Certificate Revocation Strategy: When "Revoke" Is Theatre and When It Actually Matters

Here's an uncomfortable truth about certificate revocation: for the vast majority of web-facing TLS certificates, revoking a compromised certificate does almost nothing.

Browsers don't hard-fail on revocation checks. OCSP responses are soft-failed — if the check times out, the browser proceeds anyway. Let's Encrypt, which issues more certificates than any other CA, shut down its OCSP service in May 2025 and moved to CRL-only, citing privacy concerns and the operational cost of serving twelve billion OCSP requests daily. The CA/Browser Forum made OCSP support optional for CAs in August 2023 while making CRL support mandatory. Chrome replaced real-time revocation checking with CRLSets — a compressed revocation database shipped with browser updates — years ago. Firefox uses CRLite, a similar mechanism.

The industry has collectively acknowledged that real-time revocation checking doesn't work at web scale. And rather than fix it, the industry is making certificates short enough that revocation becomes moot.

This is not a criticism. It's a strategic reality that should reshape how you think about revocation.

The Revocation Problem Nobody Wants to Admit

Certificate revocation was designed in the 1990s when the web had thousands of HTTPS sites, not billions. The original model was straightforward: if a certificate is compromised, the CA adds it to a Certificate Revocation List (CRL), and relying parties check the list before trusting the certificate.

