CRL vs OCSP is how a relying party learns that a certificate was revoked before it expired. A certificate revocation list (RFC 5280 §5) is a signed list of revoked serial numbers that clients download; the Online Certificate Status Protocol (RFC 6960) answers a query about one certificate. For the public web PKI the answer has shifted decisively since 2024: CRLs became mandatory, OCSP optional, and the largest CA switched OCSP off.
At a glance
| CRL | OCSP | |
|---|---|---|
| Specification | RFC 5280 §5 | RFC 6960 (nonce: RFC 8954) |
| What the client gets | Signed list of all revoked serials for a scope | Signed status (good, revoked, unknown) for one serial |
| Size (measured 2026-10-20) | 62,116-byte Let's Encrypt CRL shard with 1,591 entries | 471-byte DigiCert OCSP response |
| Freshness | thisUpdate to nextUpdate (that shard: 9 days) | Response validity (that response: 7 days) |
| Privacy | Server learns only that a CRL was fetched | Responder learns which site the client is visiting |
| Availability dependence | Can be cached, mirrored and preloaded | Live dependency on the responder unless stapled |
| Web PKI rule (Baseline Requirements) | Mandatory since 15 March 2024; new CRL at least every 4 days (7 if every certificate has an OCSP URL) and within 24 hours of a revocation | Optional since 15 March 2024 |
| Browser use | Aggregated: Firefox CRLite, Chrome CRLSets | Firefox stopped querying for DV certificates (version 142); Chrome does not query for most certificates |
| Server delivery | Not applicable | OCSP stapling (status_request, RFC 6066) |
How each one works
A CRL names its issuer, carries thisUpdate and nextUpdate, a monotonically increasing CRL number and one entry per revoked certificate (serial, revocation date, optional reason), and is signed by the CA. Certificates point to their CRL in the CRL Distribution Points extension; large CAs shard CRLs so each file stays manageable, and public CAs disclose the full set of CRL URLs in CCADB so aggregators can collect every revocation. Clients that check CRLs download and cache them, and delta CRLs (RFC 5280 §5.2.4) can reduce traffic for large lists.
An OCSP client sends the issuer name hash, issuer key hash and serial number to the URL in the certificate's Authority Information Access extension; the responder returns a signed status with its own validity window. Responses can be cached until nextUpdate, and servers can staple a fresh response into the TLS handshake so clients need not contact the CA.
The measurements above were taken live: a Let's Encrypt certificate issued in September 2026 points only to http://ye2.c.lencr.org/96.crl (no OCSP URL), and that shard was 62 KB; a DigiCert certificate still carries http://ocsp.digicert.com, whose response was 471 bytes.
Why OCSP faded on the web
Three properties undid live OCSP for browsers. Privacy: each lookup tells the CA which site a user is visiting from which IP address. Availability: a slow or unreachable responder either blocks page loads or, because browsers chose to soft-fail, is silently ignored, which means an attacker who can block the responder defeats the check. Cost: responders must handle every page load on the internet. Stapling fixed privacy and cost but depended on every server refreshing responses reliably, and Must-Staple (RFC 7633), which would have made stapling enforceable, was supported only by Firefox.
The CA/Browser Forum responded with ballot SC-063 (effective 15 March 2024): CRLs mandatory, OCSP optional. Let's Encrypt removed OCSP URLs from new certificates and stopped accepting Must-Staple orders on 7 May 2025 and shut down its responders on 6 August 2025. Firefox enabled CRLite for all desktop users in version 137: a compact local encoding of every revocation among CT-logged certificates, refreshed every 12 hours at an average of about 300 kB of downloads per day. Firefox 142 then stopped OCSP queries for domain-validated certificates. Chrome relies on CRLSets, a curated set focused on high-impact revocations, rather than per-site lookups.
The third option: short-lived certificates
A certificate valid for days needs no revocation check: by the time a revocation would propagate, it has expired. The Baseline Requirements let CAs omit revocation information from short-lived certificates (at most 7 days for those issued since 15 March 2026), and Let's Encrypt offers 160-hour certificates through its shortlived ACME profile since January 2026. Combined with the general lifetime reduction to 47 days by 2029 (ballot SC-081v3), revocation is becoming a backstop rather than the primary control. The certificate lifetime calculator shows the limits by issuance date.
When to choose which
- Public TLS servers: do nothing special; make sure your certificates come from a CA that publishes CRLs, and do not enable Must-Staple. Remove stapling configuration that fails when no OCSP URL exists.
- Client software verifying public certificates: use the platform verifier; it applies the browser vendors' revocation sets where available.
- Private PKI with many clients, some offline: CRLs with a short
nextUpdate, served from highly available HTTP. - Private PKI with high-value certificates and online clients: OCSP, with stapling where the protocol supports it, and hard-fail policies if the responder is under your control.
- Workload and service identities: short-lived certificates (hours to days) issued automatically, with no revocation infrastructure at all.
- Code signing and document signing: revocation still matters for long-lived signatures; combine CRLs or OCSP with timestamps so verifiers can check status at signing time.
Migration notes
- Inventory dependencies on OCSP: server stapling configuration, clients that hard-fail without OCSP, monitoring that checks responders.
- Make stapling optional: nginx and Apache must not refuse to start when a certificate has no OCSP URL.
- For private CAs, publish CRLs first: add CRL distribution points to new certificates, shard large lists, set
nextUpdateto match your revocation SLA, and serve them over HTTP (not HTTPS, to avoid circular dependencies). - Shorten lifetimes where automation allows; each step reduces how much revocation must carry.
- Test revocation end to end: revoke a test certificate and confirm clients reject it within the expected time. The CRL decoder and OCSP decoder show what clients will see.