What Is a Certificate Revocation List? CRL, OCSP, and the Evolving State of Revocation in 2026

An SSL certificate has an expiry date: a defined point in the future when it stops being trusted. Expiry handles the normal case. Revocation handles the emergency case: what happens when a certificate must be invalidated before its expiry date because the private key was compromised, the certificate was mis-issued, or the certificate holder’s circumstances changed?

The Certificate Revocation List was the original answer to this question. A CRL is a signed file published by a Certificate Authority that lists the serial numbers of every certificate it has revoked before their scheduled expiry. Browsers and other TLS clients download this list and check incoming certificates against it. If a certificate’s serial number appears on the list, the connection is blocked.

The CRL mechanism works in principle. In practice it has produced decades of partial solutions, workarounds, edge cases, and one major 2025 industry shift: Let’s Encrypt, which issues approximately half of all active TLS certificates, shut down its OCSP infrastructure entirely in August 2025, moving exclusively to CRL-based revocation. This article covers how each piece of the revocation infrastructure works, why none of it works as well as intended in browsers, and where the industry is heading.

How a Certificate Revocation List Works

A CRL is a DER-encoded file signed by the Certificate Authority. Its structure is defined in RFC 5280. Each entry in the list contains the serial number of a revoked certificate, the revocation date, and optionally a reason code explaining why the certificate was revoked.

Revocation reason codes

RFC 5280 defines nine revocation reason codes that CAs can include with each revocation:

The reason code is advisory: it informs the client about why revocation occurred but does not change the treatment. Any revoked certificate, regardless of reason code, is rejected. The practical value of reason codes is in audit trails and incident documentation.

CRL distribution points

Every publicly trusted TLS certificate includes one or more CRL Distribution Point (CDP) URIs in the certificate’s extensions. These URIs point to the CRL files the CA publishes, typically as HTTP URLs. When a client needs to verify a certificate’s revocation status, it downloads the CRL from the CDP URI and checks whether the certificate’s serial number appears in it.

CRL files are signed by the CA and have their own expiry dates. A client that downloads a CRL can cache it until it expires, avoiding repeated downloads for certificates from the same CA. CRL expiry periods vary by CA and certificate type: publicly trusted certificate CRLs are typically updated every 24 hours or less; enterprise CAs may publish less frequently.

CRL files can become very large. A CA that has issued millions of certificates and revoked a significant fraction of them publishes a CRL that may be megabytes in size. Downloading megabytes of data for each TLS connection is not practical for browsers. This size problem is one of the primary motivations for OCSP, and later for CRLSets and short-lived certificates.

Delta CRLs

Delta CRLs are incremental updates: rather than the full list of all revoked certificates, a delta CRL contains only the certificates revoked since the last complete CRL was published. Clients that already have a cached base CRL can download only the delta to update it, reducing bandwidth consumption. Delta CRLs are defined in RFC 5280 and implemented by most enterprise CAs, but have limited adoption in public CA infrastructure.

The Limitations of CRL-Based Revocation

CRLs have three fundamental limitations that motivated the development of OCSP and that still affect revocation effectiveness today.

Propagation delay

CRLs are published on schedules, not in real time. When a CA revokes a certificate due to private key compromise, the updated CRL is not available until the next scheduled publication, which may be hours away. During that window, the revoked certificate passes CRL-based revocation checks because the checking client’s cached CRL does not yet contain the revocation. For severe incidents involving key compromise, this delay represents a period where the compromised certificate is still trusted by all CRL-based clients.

Size at scale

A CA issuing hundreds of millions of certificates accumulates a large revocation list over time. The CRL grows with each revocation and is trimmed only as revoked certificates reach their expiry dates. For large CAs, full CRL download is impractical for clients performing this check on every connection. The download latency alone adds unacceptable overhead to the TLS handshake.

Availability dependency

