Certificate revocation is the process by which certificates can be invalidated before they naturally expire. There are several events that would warrant revocation, ranging from known or suspected private key compromise through to simply not running the domain or service any longer (and thus not needing the certificate). In order to revoke a certificate, the issuing CA adds the certificate to a publicly available list known as a Certificate Revocation List (CRL). Then, when validating a certificate, the client verifies that the certificate they are attempting to authenticate is not contained in the CRL of the issuing CA, implying that it remains valid.
In the Web PKI, CRLs grow too large to be practical for clients to use directly, and so most browsers have innovated bespoke solutions to use in certificate chain validation. Common examples include CRLSets, which selects a subset of the CRLs to use (generally only high profile and/or CA certificates), and CRLite, which embeds the revocation information contained in the CRLs into a more compact data structure, but such solutions are not ubiquitous across all clients.
A mechanism called Online Certificate Status Protocol (OCSP) was designed to avoid end users having to obtain and store massive CRLs. In this case, the OCSP responder is responsible for obtaining the up-to-date CRL from the CA and checks the certificate status on behalf of the end user. This service is costly to run since it needs to be highly available, resilient and scalable to ensure that OCSP provides any security benefit, and is not mandatory for CAs to implement. Additionally, there are privacy concerns with OCSP as in order to obtain revocation information, the client has to divulge the domain or service it wishes to access to the OCSP responder.
An alternative is OCSP stapling, in which the domain or service obtains the OCSP response for its certificate and provides it to clients itself and so protects the client privacy. However, OCSP stapling is not particularly well supported in the Web PKI.
In summary, neither CRLs nor OCSPs as they’re currently deployed provide an ideal solution to the revocation problem for the Web PKI. Despite this, in response to a revocation-worthy event, we still strongly recommend that a domain or service owner revokes this key through the CA (possibly via your certificate management automation software) and gets it added to the CRL. However, this should be done in the knowledge that it cannot be guaranteed that this revocation status will percolate through to all end users.
