Certificate Revocation Deep Dive: CRL, OCSP, OCSP Stapling, and Short-Lived Certs

Certificate revocation invalidates a certificate before expiry—but Web PKI revocation rarely matches the threat model in practice: browsers soft-fail, Let’s Encrypt moved to CRL-first, and short lifetimes (including SC-081 / 47-day public TLS) shrink exposure windows. This page explains how CRL, OCSP, and stapling work, where they fail, and what to do in production.

Certificate Revocation Deep Dive: CRL, OCSP, OCSP Stapling, and Short-Lived Certs

TL;DR: Web PKI revocation is weak against MITM + blocked checks (soft-fail); stapling helps privacy/latency where OCSP URLs exist; Let’s Encrypt dropped OCSP for new certs in 2025; short TTLs and automation (47-day timeline) are the practical risk reduction.

Overview

Revocation theory: a compromised or mis-issued cert must not be trusted until natural expiry. Operational reality: clients, caches, and network attackers interact badly with online checks. Use this page with certificate lifecycle management and X.509 background.

Problem Statement

• Soft-fail lets attackers block OCSP and still get connections—users assume “green lock = safe.”
• CRL size and cache staleness delay propagation even when CRLs are correct.
• Non-browser stacks (OpenSSL, curl) often skip revocation unless explicitly configured—VPN/proxy gear may differ and break on CA policy changes.
• Stapling fails silently when responders are down—Must-Staple did not save the ecosystem.
• Short-lived certs require reliable automation—failure mode is outage, not slow revocation.
• Private PKI still uses CRL/OCSP patterns you control—different tradeoffs than browsers.

Failure scenario: Team staples OCSP for monitoring; CA migrates to CRL-only; stapling stops; nobody notices until a compliance scan flags missing stapling—while browser trust was never dependent on it.

Certificate Revocation Lists (CRL)

A CRL is a signed list of revoked certificate serial numbers published by the issuing CA. The CA periodically generates a new CRL, signs it with the CA’s private key, and publishes it at a URL specified in the certificate’s CRL Distribution Points (CDP) extension.

How CRL checking works

When a client (browser, TLS library, application) encounters a certificate, it reads the CDP extension, downloads the CRL from the specified URL, verifies the CRL’s signature against the issuing CA’s public key, and checks whether the certificate’s serial number appears in the list. If the serial number is present, the certificate is revoked.

CRLs contain: the issuer name, the date the CRL was issued (thisUpdate), the next expected CRL publication date (nextUpdate), and a list of revoked certificate entries — each containing a serial number, revocation date, and optional revocation reason code.

CRL limitations

Size: A CRL contains every revoked certificate that hasn’t yet expired. For a high-volume CA, CRLs can grow to megabytes. Let’s Encrypt’s CRLs, serving over 60% of web certificates, are sharded across multiple URLs to manage size. Downloading a multi-megabyte CRL for every TLS handshake would be impractical — so clients cache CRLs, which introduces staleness.

Latency: The gap between when a CA revokes a certificate and when the CRL is published (and cached CRLs expire) means clients may trust a revoked certificate for hours or days after revocation. CAs can publish CRLs frequently, but clients honor the nextUpdate field for caching.

Delta CRLs: To address the size problem, RFC 5280 defines delta CRLs — incremental updates that contain only changes since the last base CRL. Delta CRLs reduce download size but add implementation complexity. Not all clients support them.

CRL in practice (2026)

CRLs are experiencing a revival. Let’s Encrypt’s shift from OCSP to CRLs (completed May 2025) has forced the ecosystem to ensure CRL infrastructure is robust. Chrome uses CRLSets (a Google-curated subset of CRLs) rather than fetching CRLs directly. Firefox fetches CRLs for intermediate CA certificates (CRLite) but not for leaf certificates. For private PKI (Vault PKI, EJBCA, step-ca), CRLs remain the standard revocation mechanism.

Online Certificate Status Protocol (OCSP)

OCSP (RFC 6960) provides real-time, per-certificate revocation status. Instead of downloading a full revocation list, the client sends a request containing the certificate’s serial number to the CA’s OCSP responder and receives a signed response: “good,” “revoked,” or “unknown.”

How OCSP checking works

The client reads the Authority Information Access (AIA) extension in the certificate to find the OCSP responder URL. It constructs an OCSP request containing the issuer name hash, issuer key hash, and certificate serial number. The OCSP responder looks up the certificate’s status in the CA’s database and returns a signed response.

