« Bulletproof SSL and TLS available for early access and preorder | Main | SSL Labs: Testing for Apple's TLS authentication bug »

Checking OCSP revocation using OpenSSL

February 24, 2014

If an OCSP responder is malfunctioning, it is often difficult to understand why exactly. As is usually the case with SSL, the best approach is to use OpenSSL for troubleshooting. Checking certificate revocation status from the command line is possible, but not quite straightforward. You need to perform the following steps:

  1. Obtain the certificate that you wish to check for revocation.
  2. Obtain the issuing certificate.
  3. Determine the URL of the OCSP responder.
  4. Submit an OCSP request and observe the response.

For the first two steps, connect to the server with the -showcerts switch specified:

$ openssl s_client -connect www.feistyduck.com:443 -showcerts

The first certificate in the output will be the one belonging to the server. If the certificate chain is properly configured, the second certificate will be that of the issuer. To confirm, check that the issuer of the first certificate and the subject of the second match.

---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=GB/businessCategory=Private Organization/serialNumber=06694169/C=GB/ST=London/L=London/O=Feisty Duck Ltd/CN=www.feistyduck.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
-----BEGIN CERTIFICATE-----
MIIF5zCCBM+gAwIBAgIHBG9JXlv9vTANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UE
[30 lines of text removed]
os5LW3PhHz8y9YFep2SV4c7+NrlZISHOZVzN
-----END CERTIFICATE-----
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
MIIFBzCCA++gAwIBAgICAgEwDQYJKoZIhvcNAQEFBQAwaDELMAkGA1UEBhMCVVMx
[...]

If the second certificate isn't the one, check the rest of the chain; some servers don't serve the chain in the correct order. If you can't find the issuer certificate in the chain, you will have to find it somewhere else. One way to do that is to look for the Authority Information Access extension in the leaf certificate:

$ openssl x509 -in fd.crt -noout -text
[...]
    Authority Information Access:
        OCSP - URI:http://ocsp.starfieldtech.com/
        CA Issuers - URI:http://certificates.starfieldtech.com/repository/sf_intermediate.crt
[...]

If the CA Issuers field is present, it should contain the URL of the issuer certificate. If the issuer certificate information isn't available, you can try to open the site in a browser, let it reconstruct the chain, and download the issuing certificate from its certificate viewer. If all that fails, you can look for the certificate in your trust store, or visit the CA's web site.

If you already have the certificates and just need to know the address of the OCSP responder, use the -ocsp_uri switch to the x509 command as a shortcut:

$ openssl x509 -in fd.crt -noout -ocsp_uri
http://ocsp.starfieldtech.com/

Now you can submit the OCSP request:

$ openssl ocsp -issuer issuer.crt -cert fd.crt -url http://ocsp.starfieldtech.com/ -CAfile
issuer.crt
WARNING: no nonce in response
Response verify OK
fd.crt: good
        This Update: Feb 18 17:59:10 2013 GMT
        Next Update: Feb 18 23:59:10 2013 GMT

You want to look for two things in the response. First, that the response itself is valid ("Response verify OK" in the previous example), and second, what the response said. When you see "good" as status, that means that the certificate has not been revoked. The status will be "revoked" for revoked certificates.

The warning message complaining about the missing nonce is telling you that OpenSSL wanted to use a nonce as a protection against replay attacks, but that the server in question did not reply with one. This generally happens because CAs want to improve the performance of their OCSP responders. When they disable the nonce protection (the standard allows it), OCSP responses can be produced once (usually in batch), then cached and reused for a period of time.

You may encounter OCSP responders that do not respond successfully to the previous command line. The following may help in such situations:

  • Do not request a nonce; Some servers cannot handle nonce requests, and respond with errors. OpenSSL will request a nonce by default. To disable nonces, use the -no_nonce command line switch.
  • Supply a Host request header; Although most OCSP servers occupy an entire IP address and respond to HTTP requests no matter the hostname, some don't. If you encounter an error message that includes a HTTP error code (e.g., 404), you should try supplying the correct hostname in your OCSP request. You can do this if you are using OpenSSL 1.0 and better, using the undocumented -header switch.

With the previous two points in mind, the final command to use is the following:

$ openssl ocsp -no_nonce -header Host ocsp.starfieldtech.com -issuer issuer.crt -cert fd.crt -url http://ocsp.starfieldtech.com/ -CAfile issuer.crt
MY NEXT BOOK: If you like this blog post, you will love Bulletproof SSL and TLS. This book will contain everything you need to know about SSL and TLS for web application development and deployment, covering both theory and practice. It is available now for early access and preorder.

For a preview of the book, download and read my OpenSSL Cookbook ebook. It's free.