What is certificate revocation?

Certificate revocation is the mechanism for declaring a certificate untrustworthy before it expires — after a key compromise, a mis-issuance, or simply because the server that held the key was decommissioned insecurely. The CA marks the certificate revoked and publishes that fact; clients are supposed to check before trusting it.

The checking part is where theory and practice diverge. The two classic mechanisms are CRLs, signed lists of revoked serial numbers that clients download, and OCSP, a live per-certificate query to the CA. Browsers found both wanting: CRLs grew large, OCSP was slow and leaked browsing history to CAs, and a failed lookup left an unanswerable question — block the site (and break the web whenever a CA responder hiccups) or proceed (and make the check pointless). Mainstream browsers chose to proceed, which made live revocation checking largely advisory.

What actually protects users today is aggregation and shortness. Browsers ship compressed summaries of revocation data with their updates — Chrome's CRLSets, Firefox's CRLite — so high-value revocations reach users without any per-site lookup. And the industry is shrinking certificate lifetimes so that a bad certificate dies soon regardless: Let's Encrypt certificates last 90 days, the CA/Browser Forum has scheduled maximum lifetimes to step down over the next few years, and Let's Encrypt retired its OCSP service in 2025 in favour of CRLs.

For an operator, revocation is mostly something you request rather than something you rely on. If a private key may have leaked, revoke and reissue immediately — but assume some clients will never see the revocation, and treat rotation, not revocation, as the real remedy. It is also worth monitoring your own certificates for unexpected revocation, because a CA acting on a mis-issuance report will revoke on its required timeline whether or not anyone told you first.