The response includes: the certificate status, a timestamp (thisUpdate), an optional nextUpdate (for caching), and the responder’s signature. OCSP responses are typically valid for hours to days, and clients cache them.

Why OCSP failed in the Web PKI

Privacy: Every OCSP check tells the CA exactly which website the user is visiting, from the user’s IP address. Let’s Encrypt’s OCSP responders handled approximately 12 billion requests per day. Even with no intent to track users, CAs could be legally compelled to log this data.

Soft-fail: The critical flaw. When a browser cannot reach the OCSP responder (network error, timeout, responder down), most browsers proceed with the connection anyway. This is “soft-fail” — the revocation check fails silently. An attacker who has compromised a certificate’s private key and is in a man-in-the-middle position can simply block the OCSP request, and the browser connects to the attacker’s server without checking revocation. Soft-fail makes OCSP security theater against the exact attack it’s designed to prevent.

Latency: An OCSP check adds a round trip to the CA’s responder during the TLS handshake, increasing connection latency by 100-300ms. For performance-sensitive applications, this is significant.

Availability: The OCSP responder becomes a single point of failure for every certificate it serves. If the responder goes down, all clients checking revocation against it either fail open (soft-fail) or refuse connections (hard-fail). Neither outcome is acceptable at scale.

Let’s Encrypt’s OCSP deprecation timeline

Let’s Encrypt announced the end of OCSP support in December 2024. The timeline: January 30, 2025 — OCSP Must-Staple requests fail for most accounts. May 7, 2025 — OCSP URLs removed from newly issued certificates, replaced with CRL URLs. August 6, 2025 — OCSP services shut down entirely.

After August 2025, Let’s Encrypt certificates contain no OCSP responder URL. OCSP stapling has no effect on these certificates. Revocation status is available only via CRLs. For systems that relied on OCSP checking for Let’s Encrypt certificates (some VPN concentrators, non-browser TLS clients), this is a breaking change that requires configuration updates.

OCSP stapling

OCSP stapling (RFC 6066) addresses the privacy and latency problems of standard OCSP by moving the OCSP query from the client to the server. The web server periodically fetches the OCSP response from the CA’s responder and includes (“staples”) it in the TLS handshake’s Certificate Status message.

How OCSP stapling works

The server fetches the OCSP response for its own certificate from the CA’s OCSP responder (typically every few hours). When a client initiates a TLS handshake and requests the certificate status (via the status_request TLS extension), the server includes the pre-fetched OCSP response. The client verifies the OCSP response’s signature and timestamp without contacting the CA.

Configuration

Nginx:

server {
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
    resolver 8.8.8.8 1.1.1.1 valid=300s;
    resolver_timeout 5s;
}

Apache:

SSLUseStapling On
SSLStaplingCache "shmcb:/tmp/stapling_cache(128000)"
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

Verification:

openssl s_client -connect yourdomain.com:443 -status </dev/null 2>/dev/null \
  | grep -A 5 "OCSP Response"
# Look for: OCSP Response Status: successful (0x0)

OCSP stapling failure modes

Stale staple: If the server cannot reach the OCSP responder to refresh the stapled response, it serves a stale (expired) response or no response. Nginx fails silently — it stops stapling and the client falls back to direct OCSP or soft-fail.

First request problem: On server startup or certificate reload, the first TLS handshake may not include a stapled response because the server hasn’t fetched one yet. Nginx fetches the OCSP response lazily on the first request.

Must-Staple: The OCSP Must-Staple certificate extension (RFC 7633) told browsers to require a stapled OCSP response — if the server didn’t staple, the browser should refuse to connect (hard-fail). This was the promise of making OCSP actually work. In practice, Must-Staple failed: browser support was incomplete, server implementations were unreliable (creating unnecessary outages), and Let’s Encrypt removed Must-Staple support entirely in January 2025.

OCSP stapling relevance in 2026

For certificates issued by Let’s Encrypt after May 2025, OCSP stapling does not apply — there is no OCSP URL to staple from. For certificates from other CAs (DigiCert, Sectigo, GlobalSign) that still include OCSP URLs, stapling remains a valid performance and privacy optimization. For private PKI certificates where OCSP responders are under your control, stapling is effective and recommended.

Short-lived certificates: passive revocation

The emerging alternative to active revocation is to issue certificates with lifetimes so short that revocation is unnecessary. If a certificate is valid for 6 hours, a compromised key can only be abused for at most 6 hours — less time than most revocation mechanisms take to propagate.

How short-lived certificates work

