CRL vs OCSP: How Certificate Revocation Actually Works (and Where It Still Fails)

Why Revocation Exists

Every X.509 certificate contains an expiration date. If a certificate is valid until 2027 and nothing changes, every client that validates its chain will accept it until then. That's fine most of the time. It's catastrophic when something changes.

The things that change:

• The private key leaks (cloud storage misconfiguration, HSM operator error, build-pipeline compromise)
• The subject's identity changes (person leaves, device decommissioned, hostname repurposed)
• The CA issued the certificate incorrectly (name validation bypass, template bug, cross-sign to the wrong subordinate)
• The CA itself is compromised and every cert it has ever issued becomes untrusted

For each of these, there has to be a mechanism that tells relying parties to stop trusting a specific certificate before its stated expiry. That mechanism is revocation. The two standard ways to do it are CRLs and OCSP.

CRL — The Simple Idea

A Certificate Revocation List is exactly what it sounds like: a signed list of certificate serial numbers that the CA says are revoked, published to a known URL. The CRL distribution point (CDP) URL is embedded in every certificate the CA issues. When a client validates a chain, it fetches the CRL from the CDP, checks whether the certificate's serial number is on the list, and either accepts or rejects the chain.

The CRL is signed by the CA (or by a dedicated CRL signer). It has a thisUpdate time (when the list was last regenerated) and a nextUpdate time (when the next version is expected). Relying parties cache the CRL until nextUpdate.

What CRL does well

• Simple to implement. A CA that can sign a certificate can sign a CRL. The format is a tiny ASN.1 structure. Every production CA since the mid-1990s supports it.
• Cacheable. A single CRL file serves millions of relying parties with one fetch each. CDNs love CRLs.
• Offline-friendly. A client can validate against a CRL without a live round-trip to the CA, as long as the cached CRL hasn't expired.
• Resilient to CA outages. If the CA goes down for an hour, cached CRLs keep working.

Where CRL breaks

• File size. Every revoked certificate stays in the CRL until it would have expired naturally. A CA that has issued 10 million certificates over three years with a 1% lifetime revocation rate ends up with a 100,000-entry CRL. At roughly 30 bytes per entry, that's a 3 MB file every relying party pulls on refresh. Big public CAs have CRLs in the tens of MB. This has eaten CDN budgets.
• Freshness lag. The default ADCS CRL publication cadence is daily. Even with delta CRLs enabled at 5-minute intervals, a cert revoked at 00:00:30 isn't visible until the next delta publication. For a 47-day certificate world, this gap is a load-bearing problem.
• Cache invalidation. Relying parties cache the CRL until nextUpdate. If you shorten nextUpdate to minutes, every client fetches it every few minutes. If you leave it at days, your revocation window is days. There's no "cheap and fresh" option.
• Soft-fail. Most non-browser clients soft-fail on CRL fetch errors: if the CDP is unreachable, the certificate is considered valid. This is why CRL alone is rarely sufficient for revocation.

OCSP — The Real-Time Idea

The Online Certificate Status Protocol addresses the CRL freshness problem by inverting the model. Instead of the CA publishing a bulk list, the client asks the CA about a specific certificate: "is serial=0x1234 revoked?" The CA (or a dedicated OCSP responder) returns a signed response: good, revoked, or unknown.

The OCSP responder URL (Authority Information Access, or AIA) is embedded in every certificate. Clients make a POST request with the certificate serial, get back a signed status, and cache it according to the response's own nextUpdate.

What OCSP does well

• Per-cert queries. The response is tiny — a few hundred bytes. No matter how many certs the CA has issued, each query transfers a few hundred bytes.
• Fresher. A revocation can be reflected in OCSP responses within minutes of the operator action, independent of CRL publication cadence.
• Scalable at the client level. A client validating 10,000 certs makes 10,000 small queries. A client validating against CRLs always pays for the full list.

Where OCSP breaks

• Server-side load. Every TLS handshake can trigger an OCSP query. For a high-traffic endpoint, that's thousands of OCSP requests per second against the responder. Public CAs run global anycast OCSP infrastructure specifically for this.
• Privacy. The CA sees every validation query. Every relying party pinging the OCSP responder tells the CA which certificates they're validating — which is a privacy leak that's exactly as bad as it sounds.
• Latency. Each OCSP query adds a round-trip to the handshake. For a TLS connection to a server in Virginia from a client in Singapore, that's 200+ ms of extra latency before the handshake completes.
• Soft-fail. Same problem as CRL — most non-browser clients treat an unreachable OCSP responder as "not revoked." A compromised cert plus a reachable DNS plus a firewalled OCSP responder equals a successful attack.
• Single point of failure. If the OCSP responder goes down and clients soft-fail, revocation stops working for the duration of the outage. If they hard-fail, your entire fleet stops validating.

OCSP Stapling — The Fix for OCSP's Problems