A client that cannot reach the CRL distribution point has two options: fail open (assume the certificate is not revoked and allow the connection) or fail closed (block the connection because revocation status cannot be confirmed). Failing open means revocation checking adds no security when the CRL server is unreachable. Failing closed means any network disruption affecting the CRL distribution point breaks all TLS connections that depend on it. Most clients default to failing open.

OCSP: The Real-Time Alternative to CRL

OCSP (Online Certificate Status Protocol, defined in RFC 6960) was designed to address the size and propagation delay problems of CRLs. Rather than downloading a list of all revoked certificates, the client sends a query for one specific certificate’s status to the CA’s OCSP responder and receives a signed response containing the status: good, revoked, or unknown.

OCSP responses are small (a few hundred bytes versus potentially megabytes for a CRL), and the CA’s responder reflects revocations as soon as they are processed rather than waiting for the next CRL publication cycle. For time-sensitive revocations, OCSP provides substantially faster propagation than CRL.

OCSP limitations

OCSP introduced new problems alongside its improvements.

Privacy exposure: every OCSP query tells the CA which website a user is visiting, at what time, from what IP address. The CA builds a profile of user browsing behavior through OCSP request logs. This is not a theoretical concern; it is a direct privacy cost that attracted significant criticism and motivated OCSP stapling.

Single point of failure: the OCSP responder must be available and responsive for revocation checking to function. A responder that is down or slow degrades to the same soft-fail behavior as an unreachable CRL server. At scale, a single OCSP responder serves queries for millions of certificates, and its availability directly affects the TLS performance of every site that uses it.

Soft-fail is the security-defeating default: browsers implement soft-fail for OCSP, meaning that if the OCSP responder cannot be reached, the browser allows the connection to proceed without confirmed revocation status. This is deliberate: hard-fail OCSP would break the web every time a CA’s OCSP infrastructure experienced any disruption. But soft-fail means that an attacker who can block the client’s network access to the OCSP responder silently bypasses revocation checking. The browser shows no error; the revoked certificate is accepted.

OCSP soft-fail is not a minor edge case. It means revocation checking provides no security guarantee against a network-positioned attacker. An attacker performing a man-in-the-middle attack who also blocks the OCSP responder’s IP address prevents the client from receiving the revocation signal for the compromised certificate being used in the attack. The browser fails open and accepts the connection. This fundamental limitation has been known since OCSP was deployed and motivated both OCSP stapling and the move toward short-lived certificates.

OCSP Stapling: Solving Privacy and Performance

OCSP stapling, defined in RFC 6066, inverts the OCSP query model. Rather than the client querying the CA’s OCSP responder, the server periodically fetches its own OCSP response and includes it in the TLS handshake as a stapled attachment. The client receives the revocation status from the server without making any separate network request.

This eliminates the privacy problem (the CA never sees individual client queries, only server queries), removes the per-connection latency overhead (no additional network round trip), and shifts the OCSP infrastructure load from millions of clients to the server itself. For a site with significant traffic, the server fetches one OCSP response periodically and serves it to all connecting clients, vastly reducing CA infrastructure load compared to per-client OCSP queries.

OCSP stapling server configuration

Enabling OCSP stapling requires server-side configuration. In Nginx:

In Apache 2.3.3 and later, add SSLUseStapling on and SSLStaplingCache to the server or virtual host configuration.

OCSP stapling limitations

Stapling shifts the failure mode: if the server cannot obtain a fresh OCSP response before the previous one expires, the TLS handshake either proceeds without a stapled response (clients fall back to direct OCSP queries or soft-fail) or connections fail if OCSP Must-Staple is configured in the certificate. The server becomes responsible for reliably fetching and serving OCSP responses, which is a new operational dependency.

OCSP stapling is available only for server certificates, not for client certificates used in mTLS, EAP-TLS, or 802.1X authentication. These client certificate use cases still depend on CRL or direct OCSP queries.

How Chrome Actually Handles Revocation: CRLSets