The model broke at scale. CRLs grew too large to download efficiently. Bandwidth was expensive, then mobile made it expensive again. The response was OCSP — Online Certificate Status Protocol — which allowed real-time, per-certificate status checks. But OCSP introduced its own problems: latency (an additional network round-trip for every TLS connection), availability (if the OCSP responder is down, should the browser block the connection or proceed?), and privacy (every OCSP query tells the CA which sites you're visiting).

Browsers chose the pragmatic answer: soft-fail. If the OCSP check fails or times out, proceed anyway. This means an attacker who's in a position to exploit a compromised certificate — typically a man-in-the-middle — is also in a position to block OCSP queries. The revocation check fails precisely when you need it most.

OCSP stapling addressed the privacy and performance issues by having the server fetch and cache OCSP responses, then "staple" them to the TLS handshake. But stapling was never universally implemented. Among major web servers, only Caddy implemented stapling correctly by default. Apache and Nginx support it but require explicit configuration, and implementation bugs have been common.

The TLS extension "OCSP Must-Staple" was supposed to enforce stapling — a certificate with this extension would only be trusted if accompanied by a valid stapled OCSP response. But adoption was minimal, browser support was inconsistent, and Let's Encrypt began rejecting certificate requests with the Must-Staple extension in January 2025 for most accounts.

The result: for public web TLS, revocation is structurally compromised. Not because the cryptography is wrong, but because the operational model doesn't survive contact with the real internet.

Short-Lived Certificates: The Revocation Strategy That Isn't

If revocation doesn't work reliably, the alternative is to make certificates expire fast enough that revocation becomes unnecessary. A compromised certificate that expires in 24 hours creates a maximum 24-hour exposure window — roughly comparable to the time it takes most organisations to detect, verify, and complete a revocation process anyway.

The CA/Browser Forum formalised this logic. As of March 2024, certificates with validity periods of 10 days or less are classified as "short-lived" and CAs are explicitly not required to support their revocation via CRL or OCSP. The March 2026 threshold tightens to 7 days.

The broader industry trajectory reinforces this direction. Ballot SC-081v3's phased reduction to 47-day maximum validity by March 2029 doesn't eliminate the need for revocation entirely, but it dramatically narrows the window during which a compromised certificate is usable. When your certificates are renewed every 30 days, revocation is less critical than when they're renewed annually.

For organisations with mature automation — those already using ACME to issue and renew certificates — the shift to short-lived certificates is the most operationally sound revocation strategy for public TLS. You don't revoke compromised certificates. You stop renewing them. Passive revocation: disable the automation, let the certificate die.

As Smallstep's engineering team has articulated clearly: if you set things up properly, certificate revocation isn't worth worrying about for internal PKI either. Issue short-lived certificates, automate renewals, and use passive revocation — stop renewing — for certificates with compromised private keys.

But "set things up properly" is doing a lot of work in that sentence. Short-lived certificates require renewal automation that is reliable, monitored, and resilient. If your automation fails silently, you've traded a revocation problem for an availability problem. The Volume Paradox applies: short-lived certificates mean more issuance events, which means more opportunities for failure, which means more operational surface area to monitor.

OCSP, CRL, and CRLite: An Honest Comparison

For organisations that still need active revocation capability — and many do, as we'll discuss below — understanding what each mechanism actually guarantees matters.

CRLs are the mechanism the industry has converged on for publicly trusted certificates. They're lists of revoked certificate serial numbers, signed by the CA and published at regular intervals. Chrome consumes CRLs and compresses them into CRLSets that ship with browser updates. Firefox uses CRLite, a Bloom filter-based approach that encodes the revocation status of every certificate on the web in a compact form that ships with the browser. Both approaches eliminate the need for real-time network requests, solving the performance, privacy, and availability problems that plagued OCSP.

The trade-off is freshness. CRLSets and CRLite are updated with browser releases, so there's a delay between when a CA publishes a revocation and when browsers reflect it. For high-profile incidents, browser vendors can push out-of-band updates, but routine revocations may take hours or days to propagate.

OCSP is not dead for all use cases. While the web is moving away from it, OCSP remains relevant for enterprise and internal PKI where the relying parties are controlled applications, not browsers. If you run a private PKI for service-to-service authentication, your applications can be configured to hard-fail on OCSP — and since you control both the OCSP responder and the clients, the availability and privacy concerns of the public web don't apply.

OCSP stapling remains useful where supported and properly implemented, particularly for server-to-server connections where you control both endpoints. But relying on it for public web security is no longer a viable strategy.

When Revocation Actually Matters

The "revocation is theatre" framing applies specifically to public web TLS certificates consumed by browsers that soft-fail. For other certificate types, revocation is not only relevant — it's essential.

Code signing certificates. A compromised code signing key means every piece of software signed with it is potentially malicious. Timestamping means code signing certificates remain useful after expiry — signed code is valid as long as it was signed before the certificate expired. This means short-lived certificates don't help. If a code signing certificate is compromised, revocation is the only mechanism to invalidate previously signed code. Revocation infrastructure for code signing needs to be robust, well-maintained, and actively monitored. See Code Signing and Supply Chain Strategy for the full picture.

Client certificates (mTLS). In mutual TLS deployments, client certificates authenticate users or devices. If a device is lost, stolen, or compromised, the client certificate needs to be revoked immediately. The relying party in mTLS is typically a server you control, which means you can enforce hard-fail revocation checking — OCSP or CRL. Short-lived client certificates can reduce the need for revocation, but the UX implications of frequent re-enrollment may be unacceptable for some deployments. See mTLS and Client Certificate Strategy for the trade-offs.

Private PKI certificates. Internal certificates for service-to-service communication, database encryption, or API authentication are consumed by applications you control. You can enforce strict revocation checking because you control the relying parties. CRL distribution within your internal network is typically reliable and fast. OCSP hard-fail is operationally feasible when you run the responder.

Long-lived certificates in legacy environments. Some device and protocol constraints require certificates with multi-year lifetimes. Industrial control systems, medical devices, and network equipment may have certificates valid for 5-10 years. For these, revocation is the only mechanism to invalidate a compromised certificate before natural expiry.

Building a Revocation Posture That Matches Your Risk Model

A certificate revocation strategy shouldn't be one-size-fits-all. It should match your revocation investment to the risk and relying-party characteristics of each certificate type.

For public web TLS, invest in automation that enables short certificate lifetimes (90 days today, 47 days by 2029). Implement passive revocation: if a key is compromised, stop renewing. The exposure window is the remaining certificate lifetime. Ensure your certificate observability catches automation failures before they become outages.

For code signing, invest in robust CRL infrastructure and ensure your signing certificates are issued from CAs with reliable revocation services. Use timestamping for every signature. Protect signing keys with HSMs — prevention is more effective than revocation in this context.

For client certificates (mTLS), implement CRL distribution or OCSP within your controlled infrastructure with hard-fail enforcement. Consider short-lived client certificates if your enrollment and provisioning infrastructure supports frequent renewal without degrading user experience.

For private PKI, deploy CRL distribution points within your internal network and configure applications to hard-fail. OCSP is viable if you can guarantee responder availability. Short-lived certificates issued via internal ACME are the cleanest approach if your infrastructure supports them.

The revocation strategy question isn't "should we revoke?" — it's "for which certificate types does revocation provide meaningful protection, and what's the most operationally sound way to deliver it?" The honest answer is: for public web TLS, revocation provides very little protection. For everything else, it provides essential protection that requires dedicated infrastructure.

Sector context: Financial mTLS (hard-fail relying parties), financial private PKI (audit), manufacturing firmware signing.

---

← Back to Certificate Strategy: The Framework Most Organisations Skip

External References

• The Slow Death of OCSP (Feisty Duck / Ivan Ristić, 2025) — feistyduck.com
• Let's Encrypt OCSP Shutdown Announcement (May 2025) — letsencrypt.org
• CA/Browser Forum: OCSP Made Optional (August 2023)
• CA/Browser Forum Ballot SC-081v3: 47-Day Certificate Validity (April 2025) — cabforum.org
• Good Certificates Die Young: Passive Revocation (Smallstep) — smallstep.com
• CA/Browser Forum: Short-Lived Certificate Definitions (Ballot SC-063)
• RFC 6960: Online Certificate Status Protocol (OCSP) — ietf.org
• AWS Private CA: Revocation Method Planning — docs.aws.amazon.com