The Online Certificate Status Protocol (OCSP) was built as an alternative to CRL (Certificate Revocation List). It’s used for fetching the revocation status for a certain X.509 certificate.

In this post, we’ll get into the finer details of OCSP, telling you how it works and how to check if you enabled it properly on MaxCDN. For a higher level view of OCSP, check out this visual glossary article and this blog post.

How OCSP Works

  1. Assuming person A and B have public key certificates provided by person C, or the CA (certificate authority) …
  2. A starts communication with B and sends its public key certificate to B
  3. Now person B wants to make sure that key wasn’t compromised, and thus, B sends A’s public key to C as a part of an OCSP request.
  4. C’s responder grabs the serial number from the key certificate and checks the its database for revocation status.
  5. The OCSP responder confirms that the key certificate is OK and sends it back to B with a signed OCSP response.
  6. B has C’s public key, so B can verify C’s signature.
  7. And finally B can freely communicate with A.

NOTE: When B sends an OCSP request to C (step 3,) it’s assumed that C’s database is the only revocation database they can trust at this time.

 

Enabling OCSP on MaxCDN

As described in our blog post, if you don’t already have the certificate installed, all you need to do is upload the certificate as well as the CA bundle. After this, MaxCDN automatically reloads the vhost file for your zone and OCSP is enabled.

Before your zone makes enough traffic for tools like SSL Lab’s SSL Server Test to recognize your OCSP as being enabled, you can manually confirm it’s status as follows:

echo QUIT | openssl s_client -connect www.maxcdn.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

Expected Output

$ echo END | openssl s_client -connect www.maxcdn.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 9B679E7FECC2208C37F290121EB78BA69EA87F6B
    Produced At: Sep 14 17:12:48 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 84D56BF8098BD307B766D8E1EBAD6596AA6B6761
      Issuer Key Hash: F5CDD53C0850F96A4F3AB797DA5683E669D268F7
      Serial Number: 11213F9430FA68006A9D497F691D7B959EBD
    Cert Status: good
    This Update: Sep 14 17:12:48 2015 GMT
    Next Update: Sep 15 05:12:48 2015 GMT

If OCSP was not enabled properly, you won’t see any response in the output.

Noteworthy components of the output include:

  1. The Responder Id in the example above (persons A and B) is the entity that grants the certificate serial number and performs the lookup in the revocation database. The responder Id is its identification number.
  2. Produced At shows the date when the response was generated.
  3. Hash Algorithm, Issuer Name Hash, Issuer Key Hash and Serial Number are all readable information from the certificate itself. Based on this serial number the responder can perform the lookup.