Chrome does not perform real-time CRL or OCSP checks for most certificates. Instead, Chrome uses CRLSets: a curated, compressed list of revoked certificates pushed to browsers as a component update, independent of browser version updates. CRLSets are updated by Google’s Chrome security team and pushed to Chrome installations worldwide within hours of a significant revocation event.

CRLSets only include high-priority revocations: certificates where the revocation is security-critical, such as compromised CA certificates, mis-issued certificates for high-profile targets, or certificates involved in known attacks. The vast majority of individual TLS certificate revocations never appear in CRLSets. Chrome allows connections using these revoked certificates because they are not in the CRLSet and Chrome does not perform per-connection CRL or OCSP checks.

The practical implication: for most revoked TLS certificates, Chrome does not enforce the revocation. Security guarantees from certificate revocation in Chrome apply only to the small category of certificates that Google considers important enough for CRLSet inclusion. This is a deliberate engineering tradeoff: CRLSet-based revocation is reliable and fast because it is always cached locally; per-connection revocation checking is unreliable because of soft-fail behavior.

Firefox, Safari, and Edge have different revocation checking behaviors from Chrome. Firefox performs CRL and OCSP checks with soft-fail behavior and has its own OneCRL list (similar to Chrome’s CRLSets). Safari performs OCSP checks with soft-fail. The inconsistency across browsers means there is no single universal statement about how revocation is enforced. For the specific security guarantee that a revoked certificate is rejected, none of the major browsers provide it reliably for ordinary TLS certificates through standard revocation mechanisms.

The 2025 Industry Shift: Let’s Encrypt Ends OCSP

Let’s Encrypt issues approximately half of all active TLS certificates. In December 2024, it announced it would discontinue OCSP support entirely and move to CRL-only revocation. The timeline:

• January 30, 2025: OCSP Must-Staple requests began failing for most accounts
• May 7, 2025: OCSP URLs removed from newly issued Let’s Encrypt certificates; CRL URLs added instead
• August 6, 2025: Let’s Encrypt OCSP services shut down entirely

Let’s Encrypt’s stated reasons for the change: CRLs have significant advantages over OCSP. OCSP infrastructure requires high availability at scale (every client performing OCSP checks for Let’s Encrypt certificates hits their responders, creating massive infrastructure load). CRLs can be distributed via CDN and cached efficiently. OCSP causes privacy concerns through responder query logs. OCSP soft-fail behavior means the security value is limited. For a CA at Let’s Encrypt’s scale, OCSP was operationally expensive and delivered limited security benefit.

Systems that relied on OCSP for Let’s Encrypt certificate revocation checking were broken by this change. Affected systems include VPN concentrators and network access servers that perform active OCSP checking, TLS proxy appliances, enterprise firewall products performing SSL inspection, and any custom application that explicitly configures OCSP checking. These systems need to be reconfigured to use CRL-based checking for Let’s Encrypt certificates. OCSP stapling configuration also has no effect on Let’s Encrypt certificates issued after May 2025.

The Direction the Industry Is Heading: Short-Lived Certificates

The underlying problem with all revocation mechanisms is that they attempt to retract trust for certificates that were issued with multi-month or multi-year validity. The broader the validity window, the more important it is to have a reliable revocation mechanism, and the harder that is to achieve at scale with acceptable latency.

The alternative approach gaining industry momentum: reduce certificate validity periods so that revocation becomes less critical. If a certificate expires in 47 days, a revoked certificate’s window of harm is capped at 47 days in the worst case. If a certificate expires in a few days, effective revocation becomes academic for most scenarios.

The CA/B Forum approved validity reduction to 47 days by March 2029 (Ballot SC-081v3). Some security researchers and browser vendors have advocated for even shorter validity periods approaching 7 days for certificates where automated issuance and renewal is established. At these validity periods, revocation infrastructure addresses edge cases rather than being a primary security control.

