How Certificate Revocation Works with CRLs and OCSP

CRLs are one mechanism for retracting the validity of a previously issued digital signature on an X509 certificate. There are many reasons why a Certificate Authority (CA) might want to do this. For example, if an end user elects to rekey a certificate before the expiration of the old signed certificate due to private key compromise, the CA would add that certificate’s public key to the CRL. Most clients, when verifying a certificate chain via the method specified in the certificate’s own, consume the CRL and ensure that the certificate is not present on the blacklist.

By and large, the most common way of distributing a CRL is via HTTP. However, RFC 5280 makes it clear that other distribution channels such as LDAP, FTP, or even the rarely used x.500 directory service are all options. A valid URI is included as an attribute of an X509 certificate itself called “CRL Distribution Points”. What happens though if that endpoint is inaccessible by the client establishing trust? Unfortunately, this situation can result in a lot of very strange and unintuitive behaviors. Sometimes, software timers retry for periods of upwards of 2 minutes hoping the CRL will be available! This can result in an extremely poor user experience. Sometimes client implementations elect to continue on in the event all CRL distribution points are inaccessible. Others choose to throw an error. This inconsistent behavior is one of the reasons many elect to rely on OCSP instead.

OCSP (Open Certificate Status Protocol) is a standards based protocol defined in RFC 6960. OCSP provides an alternative to CRLs. Instead of a client reaching out, pulling down a large list and parsing it, it sends an ASN.1 serialized query message and receives a decision. OCSP can be implemented client side (referred to as OCSP checking) or server side (referred to as OCSP stapling).

OCSP stapling is a server-side alternative to CRLs growing in popularity. It is much less resource intensive, instead shifting the burden back on the CA’s own infrastructure. OCSP inverts the flow validity in that instead of having clients reach out to an external party as directed by an attribute in the x509 certificate, servers frequently reach out to an OCSP server hosted by the CA for a signed attestation that serves to “reup” its proof of authenticity. The server then “staples” this recent proof to the response it sends to the client, who, through verification of the signed timestamp is able to ascertain that the certificate hasn’t been revoked without any additional outbound calls! Pretty neat. Oftentimes CRLs are still present on certificates as a fallback option even for those servers that enable OCSP stapling.

OCSP, like the CRLs which came before t can suffer from an inconsistent client implementation. To promote a faster user experience, many browsers silently proceed if OCSP fails. In many cases this is a reasonable decision, but for purposes that have higher than average security needs (banking, etc), it is useful to be able to override this behavior. Enter OCSP MustStaple. Implemented as an SSL/TLS Extension, if both sides have this extension enabled, successful client verification of a server side OCSP staple must occur in order for the client to verify the validity of the server. This can cause downtime for your service if the upstream OCSP responder experiencing downtime, so be careful when supporting this option!