OCSP vs CRL: how certificate revocation works in 2026

Revocation marks a certificate as untrusted before it expires. CAs publish it in a CRL, a signed list of revoked serial numbers, or through OCSP, a live per-certificate status service. As of November 2026 the Web PKI relies on CRLs: OCSP is optional for CAs, Let's Encrypt turned its responders off in August 2025, and browsers check locally cached data.

Why certificates need to be revoked

Revocation exists because a certificate can become untrustworthy long before it expires. The common triggers are a leaked private key, a domain that changed hands, a certificate issued in error, or a CA discovering that its own validation was flawed. The Baseline Requirements give CAs 24 hours to revoke in the most serious cases, such as a confirmed key compromise, and 5 days for most other reasons.

Revocation only helps if relying parties can learn about it. That is the hard part: a browser has to find out, quickly and privately, that one certificate out of billions is no longer valid. CRL and OCSP are two answers to that problem, and both have trade-offs.

How a CRL works

A Certificate Revocation List is a file signed by the CA that lists the serial numbers of revoked certificates. Its format is defined in RFC 5280 section 5, and a certificate points to its CRL through the CRL Distribution Points extension.

Large CAs no longer publish one giant CRL. They split revocations across many smaller partitioned CRLs, each covering a subset of certificates. A Let's Encrypt certificate issued in November 2026 points to one shard:

X509v3 CRL Distribution Points:
    Full Name:
      URI:http://ye2.c.lencr.org/51.crl

Decoding that shard with OpenSSL shows the structure (output shortened):

Certificate Revocation List (CRL):
    Version 2 (0x1)
    Signature Algorithm: ecdsa-with-SHA384
    Issuer: C=US, O=Let's Encrypt, CN=YE2
    Last Update: Nov  9 17:52:09 2026 GMT
    Next Update: Nov 18 17:52:08 2026 GMT
    CRL extensions:
        X509v3 CRL Number:
            1794246729324766624
        X509v3 Issuing Distribution Point: critical
            Full Name:
              URI:http://ye2.c.lencr.org/51.crl
            Only User Certificates
Revoked Certificates:
    Serial Number: 05E7C117F64B64BC83F3691B78C8F454F1B2
        Revocation Date: Sep 24 17:49:02 2026 GMT

That shard was about 100 KB with a few thousand entries. CRLs are cacheable, signed and can be served from any CDN, but a client that wants complete coverage has to download many of them, which is why browsers do not fetch CRLs on demand.

How OCSP works

OCSP, defined in RFC 6960, replaces the list with a question and an answer. The client sends the CA's responder a request identifying one certificate (hashes of the issuer name and key plus the serial number), and the responder returns a signed status.

Browser                         OCSP responder (CA)
   |  TLS handshake with example.com   |
   |  certificate has AIA OCSP URL     |
   |---- OCSP request (serial 0x05E7…) ---->|
   |<--- signed response: good / revoked / unknown,
   |     thisUpdate, nextUpdate -------|
   |  continue or abort the connection |

Responses are signed by the CA or by a delegated responder certificate carrying the OCSP Signing EKU. Public CAs pre-generate responses and serve them over plain HTTP from CDNs, which is why the RFC's optional nonce is rarely used.

Why OCSP fell out of favour

OCSP failed on privacy, reliability and performance, and the industry concluded that it could not be fixed. Each problem is structural rather than an implementation bug.

• Privacy. Every OCSP query tells the CA which site a given IP address is about to visit, and because requests travel over plain HTTP, everyone on the path sees it too. Let's Encrypt cited this as its main reason for ending the service.
• Soft-fail. If the responder is unreachable, browsers have always let the connection continue, because hard-failing would turn every responder outage into a site outage. An attacker who can intercept traffic can usually block the OCSP request as well, so soft-fail checking offers little protection exactly when it is needed.
• Latency. Mozilla measured that OCSP requests blocked the TLS handshake for about 100 ms at the median.
• Cost. At its peak Let's Encrypt answered roughly 340 billion OCSP requests per month.

OCSP stapling and Must-Staple

OCSP stapling moves the query from the browser to the server. The client sends the status_request extension defined in RFC 6066 section 8, and the server attaches a recent OCSP response that it fetched itself. In TLS 1.2 the response travels in a separate CertificateStatus message; in TLS 1.3 it sits in the extensions of the leaf entry in the Certificate message.

