Certificate revocation is the part of PKI that almost nobody tests until it breaks in production. When a private key leaks, an issuer misissues a cert, or a domain changes hands, the certificate needs to be invalidated before its natural expiration date — and the two mechanisms built for that job, Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP), take very different approaches to solving the same problem. Picking the wrong one, or misconfiguring either, leaves a window where a compromised certificate is still trusted by every browser hitting your site.
What CRLs and OCSP actually do differently
A CRL is a signed, timestamped file published by a Certificate Authority listing every certificate it has revoked, identified by serial number. Clients download the whole list — sometimes tens of megabytes for a busy CA like DigiCert or Sectigo — and check locally whether a given serial appears on it. It’s a pull-once, cache-and-reuse model, refreshed on an interval the CA defines in the certificate itself (commonly 7 days for CRLs published via the cRLDistributionPoints extension).
OCSP flips that around. Instead of pulling a giant list, the client (or, with OCSP stapling, the server on the client’s behalf) sends a single query to the CA’s OCSP responder asking “is serial 04:3F:A2… still good?” and gets back a signed yes/no/unknown, typically valid for a much shorter window — often 4 to 7 days for the response’s own validity, though the query itself happens in near real time. That per-certificate lookup is lighter on bandwidth but introduces a new dependency: the OCSP responder has to be reachable and fast, every single time a client wants confirmation.
Why the industry converged on OCSP, then partly walked it back
CRLs scale badly. A CA like Let’s Encrypt issues over 300 million certificates and revokes a meaningful fraction of them for key compromise, CAA violations, or policy issues — a flat list model at that volume becomes unwieldy fast, which is why Let’s Encrypt stopped supporting CRLs for end-entity certs and leans on OCSP (and now short-lived certs) instead. OCSP looked like the fix: smaller queries, faster answers, less client-side storage.
But OCSP has its own well-documented failure mode. If the OCSP responder is down or slow, most browsers historically fell back to “soft-fail” — treating an unreachable responder as if the certificate were valid, which quietly defeats the whole point of revocation checking. Chrome deprecated online OCSP/CRL checking for the general web PKI years ago and instead relies on its own aggregated revocation mechanism, CRLSet, updated centrally rather than queried per-connection. Firefox uses a similar approach with OneCRL. So for the browsers most of your traffic comes from, neither classic CRL nor live OCSP is actually doing the revocation check anymore — the browser vendor’s own compiled list is.
That’s the myth worth busting directly: many engineers assume enabling OCSP stapling means “browsers now properly check revocation status in real time.” In practice, it mainly buys you performance (skipping a client-side round trip) and privacy (the CA doesn’t see every visitor’s IP), not a guaranteed hard-fail revocation check across all clients.
OCSP stapling: the practical middle ground
OCSP stapling is where most production teams should focus if they’re using OCSP at all. Instead of the browser querying the CA directly on every handshake, the web server itself periodically fetches a signed OCSP response and “staples” it to the TLS handshake. Nginx handles this with `ssl_stapling on;` and `ssl_stapling_verify on;`, Apache with `SSLUseStapling on`. This removes the client-to-CA round trip entirely, cuts handshake latency by tens to low hundreds of milliseconds depending on the responder’s geographic distance from the CA, and avoids leaking visitor IPs to the CA’s infrastructure.
The catch: a stapled response is only as fresh as the last successful fetch. If a web server’s outbound connection to the OCSP responder starts failing — firewall change, DNS issue, CA-side outage — and nobody notices, the server keeps serving a stale staple until it expires, then TLS handshakes may start failing outright for clients that hard-fail on missing staples (some Firefox configurations do this via OCSP Must-Staple).
Where CRLs still make sense
CRLs haven’t disappeared. Enterprise PKI, internal certificate authorities, code-signing infrastructure, and S/MIME email all lean on CRLs heavily, partly because those environments don’t have the same volume problem public web PKI does, and partly because CRLs work fine in air-gapped or intermittently-connected networks where a live OCSP query isn’t feasible — a signed CRL can be distributed once and cached for days. If you’re running an internal CA for service-to-service mTLS in a Kubernetes cluster, publishing a CRL to an internal endpoint and having services check it on a schedule is often simpler and more reliable than standing up a highly-available OCSP responder.
Common mistakes teams make with revocation checking
A recurring pattern: teams enable OCSP stapling once during initial TLS setup and never check it again, assuming it’s a “set and forget” flag. An experienced SRE instead adds the stapling response to routine SSL monitoring checks — verifying the staple is present and current, not just that the handshake succeeds, since a broken staple often still results in a working connection with degraded trust guarantees.
Another mistake is treating revocation as purely a CA-side concern. If a private key is compromised — leaked in a public GitHub repo, exposed via a misconfigured backup, pulled from a decommissioned load balancer — the organization has to actively request revocation from the issuing CA and confirm it propagated, not just assume rotation of the cert on the server is enough; old copies of the compromised cert-key pair remain individually valid to anyone who has them until the CA formally revokes the serial. Detection-and-response workflows for this exact scenario are worth having documented in advance rather than improvised during an incident.
A third: assuming a green padlock means revocation status was actually verified. Given Chrome’s and Firefox’s reliance on centrally distributed revocation lists rather than live per-connection checks, a certificate can display as fully trusted in a browser for hours or days after formal revocation, depending on when that browser’s local CRLSet or OneCRL update last ran.
FAQ
Does OCSP stapling replace the need for a CRL entirely?
No. Stapling changes how the client gets an OCSP-style answer, but many CAs still maintain and publish CRLs as a fallback distribution point, and some client software or embedded devices default to CRL checking regardless of what the server offers.
Why do some certificates show both CRL and OCSP URLs in their extensions?
CAs typically include both the cRLDistributionPoints and authorityInfoAccess (OCSP) extensions so that clients unable to reach one method can fall back to the other — it’s redundancy, not a signal that both are required.
Can I monitor whether my server’s OCSP stapling is actually working?
Yes — tools like `openssl s_client -connect host:443 -status` show whether a staple is present and its validity window; this is exactly the kind of check worth automating rather than running manually after something breaks.
For most public-facing web servers, enabling OCSP stapling correctly and keeping an eye on its freshness delivers the best balance of performance and revocation coverage available today. CRLs remain the right tool for internal PKI, offline environments, and as the CA-side fallback everything else depends on — understanding both, rather than picking one and ignoring the other, is what keeps a revocation event from turning into an outage.