1

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.

Charlweed
  • 209
  • 2
  • 12
  • 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`. – Crypt32 Jul 05 '21 at 06:21

1 Answers1

1

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.

garethTheRed
  • 4,009
  • 13
  • 20
  • 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. – Charlweed Jul 05 '21 at 20:59
  • I consistently get nothing in results, and the error " Error => Pending OCSP response download -- <8958F37AF76E2151B548E950719789A1FA705F0A> " ... ... ... I get nothing real from google searching for certutil "Pending OCSP response download" – Charlweed Jul 05 '21 at 22:03
  • 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). – garethTheRed Jul 06 '21 at 06:16