Short-lived certificates shift the security model entirely: rather than managing revocation of long-lived certificates, you ensure automated renewal is reliable and that a compromised certificate expires quickly. ACME protocol automation (Certbot, acme.sh, ACME clients built into load balancers and CDNs) has made automated renewal operationally feasible at scale. The industry is converging on a model where short validity plus automated renewal replaces the revocation checking infrastructure that has always had reliability and performance problems.

Revocation Mechanisms: A Comparison

Frequently Asked Questions

What is a Certificate Revocation List?

A Certificate Revocation List (CRL) is a signed file published by a Certificate Authority that lists the serial numbers of all certificates the CA has revoked before their scheduled expiry date. Each entry includes the certificate’s serial number, the revocation date, and optionally a reason code. Clients that need to verify a certificate’s status download the CRL from the distribution point URL included in the certificate and check whether the certificate’s serial number appears in it.

What is the difference between CRL and OCSP?

A CRL is a full list of all revoked certificates from a CA, downloaded and cached by the client. It can be large and is updated on a schedule, not in real time. OCSP (Online Certificate Status Protocol) is a query protocol: the client asks the CA’s responder about one specific certificate and receives a real-time signed response. OCSP responses are smaller and more current than cached CRLs, but OCSP requires a live connection to the CA’s responder and creates privacy concerns because the CA can log all queries. OCSP stapling, where the server fetches and serves the OCSP response itself, addresses the privacy and latency problems.

Why did Let’s Encrypt stop supporting OCSP?

Let’s Encrypt shut down OCSP services in August 2025 and moved to CRL-only revocation for several reasons: OCSP infrastructure requires high availability at massive scale (every client checking revocation for Let’s Encrypt certificates queries their responders), CRLs can be distributed via CDN and cached more efficiently, OCSP creates privacy concerns through query log visibility, and OCSP soft-fail behavior means a blocked responder silently allows revoked certificates through. CRLs provide better scaling and are a technically sufficient alternative given the limitations of OCSP in practice.

Does Chrome check certificate revocation?

Not in the way most people assume. Chrome does not perform per-connection CRL or OCSP checks for most TLS certificates. Instead, Chrome uses CRLSets: a curated list of high-priority revocations pushed by Google as a browser component update. CRLSets include only certificates Google considers security-critical, such as compromised CA certificates or certificates involved in known attacks. Most revoked TLS certificates are not in CRLSets, and Chrome allows connections using those revoked certificates without any revocation check. This is a deliberate tradeoff: CRLSet-based revocation is reliable because it is always locally cached; per-connection checks are unreliable because soft-fail behavior allows revoked certificates through when the checking infrastructure is unreachable.

What happens if a CRL distribution point is unreachable?

Most clients default to soft-fail: if the CRL cannot be downloaded, the certificate is assumed to be valid and the connection proceeds. This is a deliberate design choice to prevent widespread connection failures during CA infrastructure outages. The security tradeoff is that an attacker who can block access to the CRL distribution point (by DNS poisoning, network filtering, or other means) prevents revocation checking from occurring, allowing a revoked certificate to be used as if it were valid. Hard-fail configurations, which block connections when revocation status cannot be confirmed, exist but are rarely deployed in browser contexts because they produce unacceptable availability impacts.

Are short-lived certificates replacing revocation?

For web-facing TLS certificates, yes, progressively. The CA/B Forum has approved validity reduction to 47 days by March 2029. At very short validity periods, the security value of revocation checking diminishes because an attacker exploiting a compromised certificate faces a hard expiry deadline. Automated renewal via ACME protocol (Let’s Encrypt, ZeroSSL, and others) makes frequent certificate replacement operationally feasible. For enterprise PKI and client certificate use cases where automated renewal is less established, CRL and OCSP-based revocation remain important. Short-lived certificates are not yet universal, but they represent the direction browser security policy is pushing the industry.