OCSP stapling (RFC 6066's status_request extension) moves the OCSP query from the client to the server. The TLS server fetches an OCSP response for its own certificate on a schedule, caches it, and includes ("staples") it in every TLS handshake. Clients validate the stapled response's signature and freshness without making their own OCSP query.

Why stapling matters

• Zero client-side latency. No round-trip to the OCSP responder during the handshake.
• No privacy leak. The CA never sees which clients are validating which certs — only the server fetching for its own cert.
• Scales to the server. One OCSP fetch per server per cache interval, regardless of how many clients connect.
• Supports hard-fail. Must-Staple (RFC 7633) lets a CA mark a certificate as requiring stapling for validation. A client that sees a cert without a stapled response treats it as invalid. This is the only widely-deployed hard-fail mechanism that doesn't break on OCSP responder outages.

Where stapling still falls short

• Server configuration burden. The server has to be configured to fetch, cache, and refresh OCSP responses. nginx, HAProxy, and Envoy all support it; many application-level TLS servers do not.
• No per-chain stapling until TLS 1.3. TLS 1.2 can only staple the leaf certificate's OCSP response. TLS 1.3 (RFC 8446 §4.4.2.1) supports stapling for the entire chain, which is required for intermediate CA revocation to be effective at the handshake layer.

The Browser-Specific Alternatives

The browser vendors looked at CRL and OCSP and built their own revocation layer because neither was fast enough.

CRLSet (Chrome)

Chrome's CRLSet is a hand-curated list of high-impact revocations, pushed to every Chrome instance out-of-band via the browser update channel. When an intermediate CA is compromised (eMudhra, DigiNotar, Symantec), the CRLSet gets it blocked in hours, before any CRL publication would have propagated.

CRLSet is not a replacement for CRL/OCSP — it's a supplement for the cases where the CA machinery is too slow. Chrome still falls back to OCSP for leaf-level revocation.

OneCRL (Firefox)

Mozilla's equivalent. Same mechanism: a signed list of known-bad intermediate certificates, pushed to Firefox out-of-band. Firefox pulls OneCRL updates every 24 hours (or on demand via Remote Settings).

CRLite (Mozilla, experimental)

An ambitious attempt to push all revocations — not just high-impact intermediates — to every browser in a compressed Bloom filter. Mozilla has been iterating on CRLite for years. It works. It's shipping. It's not universal yet, and it doesn't help non-browser clients.

Short-Lived Certificates — The Structural Fix

The pragmatic end-state is making revocation less important. Short-lived certificates — on the order of hours or days — expire naturally before most compromises would need revocation.

• Let's Encrypt issues 90-day certificates by default, now moving to 6-day short-lived certs for high-automation deployments.
• AWS Private CA supports down to 1-day lifetimes for internal workloads.
• TigerTrust issues internal certs with configurable minimums as low as 1 hour.
• The CA/Browser Forum has voted to cut public TLS validity to 47 days by March 2029.

At 47 days, revocation still matters — a compromised cert for 47 days is a bad outcome. But revocation is now a backstop, not the primary mechanism. The primary mechanism is "it expires soon enough that attackers don't bother using it."

For short-lived certs, OCSP stapling with Must-Staple + a 24-hour CRL cadence is operationally cheap and functionally sufficient. Longer-lived certs need a stricter revocation discipline — delta CRLs on a 5-minute cadence plus OCSP stapling plus client-side hard-fail where possible.

The Comparison

What You Should Actually Deploy

For public-facing TLS endpoints

1. Enable OCSP stapling on every terminating server (nginx, HAProxy, Envoy, ALB).
2. Set OCSP cache lifetime to 1-24 hours. Shorter is fresher; longer survives OCSP responder outages.
3. Add Must-Staple to new certificates when all your clients support it. (Most do in 2026.)
4. Monitor OCSP response freshness. If stapled responses age past their nextUpdate, your server is serving stale status. Alert on this.
5. Keep CRL as a backup. OCSP responders fail. CRL cached on the client is still a safety net.

For internal (private PKI) TLS

1. Short-lived certificates first. Internal workloads should have hours-to-days lifetimes, not years.
2. Delta CRLs on a 5-minute cadence for anything longer than a week.
3. OCSP stapling where TLS terminators support it; most internal mTLS implementations now do.
4. Hard-fail on validation errors at the client. For internal traffic, hard-fail is the safe default — a reachable OCSP endpoint is a solved problem inside your network.

For device fleets (IoT, OT)

1. Short-lived certificates at scale. Devices with over-the-air update paths should rotate on days-to-weeks cadence.
2. CRL fetch via the device's management plane, not direct from the public internet. The management plane can enforce revocation decisions centrally.
3. For devices with no update path: certificate pinning in firmware, bounded by the device's expected lifetime. Accept that revocation is impossible and plan for the cert to live until the device dies.

For code signing

1. Timestamp every signature. This decouples signature validity from certificate expiry.
2. Hard-fail on revocation check. The default soft-fail on Windows code-signing is why forged signatures remain valid after revocation.
3. Log every signature's validation chain to your SIEM. An unexpected intermediate appearing in the chain is a signal of a compromised issuer.

Why This Matters For TigerTrust

TigerTrust is built with the revocation story baked in. On the issuance side: delta CRLs republish every 5 minutes by default, global anycast OCSP with sub-50ms stapling latency, Must-Staple available as a per-profile toggle. On the client side: the agent configures hard-fail revocation on the OS trust store wherever the OS supports it, and the trust-store enumeration surfaces every anchor present on every host.

For CA migrations, revocation is the one thing you don't get a second chance on. The dual-trust + shadow-issuance pattern we use for ADCS migrations specifically preserves the revocation path during cutover — old CA's CRL and OCSP keep serving for the entire natural-expiry window of its issued certs, with the new CA's revocation infrastructure running in parallel from day one.

Related Reading

• eMudhra, eight bytes of entropy, and what breaks — a recent incident where revocation infrastructure was tested in production
• The non-browser trust store blind spot — why non-browser revocation is harder than browser revocation
• 47-day certificates — ADCS can't keep up — the revocation cadence pressure from shorter lifetimes
• ADCS CRL and OCSP: the revocation gaps your auditor will find — the compliance angle on CRL/OCSP configuration