Score:1

Windows: How can I diagnose certificate revocation check failure, when I know the OK response is sent?

in flag

TL;DR; How to discover what is wrong with OCSP response on Windows?

I am trying to install a new certificate in on-premises Exchange Server 2019. But Exchange always reports that the new certificate fails the revocation check and will not use it. The new certificate has a chain of trust from the new cert, through an intermediate CA to my root ca. When I open the new cert in certmgr.msc, I see that that chain, and all certificates are reported as OK in certmgr. I have installed my root CA into the “Trusted Root Certification Authorities” store. I have installed the intermediate CA into the “Intermediate Certification Authorities” store.

The new cert’s Authority Info Access URL specifies my own OCSP responder. I know this is not a connection nor proxy problem, because I watch the OCSP logs real-time, and I know the connection is made, and my OCSP responder sends cert “OK”. I have tested with openssl-ocsp on a linux host, and that validation succeeds, when I use this openssl command:

   openssl ocsp 
      -issuer "$ca_sub_cert_file" 
      -cert "$exchangeCert" 
      -resp_text 
      -CApath "$CA_ROOTS_HASHES_DIR" 
      -url "http://$hostNameFull:$ocsp_port/"

Please note that the above openssl command explicitly refers to the issuer, and the CApath, and that enables trust upon the intermediate CA. On Windows, I expected that installing the root-ca and the intermediate CA would similarly enable trust for the OCSP response. But I do not know how to test this.

It should not be necessary, but I also “installed” a certificate for the ocsp-responder. I allowed the wizard to choose the store automatically, and I can not find where it was put. It does not appear when I search for it in certmgr.msc. I have not installed it manually, because I do not know which store I should use.

I suspect that the response from my openssl OCSP responder is wrong for Exchange Server 2019. My theories are:

  • A trust chain cannot be built from the new certificate to my root CA
  • The chain is built, but one of the certificates for ocsp-responder, the intermediate-ca, or root-ca is not trusted. Even though intermediate-ca, and root-ca are installed.
  • The openSSL response is incompatible with Windows and or Exchange Server 2019

How can I test the above theories? I searched the windows event logs but they do not contain any mention of OCSP or revocation.

cn flag
I don't think that OCSP is your problem. Your problem is most likely in CRL. Post the output of the following command: `certutil -verify -urlfetch exchcert.cer`.
Score:1
br flag

The certutil.exe has a relatively new option, called -downloadocsp which you can use to verify the OCSP responses.

  1. In a command prompt, create two folders, called certs and results.
  2. Place your Exchange server certificates in the certs folder. If your using OCSP to check the CA certificate too, place a copy of the CA certificate in that folder.
  3. Run certutil -downloadocsp certs results downloadonce. This will create a .ocsp file within results for each response.
  4. Finally, run certutil results\????.ocsp to view each response as plaintext.

The above is from Mark Cooper's brilliant website.

in flag
Thanks a million! I tried the above: not on my exchange server, but on a Windows 10 workstation. I watch certutil make a connection to my ocsp responder, and it downloads something, but it reports "Error => Pending OCSP response download". Nothing is created in the results directory. At least now I have s tool to work with, and some documentation to read.
in flag
I consistently get nothing in results, and the error " Error => Pending OCSP response download -- <8958F37AF76E2151B548E950719789A1FA705F0A> <saratoga.candy-land.name> <ca-sub.candyland.org> <saratoga.candy-land.name_exchange_20210630145440_exchange.p7b>" ... ... ... I get nothing real from google searching for certutil "Pending OCSP response download"
br flag
I can't help you there as I can't get it to error - it works for me when I run it against a certificate I've downloaded from the Internet (GMail in this instance).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.