How OCSP and CRL Work: Certificate Revocation Explained

OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) are the two mechanisms that allow clients to check whether a TLS certificate has been revoked before its natural expiration date. Certificates get revoked when private keys are compromised, when a CA discovers it misissued a certificate, or when domain ownership changes. Without revocation checking, a stolen private key would remain usable until the certificate expires -- potentially months or years. In practice, the revocation ecosystem is one of the most broken parts of the web PKI: browsers disagree on whether to check, CAs disagree on how to publish, and the entire system is riddled with soft-fail semantics that undermine the security it was designed to provide.

Why Certificates Need Revocation

An X.509 certificate binds a public key to an identity (typically a domain name) for a fixed validity period. When the CA signs the certificate, it is asserting: "this public key belongs to this entity, and this assertion is valid from date X to date Y." But many things can go wrong before date Y arrives:

Key compromise -- the private key corresponding to the certificate is stolen or leaked. The Heartbleed vulnerability (CVE-2014-0160) in April 2014 potentially exposed millions of private keys, triggering a mass revocation event that overwhelmed existing revocation infrastructure.
CA misissue -- the CA issued a certificate without proper domain validation. Certificate Transparency has made these incidents more visible, but once a bad certificate is discovered, it must be revoked.
Domain ownership change -- the domain is sold or transferred, and the new owner should not inherit a certificate with the previous owner's key.
Certificate supersession -- the certificate is replaced by a new one (e.g., during key rotation), and the old one should be invalidated.
Affiliation change -- the subject's relationship with the organization named in the certificate has ended.

RFC 5280 defines several revocation reason codes: keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, and certificateHold (a temporary suspension). In practice, most CAs mark revocations as unspecified or keyCompromise, and few clients distinguish between reasons.

CRL: Certificate Revocation Lists

CRLs are the original revocation mechanism, defined in X.509 v2 and formalized for the internet in RFC 5280. A CRL is a signed, timestamped document published by a CA that lists all certificates the CA has revoked but that have not yet expired. Conceptually, it is simple: the CA periodically publishes a list of serial numbers, and clients download the list and check whether the certificate they are validating appears on it.

CRL Structure

A CRL is an ASN.1 DER-encoded structure containing:

Version -- v2 (integer value 1) for modern CRLs with extensions
Signature algorithm -- the algorithm used by the CA to sign the CRL (e.g., SHA-256 with RSA)
Issuer -- the distinguished name of the CA that issued the CRL
thisUpdate -- the timestamp when this CRL was published
nextUpdate -- the time by which the next CRL will be published (optional but effectively required)
revokedCertificates -- a sequence of entries, each containing a serial number, revocation date, and optional extensions (reason code, invalidity date, etc.)
CRL extensions -- authority key identifier, CRL number (monotonically increasing), delta CRL indicator, issuing distribution point

CRL Distribution Points