The CA issues certificates with validity periods of hours to days instead of months. When the certificate expires, the client rejects it. No CRL, no OCSP, no revocation infrastructure. The CA/B Forum Baseline Requirements define “short-lived” as 7 days or less (as of March 2026) and exempt short-lived certificates from CRL/OCSP requirements.

Let’s Encrypt offers 6-day certificates in general availability since January 2026. step-ca is architecturally designed for short-lived certificates — its default configuration favors 24-hour lifetimes with automated renewal. Vault PKI typically issues certificates with TTLs measured in hours for service-to-service communication.

Tradeoffs

Requires automation: If your renewal pipeline fails, your certificate expires within hours or days — not months. There is no manual recovery window. The automation must be robust.

Higher issuance volume: A 24-hour certificate renewed at 2/3 lifetime means a new certificate every 16 hours per endpoint. At scale, this is significant load on the CA and the deployment pipeline.

No revocation for specific cause: If a key is compromised, you cannot revoke the certificate early — you must wait for natural expiration. For a 6-day certificate, the maximum exposure window is 6 days. For a 24-hour certificate, it’s 24 hours. Whether this is acceptable depends on your threat model.

Offline resilience: If the CA is unreachable, certificates expire and are not renewed. Long-lived certificates with active revocation provide a longer buffer against CA outages.

Axelspire’s position

For internal infrastructure (service mesh, Kubernetes workloads, API-to-API communication), short-lived certificates issued by a private CA (step-ca, Vault PKI) are the most effective revocation strategy available. The blast radius of a compromised key is bounded by the certificate lifetime, and the operational complexity of CRL/OCSP infrastructure is eliminated entirely.

For publicly trusted certificates served to browsers, active revocation (CRLs) remains necessary because you don’t control when the certificate is cached by clients or intermediary devices. But the direction under SC-081v3 — driving certificate lifetimes down to 47 days, then potentially shorter — is converging toward the same principle: shorter lifetimes reduce the value of revocation by reducing the window of exposure.

Revocation in practice: what browsers actually do

The most important thing for engineers to understand about revocation is that browser behavior does not match the theoretical model. Here is what actually happens as of March 2026:

Chrome: Does not perform live OCSP checks. Does not fetch CRLs directly. Uses CRLSets — a compressed subset of revoked certificates curated by Google and distributed via Chrome component updates. CRLSets cover high-priority revocations (CA incidents, high-profile compromises) but not the full revocation set. Chrome also uses CRLite (experimental) for broader coverage.

Firefox: Uses CRLite for intermediate CA revocation checking. For leaf certificates, Firefox performs OCSP checks by default with soft-fail. If the OCSP responder is unreachable, Firefox proceeds with the connection. Firefox is transitioning away from live OCSP checking.

Safari: Performs OCSP checks with soft-fail behavior. Apple’s revocation checking is opaque — details of CRL/OCSP behavior are not publicly documented in the same detail as Chrome or Firefox.

Non-browser clients: OpenSSL, curl, and most TLS libraries do not check CRLs or OCSP by default. You must explicitly enable revocation checking in your application configuration. Many VPN concentrators and enterprise TLS proxies do perform active revocation checking — and were impacted by Let’s Encrypt’s OCSP deprecation.

The practical implication: for web-facing certificates, revocation provides weak security guarantees against a sophisticated attacker. The industry’s response — shorter certificate lifetimes, faster issuance automation, and eventually passive revocation via short-lived certificates — addresses the root cause rather than patching the broken revocation system.

Operational checklist

• Know whether your CA still publishes OCSP in AIA—if not, disable stapling monitoring alerts that assume OCSP.
• For non-browser clients, explicitly configure CRL/OCSP or accept no live revocation.
• Prefer short TTL + automation for internal workloads; validate renewal SLOs (certificate automation readiness).
• After CA policy changes, regression-test VPN, IoT, and mTLS stacks that hard-pinned OCSP.
• Document incident playbooks: revoke + re-issue + cache busting for CDNs where applicable.

Related documentation

• 47-day TLS certificates — SC-081v3 lifetimes and automation pressure
• Certificate lifecycle management — Revocation in operational context
• Renewal automation — Automation as the real control
• X.509 standard — CDP, AIA, extensions
• TLS protocol — Handshake and certificate messages
• Common vulnerabilities — Revocation checking pitfalls in code
• mTLS configuration — Short-lived mesh certs and passive revocation
• cert-manager for Kubernetes — Renewal and ARI in clusters