How Certificate Revocation Works with CRLs and OCSP

Certificate Revocation refers to the act of canceling a signed certificate before its expiration date. This can be done due to private key compromise, retirement of a service, or various administrative reasons. There are many different approaches for verifying that a certificate is still in good standing, and often a combination is used in order to provide fault tolerance.

• Certificate Revocation Lists (CRLs)
• How CRLs work. Logical flow.
• Distribution of CRLs
• Open Certificate Status Protocol (OCSP)
• OCSP Stapling
• OCSP MustStaple

Certificate Revocation Lists (CRLs)

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.

CRLs Logical Flow

1. The client reaches out an endpoint over HTTPS.
2. The server, as part of its response, includes a signed public certificate.
3. As part of validating the chain of trust, the client interrogates the “CRL Distribution Points” attribute of the certificate to determine the possible locations it can reach out to in order to obtain the blacklist.
4. The client reaches out to the distribution point, pulls down the CRL, and uses this information in order to make its trust decision. Different clients behave differently when a certificate’s public key has been revoked.

Distribution of CRLs

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.

Open Certificate Status Protocol (OCSP)

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

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 Stapling Logical Flow

1. The client reaches out an endpoint over HTTPS.
2. The server on a regular interval reaches out to an OSCP responder server hosted by its certificate’s issuer in order to constantly receive a timestamped “reup” of its certificate’s validity. This recent timestamped signature is “stapled” to the server’s response.
3. The client, which trusts information signed by the CA since it is present in its root certificate store, knows that the certificate is still valid since it was able to verify a recently timestamped “check-in” the server made with the CA.

OCSP MustStaple

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!

OCSP MustStaple Logical Flow

1. The client reaches out an endpoint over HTTPS.
2. TLS allows for additional information to be exchanged by the client and server as part of the TLS handshake. These are called “extensions”, and can influence the behavior of the client and server. For an extension to be used, it must be present in the list of supported extensions by both the client and server during the initial handshake. The client, wanting to use OCSP MustStaple, includes it in the list of extensions it supports when constructing its ClientHello.
3. The server, if it supports MustStaple, includes it in the list of supported extensions during the ServerHello.
4. The client, encountering an OCSP response of “revoked” or “unknown”, knows to hard fail the connection.