Certificates contain a CRL Distribution Points (CDP) extension that tells clients where to download the CRL. This is typically an HTTP URL (not HTTPS -- the CRL is self-authenticating via the CA's signature, so TLS is unnecessary and would create a circular dependency). For example:

X509v3 CRL Distribution Points:
    Full Name:
        URI:http://crl.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crl

Some certificates list multiple distribution points for redundancy, including LDAP URIs for enterprise environments. The client downloads the CRL, verifies the CA's signature, checks that the CRL has not expired (current time is between thisUpdate and nextUpdate), and then searches the list for the certificate's serial number.

The Scaling Problem

CRLs worked adequately when CAs issued thousands of certificates. They fail catastrophically at modern scale. Consider: Let's Encrypt has issued billions of certificates. A CRL containing serial numbers for all revoked certificates that haven't yet expired would be enormous. Even with compact encoding, each entry is roughly 30-40 bytes (serial number, date, reason). A CRL with 10 million entries would be over 300 MB. Every client connecting to a site for the first time would need to download this list -- a latency penalty that would make web browsing noticeably slower.

Even smaller CAs produce CRLs that are problematic. Historically, DigiCert and Comodo CRLs regularly reached several megabytes -- a significant download for mobile devices on slow connections. CRL checking adds latency to the first connection to any new site: the client must download the CRL before completing the TLS handshake (or at least before trusting the certificate).

Delta CRLs

RFC 5280 defines delta CRLs as a mitigation for the size problem. A delta CRL contains only the changes since a specific base CRL (identified by the base CRL's CRL number). Clients download the full base CRL periodically, then apply smaller delta CRLs between full updates. The delta CRL extension (deltaCRLIndicator) references the CRL number of the base.

In theory, delta CRLs reduce bandwidth significantly. In practice, they were rarely implemented by clients. Neither Chrome, Firefox, nor Safari ever supported delta CRLs. The complexity of managing base and delta CRL states, handling edge cases around mismatched CRL numbers, and the availability of OCSP as an alternative made delta CRLs effectively dead on the web. They see some use in enterprise PKI environments where the client base is controlled.

OCSP: Online Certificate Status Protocol

OCSP, defined in RFC 6960 (originally RFC 2560), was designed to solve the problems with CRLs by providing real-time, per-certificate revocation status checks. Instead of downloading an entire list of revoked certificates, the client sends a query about a specific certificate and gets back a signed response indicating whether it is good, revoked, or unknown.

How OCSP Works

The protocol is straightforward. The client constructs an OCSP request containing the hash of the issuer's name, the hash of the issuer's public key, and the serial number of the certificate in question. It sends this request to the OCSP responder URL specified in the certificate's Authority Information Access (AIA) extension:

Authority Information Access:
    OCSP - URI:http://ocsp.digicert.com
    CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt

The OCSP responder returns a signed response containing:

certStatus -- one of good (not revoked), revoked (includes revocation time and optional reason), or unknown (responder doesn't know about this certificate)
thisUpdate -- when this status information was generated
nextUpdate -- when the client should check again
producedAt -- when the response was signed
responderID -- identifier of the OCSP responder

The response is signed by either the CA's own key or a delegated OCSP signing key (a certificate with the id-kp-OCSPSigning extended key usage). The delegated model is more common because it allows the OCSP responder to operate without direct access to the CA's root or intermediate private key.

Privacy and Performance Problems

OCSP introduces serious issues that CRLs avoid:

Privacy leakage -- every OCSP query tells the CA's responder which sites the user is visiting. The responder sees the client's IP address and the certificate serial number. For a large CA like Let's Encrypt (which issues certificates for hundreds of millions of domains), the OCSP responder becomes a panopticon of browsing behavior.
Availability dependency -- if the OCSP responder is down or unreachable, clients must choose between blocking the connection (hard-fail) or proceeding without revocation information (soft-fail). An attacker who can block access to the OCSP responder (via a BGP hijack, DNS manipulation, or simple network filtering) can suppress revocation checks entirely.
Latency cost -- each new TLS connection requires an additional round trip to the OCSP responder before the handshake can complete. On high-latency connections, this can add 100-300 ms to the first page load. The OCSP round trip is serialized with the TLS handshake -- the client cannot trust the certificate until it has verified revocation status.

OCSP Stapling: The Server-Side Fix

OCSP stapling, defined in RFC 6066 (as the TLS Certificate Status Request extension) and extended in RFC 6961, moves the OCSP query from the client to the server. Instead of the client contacting the OCSP responder, the server periodically fetches its own OCSP response and includes ("staples") it in the TLS handshake.

The mechanics are simple: the server fetches an OCSP response for its own certificate, caches it, and sends it to clients during the TLS handshake via the CertificateStatus message (TLS 1.2) or the Certificate extension (TLS 1.3). Because OCSP responses include a nextUpdate field, the server can cache and reuse the same response for hours or days. The client validates the response's signature and freshness, getting revocation assurance without any extra network round trip.

OCSP stapling solves the privacy and latency problems simultaneously:

No privacy leak -- the OCSP responder sees the server's IP address, not the client's. The server would be fetching its own certificate status regardless, so no new information is revealed.
No extra latency -- the OCSP response piggybacks on the TLS handshake. Zero additional round trips.
Reduced responder load -- instead of millions of clients querying the responder, only the server queries it periodically. A site with 10 million daily visitors generates one OCSP query every few hours instead of 10 million.

Stapling in Practice

Server software support for OCSP stapling is widespread. In Apache, you enable it with SSLUseStapling on and configure a response cache. In Nginx, you set ssl_stapling on and ssl_stapling_verify on. Caddy staples by default. However, correct implementation has historically been buggy. Common problems include:

Servers failing to refresh the stapled response before it expires, causing clients to see stale OCSP data
Servers silently dropping stapling when the OCSP responder is temporarily unavailable, rather than serving a cached (still valid) response
Multi-certificate deployments (e.g., RSA + ECDSA) where only one certificate's OCSP response is stapled
CDN edge servers that don't maintain OCSP response caches across restarts or reconfigurations

OCSP Must-Staple

OCSP stapling has an Achilles' heel: it is optional. If a server does not staple an OCSP response, the client falls back to querying the OCSP responder directly -- or, more commonly, skips the check entirely (soft-fail). An attacker using a revoked certificate can simply not staple an OCSP response and rely on the client's soft-fail behavior.

The OCSP Must-Staple extension (RFC 7633, formally called the TLS Feature extension with value status_request) is an X.509 certificate extension that tells the client: "this certificate requires a stapled OCSP response. If the server does not staple one, reject the connection." The extension is requested at certificate issuance time and baked into the certificate itself.

X509v3 TLS Feature:
    status_request

With Must-Staple, a revoked certificate is genuinely unusable: the legitimate CA will return a revoked OCSP response, the attacker cannot obtain a good response, and the client will reject any connection that lacks a stapled response. This transforms OCSP from a soft-fail advisory into a hard-fail gate.

However, Must-Staple adoption has been extremely low. The risks are significant: if a server misconfigures stapling or the OCSP responder has an extended outage, all clients will refuse to connect -- a complete site outage caused by revocation infrastructure failure. Most site operators consider this risk unacceptable. Let's Encrypt supports issuing Must-Staple certificates, but fewer than 1% of their certificates use the extension.

Soft-Fail vs Hard-Fail: The Browser Dilemma

The fundamental question of certificate revocation is what to do when the revocation check cannot be completed. This is not a theoretical concern -- OCSP responders go down, CRL servers become unreachable, and network middleboxes block unexpected HTTP requests. Browsers have taken two approaches:

Hard-fail means refusing the connection if revocation status cannot be determined. This is the secure choice: it prevents an attacker from suppressing revocation checks. But it also means that any OCSP responder outage or network issue blocks users from accessing the site. Firefox briefly experimented with hard-fail for OCSP in the early 2010s and quickly abandoned it after widespread user complaints about sites becoming inaccessible.

Soft-fail means proceeding with the connection if revocation status cannot be determined. This is the usable choice: users can always access sites. But it completely defeats the purpose of revocation checking. An attacker who controls the network path (e.g., via a BGP hijack) can block the OCSP query and present a revoked certificate. The client, unable to reach the OCSP responder, shrugs and accepts the certificate anyway. As Adam Langley (Chrome security lead) wrote: "soft-fail revocation checks are like a seatbelt that snaps when you crash."

The result is a stalemate. No mainstream browser uses hard-fail for online revocation checks. Chrome abandoned OCSP checking entirely in 2012. Firefox checks OCSP but soft-fails. Safari checks OCSP but soft-fails. Every browser handles EV (Extended Validation) certificates differently. The practical security value of online revocation checking in browsers is close to zero.

Chrome's Approach: CRLSets

Rather than rely on broken online revocation checking, Chrome developed CRLSets -- a curated, compressed set of revoked certificates that is pushed to every Chrome installation via the component update system. Google maintains CRLSets by aggregating CRLs from major CAs, filtering for high-priority revocations (typically intermediate CA certificates and high-profile end-entity certificates), and compressing the result into a compact binary format.

CRLSets are updated roughly every few hours and are typically around 250 KB. Because they are pushed to the client proactively, they require no network request at connection time -- zero latency impact. And because they cover only the most critical revocations, they remain small enough to ship to billions of Chrome installations.

The tradeoff is coverage. CRLSets deliberately do not include every revoked certificate. Google has stated that CRLSets primarily cover intermediate CA revocations and "emergency" end-entity revocations. A typical end-entity certificate revoked for routine key rotation may not appear in CRLSets. This is a pragmatic engineering decision: covering every revocation at Google's scale would make CRLSets too large, and the marginal security value of catching routine revocations is low (the certificate will expire soon anyway).

Mozilla's CRLite: Compressed Revocation at Scale

Mozilla developed CRLite as a more ambitious alternative to CRLSets. Instead of curating a subset of revocations, CRLite aims to encode the revocation status of every certificate on the web in a compact data structure that can be shipped to every Firefox installation.

CRLite uses cascading Bloom filters to achieve extraordinary compression. A Bloom filter is a probabilistic data structure that can answer "is this element in the set?" with no false negatives (if it says "not in the set," the element is definitely not there) but possible false positives (it might incorrectly say "in the set"). By layering Bloom filters -- a primary filter for revoked certificates, a secondary filter for false positives from the first, a tertiary filter for false positives from the second, and so on -- CRLite can encode millions of revocation entries in roughly 1-2 MB.

The pipeline works as follows:

Mozilla aggregates all CRLs from CAs in its root program
Cross-references with Certificate Transparency logs to enumerate all currently valid certificates
Builds a cascading Bloom filter encoding the revocation status of every certificate
Generates delta updates (called "stashes") that capture changes since the last full filter
Distributes the filter and stashes to Firefox via the Remote Settings infrastructure

CRLite updates are generated every 6 hours. A full filter is roughly 1.3 MB compressed, and daily delta stashes are typically 30-50 KB each. Firefox stores these locally and can check any certificate's revocation status with a single in-memory lookup -- no network request, no latency, no privacy leak, and no soft-fail vulnerability.

CRLite has been enabled by default in Firefox since version 124 (early 2024), initially in "telemetry-only" mode and progressively moving toward enforcement. It is the most technically sophisticated approach to the revocation problem currently deployed.

OneCRL: Mozilla's Intermediate CA Revocation

Separate from CRLite, Mozilla maintains OneCRL, a curated list of revoked intermediate CA certificates. OneCRL is conceptually similar to Chrome's CRLSets but focused exclusively on intermediate CAs. When an intermediate CA is compromised or misissued, Mozilla adds it to OneCRL, which is pushed to all Firefox installations via Remote Settings.

Revoking intermediate CAs is far more critical than revoking end-entity certificates: a compromised intermediate CA can issue certificates for any domain. OneCRL ensures that even if a user cannot reach the CA's OCSP responder or CRL distribution point, the revoked intermediate will be rejected. Apple maintains a similar system for Safari, and Microsoft maintains one for Edge and Windows.

Let's Encrypt and the CRL Comeback

In a surprising reversal, Let's Encrypt announced in 2024 that it would begin publishing CRLs for all certificates, after years of relying solely on OCSP. This decision was driven by several factors:

CRLite and CRLSets need CRL data -- both Mozilla's CRLite and Chrome's CRLSets consume CRLs as input. Without CRLs from Let's Encrypt (which issues roughly half of all web certificates), these systems had incomplete revocation coverage. Let's Encrypt publishing CRLs enables CRLite to cover the entire web PKI.
OCSP infrastructure costs -- running OCSP responders that handle billions of queries per day is expensive. Let's Encrypt's OCSP infrastructure was one of their largest operational costs. CRLs, being static files served from a CDN, are dramatically cheaper to operate.
Privacy concerns -- Let's Encrypt recognized that their OCSP responders received information about which domains users were visiting. Publishing CRLs and encouraging browser-side checking (via CRLite/CRLSets) eliminates this privacy concern.

Let's Encrypt partitions its CRLs using CRL sharding -- splitting the list across multiple CRL URLs based on certificate serial number ranges. Each shard remains small enough to be practical for clients that do direct CRL checking. The CRL Distribution Point URL in each certificate points to the specific shard containing that certificate's potential revocation entry.

In 2025, Let's Encrypt further announced plans to deprecate OCSP entirely, making CRLs their sole revocation mechanism. This is enabled by the fact that all major browsers have moved away from direct OCSP checking: Chrome uses CRLSets, Firefox uses CRLite, and Safari has its own preloaded revocation list. The only clients still making direct OCSP queries are non-browser TLS implementations -- and those can transition to CRL checking or adopt OCSP stapling.

Revocation in TLS 1.3

TLS 1.3 (RFC 8446) streamlines OCSP stapling support. The status_request extension is sent in the ClientHello, and the server includes the OCSP response in the Certificate message's extensions (rather than as a separate CertificateStatus message as in TLS 1.2). TLS 1.3 also supports multiple stapled responses when the server sends multiple certificates in the chain, via the status_request_v2 mechanism -- allowing stapled OCSP responses for both the end-entity and intermediate certificates.

Importantly, TLS 1.3 does not mandate revocation checking. The protocol provides the mechanism for stapling, but leaves the policy decision to the client implementation. This is consistent with the broader trend: revocation enforcement is moving from online protocol-level checks to offline, preloaded data structures.

The State of Revocation Today

The revocation landscape in 2026 is fragmented but improving. Here is how the major browsers handle it:

Chrome -- does not check OCSP or CRLs at all. Relies entirely on CRLSets, pushed via component updates. This covers intermediate CA revocations comprehensively and high-profile end-entity revocations selectively. Chrome also evaluates OCSP Must-Staple: if a certificate has the extension and no stapled response is provided, Chrome rejects the connection.
Firefox -- uses CRLite for comprehensive offline revocation checking (enabled since Firefox 124). Also checks OCSP as a fallback for certificates not covered by CRLite. OneCRL covers intermediate CA revocations. Firefox evaluates OCSP Must-Staple.
Safari -- checks OCSP with soft-fail semantics. Apple maintains a preloaded revocation list for intermediate CAs and high-profile end-entity certificates, updated via macOS/iOS system updates. Safari supports OCSP stapling and Must-Staple.
Edge -- follows Chrome's behavior (shares the Chromium codebase). Uses CRLSets.

For non-browser TLS clients (libraries like OpenSSL, Go's crypto/tls, Rustls), revocation checking is typically the application's responsibility. OpenSSL provides OCSP and CRL checking APIs but does not enable them by default. Go's crypto/tls does not check revocation at all. Rustls supports OCSP stapling verification but does not perform online checks. This means that API calls, microservice communication, and other machine-to-machine TLS connections usually have zero revocation checking -- a significant gap in the PKI security model.

Short-Lived Certificates: Revocation by Expiration

An increasingly popular approach to the revocation problem is to make it irrelevant by using very short-lived certificates. If a certificate is valid for only 90 days (as Let's Encrypt mandates) or even shorter, the window of exposure from a compromised key is bounded. Some organizations issue certificates valid for 24 hours or less, eliminating the need for revocation infrastructure entirely -- by the time an attacker could use a stolen key, the certificate has expired.

The CA/Browser Forum voted in 2023 to progressively shorten maximum certificate lifetimes: 200 days starting March 2026, 100 days starting March 2027, and 47 days starting March 2029. Apple was the driving force behind this ballot. The rationale is explicit: shorter lifetimes reduce dependence on revocation, encourage automation (via ACME), and limit the damage from compromised keys or misissued certificates.

The logical endpoint of this trend is certificates that are valid for hours, making revocation a non-issue. This mirrors how SSH certificates are often used -- issued for the duration of a session with no revocation mechanism needed.

OCSP Response Sizes and Caching

An OCSP response is typically 1-3 KB, depending on the signature algorithm and whether the responder includes the signing certificate chain. RSA-signed responses are larger than ECDSA-signed ones. The response includes a nextUpdate field that tells clients how long the response is valid -- typically 4-7 days for most CAs, though some use shorter windows.

Caching behavior matters for stapling. A well-configured server refreshes its stapled OCSP response well before the nextUpdate timestamp, typically at 50% of the validity period. If the response expires and the server cannot reach the OCSP responder, the server should continue serving the last valid response (if within a grace period) rather than dropping stapling entirely. Poor caching implementations are a common source of TLS errors in production.

Revocation for Code Signing and S/MIME

While this article focuses on web PKI revocation, OCSP and CRL are also used for code signing certificates and S/MIME (email) certificates. These contexts have different requirements:

Code signing -- revocation must be checked at signature verification time, which may be months or years after signing. Timestamping services (RFC 3161) allow a code signature to remain valid even after the signing certificate expires or is revoked, as long as the timestamp proves the signature was created while the certificate was still valid. This makes revocation more nuanced: a certificate revoked after signing should not invalidate existing signatures.
S/MIME -- email certificates are checked when reading the message, which may be long after the certificate was valid. CRL and OCSP checking for S/MIME is more consistently implemented than for web certificates, because email clients (Outlook, Thunderbird, Apple Mail) have traditionally been more aggressive about hard-fail semantics.

Real-World Revocation Failures

Several high-profile incidents have exposed the weaknesses of revocation infrastructure:

Heartbleed (2014) -- after the OpenSSL Heartbleed vulnerability was disclosed, CAs needed to revoke millions of certificates whose private keys may have been compromised. The volume of revocations overwhelmed OCSP responders and CRL distribution infrastructure. CloudFlare reported that some CAs' CRLs grew by 10x in days, and OCSP response times degraded significantly. Many organizations delayed revocation because they feared the infrastructure could not handle the load.
GlobalSign OCSP outage (2016) -- GlobalSign accidentally created an OCSP response that marked its own intermediate CA as revoked. Because browsers soft-fail on OCSP errors but hard-fail on explicit revocation responses, this caused widespread outages for sites using GlobalSign certificates. The incident demonstrated that revocation infrastructure failures can be more damaging than the threats they protect against.
Sectigo CRL delays (2020) -- Sectigo (formerly Comodo) experienced delays in CRL publishing during a period of high revocation volume. Certificates that should have appeared on CRLs within hours remained unrevoked for days. Organizations relying on CRL-based checking (including some enterprise security products) continued to trust certificates that the CA had intended to revoke.

Certificate Revocation and BGP Security

Certificate revocation intersects with BGP security in several ways. RPKI (Resource Public Key Infrastructure) uses its own revocation mechanisms -- RPKI certificates include CRL distribution points and AIA extensions pointing to repositories maintained by Regional Internet Registries. If an RPKI certificate is revoked, the corresponding Route Origin Authorization (ROA) is no longer valid, potentially affecting routing decisions across the internet.

BGP hijacking can also be used to suppress revocation checks. An attacker who hijacks the IP prefix of an OCSP responder or CRL distribution point can return bogus responses (or simply drop the traffic), preventing clients from discovering that a certificate has been revoked. This is one of the strongest arguments for offline revocation mechanisms like CRLite and CRLSets -- they are immune to network-level attacks because the data is already present on the client.

You can examine the BGP routing for CAs' OCSP and CRL infrastructure using the god.ad BGP Looking Glass -- look up the IP addresses of OCSP responders to see which networks carry their traffic and how resilient the routing is to hijack attempts.