OCSP and CRLs answer the same question: has the certificate authority withdrawn this certificate before it expires? OCSP asks the authority about one certificate at the moment of use. A CRL is a signed list of every revoked serial number, downloaded in bulk. In 2026, CRLs have won for public web certificates: OCSP is optional for authorities, Let’s Encrypt switched it off, and browsers check lists they build in advance.
Sources and the CRL measurements below were checked on 15 November 2026.
The two methods side by side
A certificate revocation list (CRL) is defined in RFC 5280. The authority signs a file that lists revoked serial numbers, the revocation time and, optionally, a reason. Anyone can download it from the URL in the certificate’s CRL Distribution Points field.
The Online Certificate Status Protocol (OCSP), defined in RFC 6960, works per certificate. The client sends a serial number to the responder named in the certificate’s Authority Information Access field and gets back a signed “good”, “revoked” or “unknown”.
| CRL | OCSP | OCSP stapling | |
|---|---|---|---|
| What the client gets | Whole list of revoked serials | Status of one certificate | Status of one certificate, sent by the server |
| Who learns which site you visit | Nobody: the list is the same for everyone | The authority running the responder | Nobody beyond the server |
| Cost to the client | Large download, reused for many sites | Small request, but one per new certificate | None |
| Failure mode | Stale list until the next download | Most clients continue if the responder is down | Depends on server configuration |
| Status in public web PKI, 2026 | Required for authorities | Optional for authorities | Only works where OCSP still exists |
The privacy row is the reason most often given for the switch. Let’s Encrypt wrote that a browser checking OCSP tells the authority “which website is being visited from that visitor’s particular IP address”, and that a CRL does not.
The failure-mode row is the security problem. When Let’s Encrypt announced its plan in July 2024, it noted that most OCSP implementations “fail open”: if the responder cannot be reached, the connection goes ahead. An attacker who can block the responder can therefore hide a revocation.
What changed between 2023 and 2026
| Date | Change | Source |
|---|---|---|
| July 2023 | CA/Browser Forum ballot SC-063 makes OCSP optional for public TLS authorities and makes CRLs mandatory; Google, Mozilla and Apple voted yes | Ballot SC063v4 |
| 23 July 2024 | Let’s Encrypt announces it will end OCSP in favour of CRLs | Let’s Encrypt |
| 7 May 2025 | Let’s Encrypt stops putting OCSP URLs in certificates; requests for the Must-Staple extension fail | Let’s Encrypt timeline |
| 6 August 2025 | Let’s Encrypt turns off its OCSP responders | Let’s Encrypt |
| August 2025 | Mozilla reports CRLite on for all Firefox desktop users since Firefox 137 and OCSP being disabled for domain-validated certificates in Firefox 142 | Mozilla Hacks |
Let’s Encrypt said that at its peak, earlier in 2025, its OCSP service answered about 340 billion requests a month, more than 140,000 a second at its content delivery network.
How the browsers check now
Neither major browser engine asks the authority on every connection by default.
Chrome uses CRLSets. The Chromium documentation says they are the main way Chrome blocks certificates in emergencies, that they also hold some non-emergency revocations taken from crawled CRLs, and that “Online (i.e. OCSP and CRL) checks are not generally performed by Chrome.” Enterprises can turn online OCSP checks on by policy.
Firefox uses CRLite, a compressed structure built from all the CRLs that authorities publish. Mozilla says Firefox updates it every 12 hours and downloads about 300 kB of revocation data a day on average, against about 300 MB for the roughly 3,000 underlying CRLs. Mozilla also measured that OCSP requests had blocked the TLS handshake for 100 ms at the median. Mozilla’s comparison puts Chrome’s recent CRLSets at about 600 kB and about 1% of all revocations; that figure is Mozilla’s, not Google’s.
For a website visitor, this means revocation is checked from a list that was already on the device before the visit, so no extra network request is made and no authority learns about the visit.
What a real CRL looks like: a worked example
To see what “download the whole list” means, we fetched shards of the CRL for YR1, one of the current Let’s Encrypt issuing intermediates, from http://yr1.c.lencr.org/ on 15 November 2026 and read them with OpenSSL. Authorities may split a CRL into shards; the Baseline Requirements allow this as long as the shards together equal a full list.
| Measurement (YR1, 15 Nov 2026) | Result |
|---|---|
| Shards that answered | 1 to 128 (0 and 129 returned 404) |
| Seven sampled shards, average size | 247 kB |
| Seven sampled shards, average entries | 6,242 revoked serials |
| Bytes per entry | about 40 |
| Estimated full list for YR1 | 128 × 6,242 ≈ 799,000 serials, about 31.6 MB |
Time between lastUpdate and nextUpdate | 9 days |
The reason codes in shard 1 (6,182 entries) were: no reason code on 5,088 (82.3%), key compromise on 899 (14.5%), cessation of operation on 156 (2.5%) and superseded on 39 (0.6%). Under the Baseline Requirements, a revocation the subscriber requests without giving a reason carries no reason code, so most of these entries are routine.
Two conclusions follow. First, no browser is going to fetch 31.6 MB for one intermediate before opening a page, which is why browsers pre-process CRLs into CRLSets or CRLite. Second, for a server or a script that checks a handful of certificates, downloading one 250 kB shard is cheap. The certificate names the exact shard in its CRL Distribution Points field, so a client never needs all 128.
What the rules now require
The current Baseline Requirements, version 2.3.1 dated 4 October 2026, set these timings for publicly trusted TLS certificates:
- Revocation deadline: 24 hours for cases such as key compromise or a subscriber’s request, and at most 5 days for reasons such as misuse or a certificate issued against the rules (section 4.9.1.1).
- CRL publishing: a new CRL within 24 hours after a revocation is recorded, and otherwise at least every 7 days if every certificate carries an OCSP pointer, or every 4 days if not (section 4.9.7).
- CRL lifetime:
nextUpdateat most 10 days afterthisUpdatefor CRLs that cover subscriber certificates. The 9-day window above fits that limit. - OCSP, where offered: responses valid for 8 hours to 10 days (section 4.9.9).
- Short-lived certificates: a certificate valid for 7 days or less (issued from 15 March 2026) does not have to be revocable at all. Expiry does the job.
Put together: a revoked certificate can stay usable for up to 24 hours before the authority acts, then up to 24 more before the CRL shows it, plus however long a client’s cached list is out of date.
What to check on your own server
Most sites need to do nothing. If you run older non-browser software, a VPN or an internal service that pins its revocation checking to OCSP, check these three things.
- Does the certificate still contain an OCSP URL? Run
openssl x509 -in cert.pem -noout -ext authorityInfoAccess,crlDistributionPoints. A certificate from an authority that has dropped OCSP shows only a CRL URI. - Is your web server trying to staple? nginx logs the warning
"ssl_stapling" ignored, no OCSP responder URL in the certificatewhen stapling is on but the certificate has no OCSP URL, as its stapling source code shows. Connections still work; you can removessl_stapling on;to silence it. - Do clients fail when there is no OCSP URL? Let’s Encrypt advised operators of VPNs and other non-browser software to make sure it works with certificates that carry no OCSP URL.
To read a CRL yourself, download the URL from step 1 and run openssl crl -inform DER -in file.crl -noout -text.
For how certificates are issued in the first place, see ACME DNS-01 vs HTTP-01. For how mis-issued certificates are spotted, see Certificate Transparency logs.