Stapling fixes privacy and latency but not soft-fail, because a server can omit the staple. Must-Staple (the TLS Feature extension from RFC 7633, OID 1.3.6.1.5.5.7.1.24) was meant to close that gap by telling clients to reject the certificate if no staple arrives. In practice Firefox enforced it and Chrome did not, servers handled responder outages badly, and very few certificates ever carried it. Let's Encrypt stopped accepting Must-Staple requests in 2025.

# Only useful when the certificate still contains an OCSP URL
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver 1.1.1.1 valid=300s;

SC-063: CRLs required, OCSP optional

CA/Browser Forum Ballot SC-063, adopted in 2023, reversed the old priority between the two mechanisms. It made OCSP optional for CAs issuing publicly trusted TLS certificates and made CRLs mandatory.

The ballot also set CRL freshness rules. A CA must publish a new CRL within 24 hours of revoking a certificate, and otherwise at least every 7 days if its certificates contain an OCSP pointer, or every 4 days if they do not. Partitioned CRLs are explicitly allowed, provided that together they cover every revoked certificate.

SC-063 also defined short-lived certificates: certificates valid for at most 10 days, tightened to 7 days for those issued from March 15, 2026, need not contain any CRL or OCSP pointer and need not be revoked. Expiry does the job. Let's Encrypt's shortlived profile, at 160 hours, falls within that limit.

Let's Encrypt ended OCSP in 2025

Let's Encrypt, the largest CA by volume, completed its move to CRL-only revocation in August 2025. It had supported CRLs since 2022 and announced the timeline on December 5, 2024:

By the shutdown date, every certificate that still contained an OCSP URL had already expired, so no live certificate depended on the responders. Let's Encrypt warned that browsers and websites would be unaffected but that some non-browser software, such as VPN clients or enterprise middleware configured to require OCSP, might need changes.

The Let's Encrypt timeline tracks this and other changes from the same CA.

How browsers check revocation today

Modern browsers ship revocation data to the client in advance instead of asking the CA during the handshake. The two main designs differ in coverage.

Chromium documents that Chrome does not generally perform online OCSP or CRL checks; an enterprise policy can turn online OCSP back on. Mozilla enabled CRLite for all desktop users starting with Firefox 137 and reports an average download of about 300 kB of revocation data per day. CRLite depends on Certificate Transparency: it can only include certificates it can find in CT logs.

Other TLS stacks behave differently. Windows CryptoAPI, Java and many embedded clients have their own revocation settings, and some enterprise products can be configured to hard-fail. If you run such software, test it with a certificate that contains no OCSP URL.

What server operators should do

For most sites the shift requires no action, but a few configurations deserve a look. Start by checking which revocation pointers your certificate actually has:

openssl x509 -in cert.pem -noout -ocsp_uri
openssl x509 -in cert.pem -noout -ext crlDistributionPoints,authorityInfoAccess

• Stapling with Let's Encrypt. If -ocsp_uri prints nothing, ssl_stapling has nothing to fetch. Leaving it on is harmless; removing it avoids confusing log warnings.
• Must-Staple. Remove --must-staple or equivalent options from ACME client configs; Let's Encrypt rejects such orders.
• Internal clients. Applications that pin OCSP behaviour, such as Java with OCSP enabled or VPN gateways with strict revocation checks, must accept CRL-only certificates.
• Private PKI. Your own CA can still run OCSP. If you build one, see the private CA cookbook and publish a CRL either way.
• Key compromise. Revoke through your CA or ACME client, then replace the certificate immediately. Do not rely on revocation alone: some clients will not notice for days.

To check a live server, use openssl s_client -status and look for an OCSP response. Revocation-related browser errors are covered in NET::ERR_CERT_REVOKED.

Where revocation is heading

The long-term answer to revocation is shorter lifetimes. Under Ballot SC-081v3, the maximum lifetime of a publicly trusted TLS certificate is 200 days from March 15, 2026 and falls to 47 days from March 15, 2029; see 47-day certificates. A compromised key in a 47-day certificate is useful to an attacker for weeks rather than a year, and a 6-day certificate needs no revocation at all.

CRLs remain the authoritative source, browsers compress them into CRLSets and CRLite, and OCSP survives mainly in private PKIs and in CAs that choose to keep it. If you want to inspect any of these artifacts yourself, the OCSP and CRL cookbook walks through every command.