Certificate revocation is the mechanism that lets a Certificate Authority declare a TLS certificate invalid before its natural expiry date. It exists because certificates can be compromised — a private key can leak, a CA can mis-issue, or an organisation can be sold and need to invalidate certificates issued under the old name. Revocation is how the PKI ecosystem handles these situations.
The problem is that revocation checking is fundamentally broken in practice, and has been for most of the history of TLS. The mechanisms exist, browsers implement them inconsistently, and the fail-open design decisions made for availability reasons mean that revoked certificates often continue to work.
How revocation is supposed to work
There are two main mechanisms for certificate revocation: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP).
CRLs are lists published by CAs containing the serial numbers of all revoked certificates. A browser can download the CRL for a certificate's issuing CA and check whether the certificate's serial number appears on the list. CRLs are simple conceptually but become unwieldy at scale — a CA that has issued millions of certificates may have a CRL measured in megabytes, which browsers cannot practically download on every connection.
OCSP (Online Certificate Status Protocol) was designed to solve the CRL scaling problem. Instead of downloading the entire list, a browser sends a query to the CA's OCSP responder with the serial number of the specific certificate it wants to check, and receives a signed response: good, revoked, or unknown. This is more efficient — one small request per certificate — but it introduces a dependency on the CA's OCSP infrastructure being available.
Why revocation checking fails in practice
The critical design decision that undermines revocation is the fail-open behaviour most browsers use for OCSP checks.
If a browser cannot reach the CA's OCSP responder — because it is slow, temporarily down, or blocked by a network filter — the browser has a choice: block the connection (fail closed) or allow it (fail open). Almost all browsers chose fail open, because the alternative is that network problems at a CA would cause widespread connection failures for users who have nothing to do with any certificate compromise.
This means an attacker who intercepts traffic using a revoked certificate can simply block the OCSP request. The browser fails to get a revocation response, falls back to its fail-open behaviour, and accepts the certificate. Revocation is bypassed.
Beyond active blocking, there are structural reasons revocation checks are unreliable:
- OCSP stapling is optional and often not configured. OCSP stapling has the server pre-fetch the OCSP response and include it in the TLS handshake — eliminating the browser's dependency on the CA's infrastructure. But stapling must be configured on the server, and many servers do not have it enabled.
- OCSP responses are cached. Even when OCSP checking works correctly, responses are cached for the duration of the response's validity period — typically hours to days. A certificate revoked today may still be accepted by browsers that cached a "good" response yesterday.
- Mobile browsers often skip OCSP entirely. Battery and data usage concerns lead some mobile browsers to disable revocation checking. A revoked certificate may be fully accepted on mobile for its entire original lifetime.
- Chrome abandoned OCSP in 2012. Google's Chrome browser does not perform live OCSP checks. Instead, Chrome uses CRLSets — curated, compressed lists of high-priority revocations pushed via the browser update mechanism. Only a small fraction of revoked certificates appear in CRLSets; the vast majority are never checked by Chrome users at all.
What revocation is actually useful for
Given these limitations, it is reasonable to ask whether revocation has any practical value. It does — but in a narrower set of circumstances than commonly assumed:
High-profile compromises flagged by CAs. When a CA determines that a certificate was seriously mis-issued — especially for a high-value domain — they may push the revocation to CRLSets or other browser update mechanisms. This provides meaningful protection for a small subset of revocations.
API clients and non-browser contexts. Many API clients, mobile SDKs, and server-to-server communication libraries implement stricter revocation checking than browsers. In these contexts, revocation may be more reliably enforced.
Long-lived certificates. The longer a compromised certificate remains valid, the more value revocation has. Under 47-day certificate lifetimes, an attacker's window shrinks to weeks regardless of revocation — the limited certificate lifetime itself becomes the primary mitigation.
What actually limits damage from a compromised certificate
If revocation is unreliable, the effective controls for limiting certificate compromise damage are:
- Short certificate lifetimes. A 47-day certificate compromised on day one limits attacker use to 47 days maximum. A one-year certificate compromised on day one gives the attacker 364 days — regardless of whether it gets revoked.
- Private key security. The most effective control is ensuring private keys are never compromised in the first place — hardware security modules, strict access controls, and encrypted storage at rest.
- Certificate transparency monitoring. CT logs make mis-issuance detectable quickly. Monitoring CT logs for unexpected issuances for your domains lets you detect if a CA has issued a certificate for your domain without your knowledge.
- OCSP stapling with Must-Staple. The TLS Must-Staple extension allows a certificate to declare that it must be presented with a stapled OCSP response. Browsers that support Must-Staple will refuse connections where the staple is absent or stale — eliminating the fail-open behaviour for those certificates.
How CertControl monitors revocation status
CertControl checks OCSP status for all monitored certificates as part of each TLS certificate monitoring scan cycle — flagging certificates that have been revoked, that have OCSP responders that are unreachable, or that are not using OCSP stapling where it would be beneficial. Revocation status appears in the certificate detail view alongside expiry, chain health, and TLS configuration findings.
For certificates where revocation monitoring matters most — production certificates, certificates covering high-value services, certificates issued under managed CA relationships — the platform surfaces OCSP configuration issues as findings with appropriate severity ratings. Certificates with revocation checking problems are prioritised for remediation alongside expiry risks.
Frequently asked questions
What is the difference between CRL and OCSP?
A CRL is a list of all revoked certificate serial numbers published by a CA, which becomes large at scale. OCSP lets a client query the status of one specific certificate and receive a signed good, revoked, or unknown response, which is more efficient but depends on the CA's responder being reachable.
Why do revoked certificates often still work?
Most browsers fail open: if they cannot reach the OCSP responder they accept the certificate. Responses are also cached for hours, mobile browsers often skip OCSP, and Chrome uses CRLSets that cover only a small fraction of revocations.
What is OCSP stapling and Must-Staple?
OCSP stapling has the server pre-fetch the OCSP response and include it in the TLS handshake, removing the client's dependency on the CA. The Must-Staple extension forces browsers to refuse connections where a fresh staple is absent, eliminating fail-open for those certificates.
Does Chrome perform OCSP checks?
No. Chrome abandoned live OCSP checks in 2012 and instead uses CRLSets — curated, compressed lists of high-priority revocations pushed via browser updates. The majority of revoked certificates are never checked by Chrome users.
What actually limits damage from a compromised certificate?
Short certificate lifetimes, strong private key security, Certificate Transparency monitoring for mis-issuance, and OCSP stapling with Must-Staple are more effective than relying on revocation alone.