Home Books Training Newsletter Resources
Sign up Log in
book cover

OpenSSL Cookbook  3rd Edition

The definitive guide to using the OpenSSL command line for configuration and testing. Topics covered in this book include key and certificate management, server configuration, a step by step guide to creating a private CA, and testing of online services. Written by Ivan Ristić.


2.13 Checking OCSP Revocation

If an OCSP responder is malfunctioning, sometimes it’s difficult to understand exactly why. Checking certificate revocation status from the command line is possible, but it’s 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 matches the subject of the second:

Certificate chain
 0 s:OU = Domain Control Validated, OU = PositiveSSL, CN = www.feistyduck.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
-----BEGIN CERTIFICATE-----
MIIFUzCCBDugAwIBAgIRAPR/CbWZEksfCIRqxNcesPIwDQYJKoZIhvcNAQELBQAw
[...]
zbQXjVsc3E1THfFZWRzDPsU4fN/1iGlbrcAWa2sFfhJXrCDfAowFJ8A1n9jMiNEG
WfQfGgA2ar2xUtsqA7Re6XlXOlwBPuQ=
-----END CERTIFICATE-----
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
[...]

If the second certificate isn’t the right 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’ll 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:
        CA Issuers - URI:http://crt.comodoca.com/COMODORSADomainValidationSecureServerCA.crt
        OCSP - URI:http://ocsp.comodoca.com

If the CA Issuers information 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 with the x509 command as a shortcut:

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

Now you can submit the OCSP request:

$ openssl ocsp -issuer issuer.crt -cert fd.crt -url http://ocsp.comodoca.com -CAfile issuer.crt
WARNING: no nonce in response
Response verify OK
fd.crt: good
        This Update: Aug 30 22:35:12 2020 GMT
	 Next Update: Sep  6 22:35:12 2020 GMT

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

🛈︎
Note

The warning message about the missing nonce is telling you that OpenSSL wanted to use a nonce as a protection against replay attacks, but 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 (usually in batch), 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 suggestions 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 respond to HTTP requests that don’t specify the correct hostname in the Host header, some don’t. If you encounter an error message that includes an HTTP error code (e.g., 404), try adding the hostname to your OCSP request. You can do this with the help of the -header switch.

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

$ openssl ocsp -issuer issuer.crt -cert fd.crt -url http://ocsp.comodoca.com -CAfile issuer.crt -no_nonce -header Host ocsp.comodoca.com
< Prev
^ Table of Contents
Next >
@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

  • Newsletter
  • SSL/TLS and PKI History
  • Archived Books
  • Bulletproof TLS Guide

Company

  • Support
  • Website Terms of Use
  • Terms and Conditions
  • Privacy Policy
  • About Us