I recently did a bit of reading on how certificate revocation works in practice. Although I had some idea of what a CRL (Certificate Revocation List) was, I did not know by what mechanism a client would check a servers certificate against such a list. Hence, here’s is a writeup of my findings. This post assumes the reader has some knowledge of how digital certificates work and what they are used for, as well as what a CA (Certificate Authority) is.

To start off, let’s go through an example intended to illustrate how certificate revocation is useful. The owner of some domain example.com hosts a website over HTTPS by utilizing a digital certificate signed by a CA. One day, said certificate is compromised and the certificate holder decides to take action. In order to make sure some malicious party does not use the certificate to host their own counterfeit example.com website for nefarious purposes, the certificate holder revokes the certificate by contacting the CA. The CA adds the certificate to a CRL, marking the certificate as revoked.

Now consider the case of the malicious party hosting their own example.com website using the compromised certificate. By what means do unsuspecting clients connecting to this web server attempt to ensure the offered certificate has not been revoked? One option is to download the CRL (published by the CA) and check if it contains the certificate currently being offered by example.com. Since it does in this case, the client does not proceed with the connection. Are there any drawbacks to this particular solution? Yes. There is a performance cost associated with both downloading the CRL and searching through it which is likely not desired. Additionally, if the CA is not reachable (for whatever reason) at the moment, the client is faced with a difficult choice. Should it proceed with the connection, not knowing whether the certificate is revoked or not, or abort it based on this uncertainty?

Turns out there are options to the method outlined in the previous paragraph that manages to remedy at least some of the shortcomings. OCSP (Online Certificate Status Protocol) does away with having the client both needing to download and sift through potentially very lengthy CRLs. OCSP introduces the concept of a responder, a party whose sole purpose is to answer the question: “hey, has this certificate been revoked?”. The client knows which OCSP responder to talk to by looking at the offered certificate in question, since at the time of issuing it the CA embeds OCSP information into it. It is the job of the responder to handle OCSP requests from clients by confirming whether or not the given certificate has been revoked. It does this by simply looking through a CRL provided by the CA. So, usage of OCSP shifts the burden of fetching CRLs and searching through them from a client to the OCSP responder. However, there still is a performance hit, albeit significantly smaller, for the client, since it still has to reach out to a third party (the OCSP responder). Furthermore, this reliance on a third party once again has the issue of leaving the client with the same tough choice as before when the responder is unavailable. Can we solve this somehow?

Enter OCSP stapling. OCSP stapling provides a server with the ability to give clients the guarantee that the certificate it offers has not been revoked, without forcing the client to talk to another entity. How does this work? At regular intervals, the server performs a special OCSP request to the OCSP responder associated with its certificate. For this special requesst, the OCSP responder answers with a time-stamped OCSP response signed by the CA. This informations basically amounts to saying “I, the CA, ensure the certificate <cert> has not been revoked at the time of <timestamp>”. The web server, having acquired this response, stores it persistently somewhere. Whenever the server presents its certificate to clients, it will “staple” this information to it, and so, the client has a guarantee that the certificate is still valid, all without having to talk to anyone besides the server.

Nice! The burden of the certificate revocation check has been shifted away from the client altogether, OCSP stapling sounds awesome. In addition to all of this, it is also worth mentioning that it’s possible to embed a Must-Staple flag when issuing a certificate. This conveys a crucial piece of information to clients who will make use of the certificate: always expect this certificate to be offered to you along with an OCSP staple. If the client heeds this warning, it might choose to not go ahead with checking the revocation status of the certificate by any other means, such as vanilla OCSP or downloading a CRL.