What revocation actually achieves in the Web PKI

Ask most engineers what happens after a certificate is revoked and the answer is that clients stop accepting it. That belief survives because it is almost never tested. In the public Web PKI, revoking a certificate is a request to an authority to publish a statement that most clients will never fetch, some will fetch and ignore on failure, and a few will act on after a delay measured in days. The mechanisms in the previous lesson are real and correctly specified. What they achieve in practice is a different question, and answering it honestly changes how an incident is run.

Soft-fail is the default, and it was chosen deliberately

If a client cannot obtain status information, it has two options: refuse the connection, or proceed. Refusing is called hard-fail and sounds obviously correct until you consider who benefits.

An attacker in a position to present a stolen certificate is, by construction, in a position to block the status lookup. Hard-fail therefore hands that attacker a reliable denial-of-service switch and converts every responder outage, every captive portal and every flaky network into a total failure for legitimate users. Soft-fail accepts a security gap in exchange for not making availability depend on a third party at connection time.

The defaults are visible in source. In Firefox, the preference that governs the choice ships as follows:

# Whether or not OCSP is required.
# true  => hard-fail (if an OCSP request times out, stop the connection)
# false => soft-fail (if an OCSP request times out, continue the connection)
- name: security.OCSP.require
  value: false

- name: security.OCSP.timeoutMilliseconds.soft
  value: 2000

Two seconds, and then the check is abandoned. That is not a bug in the implementation; it is the trade-off stated plainly. The blunt formulation from an earlier revision of Chromium’s own security FAQ is that the effectiveness of OCSP is essentially zero unless the client refuses to connect when it cannot obtain a live valid response, and that no browser hard-fails by default, for good reasons.

What the major clients actually do today

The picture in 2026 is not one of browsers checking status less carefully. It is one of browsers having moved the check off the connection path entirely.

The specifics matter because they are frequently stated wrongly. Chrome’s primary mechanism is CRLSets, and as of 2024 it enforces most security-relevant revocations that are visible via CRLs published to the common CA database. It does not perform online CRL or OCSP fetches by default, citing timeouts, availability problems, invalid responses and local network attacks. Its revocation checking for extended validation certificates, once the one place online checks were performed, was disabled in 2022 for privacy reasons.

Firefox now enforces CRLite. The preference security.pki.crlite_mode ships at 2, meaning enable CRLite and enforce its results, and the documented consequence is that Firefox will not fetch OCSP for domain validated certificates that chain to the Mozilla root store unless security.OCSP.require is true. Mozilla enabled CRLite for all desktop users starting in Firefox 137 and disabled OCSP for domain validated certificates in Firefox 142.

The two runtimes most likely to appear in your own services are the least helpful. Java’s default trust manager initialisation disables revocation checking, and turning on the status request extension alone changes nothing, because the documentation states that if revocation checking is not enabled the connection proceeds regardless of the presence or status of revocation information. Go is more direct still:

Certificate.Verify

WARNING: this function doesn't do any revocation checking.

Meanwhile the Baseline Requirements themselves decline to impose any obligation on the party doing the validating. The section on revocation checking requirements for relying parties reads, in full, no stipulation.

Public OCSP is going away

Treating OCSP as the mechanism to reach for is now anachronistic for publicly trusted certificates. The largest certificate authority in the world has withdrawn from it entirely.

Let’s Encrypt stopped including OCSP URLs in its certificates on 7 May 2025, and switched off its OCSP responder on 6 August 2025, stating that revocation information would from then on be published exclusively via certificate revocation lists. Any procedure, lab exercise or monitoring check that queries an OCSP responder for a Let’s Encrypt certificate is not degraded, it is inoperative, because the certificate no longer carries the pointer and the responder no longer exists.

The same authority stopped issuing certificates carrying the TLS feature extension, the thing usually called must-staple, with a full cutoff on 7 May 2025.

Must-staple: specified, unavailable, unenforced

The one construct that could make revocation fail closed without handing an attacker a denial-of-service switch is the TLS feature extension defined in RFC 7633, identified by OID 1.3.6.1.5.5.7.1.24. A certificate carrying it declares that a compliant server will always provide a stapled status response, and a client must treat the certificate as invalid if the server does not deliver the features the certificate declares. The extension should not be marked critical, since that breaks compatibility unnecessarily.

The specification is sound and still current. Its deployment situation is not. Firefox enforces it, with the preference security.ssl.enable_ocsp_must_staple shipping true. Chrome’s documentation contains no must-staple enforcement anywhere. The CA/Browser Forum Baseline Requirements do not mention stapling, must-staple, the TLS feature extension or its OID at all. And the largest issuer refuses to include it.

The honest summary is that must-staple is a live Proposed Standard, enforced by exactly one major browser, unobtainable from the largest authority, and unmentioned by the requirements that govern the public Web PKI.

The stale window, and the control that replaced it

Even for a client that does check, revocation is not fast. Add up the documented intervals.

flowchart LR
    A["Compromise\ndiscovered"] --> B["CA records\nrevocation\nup to 24h or 5d"]
    B --> C["New CRL published\nwithin 24h"]
    C --> D["Client refreshes\nCRL or set\nhours to days"]
    D --> E["Old certificate\nstops working\nfor some clients"]

The authority is obliged to revoke within twenty-four hours for key compromise and the other listed urgent causes; for the second category of reasons it should revoke within twenty-four hours and must revoke within five days. A new CRL must then be published within twenty-four hours of recording the revocation, on top of a routine cadence of four to seven days. An OCSP response for a subscriber certificate may be valid for up to ten days, so a cached affirmative answer can legitimately outlive the revocation by that long. Browser revocation sets refresh on their own schedules rather than yours.

None of those numbers is a defect. Together they mean that between deciding a certificate is compromised and the last diligent client noticing, days pass. For clients that do not check at all, the answer is never.

The industry response to that arithmetic has been to shrink the window that revocation was supposed to close. Public TLS validity is capped at 200 days for certificates issued from 15 March 2026, falls to 100 days from 15 March 2027, and falls again to 47 days from 15 March 2029. A subscriber certificate issued from 15 March 2026 counts as short-lived when its validity period is 7 days or less.

The requirements then say something revealing about short-lived certificates: an authority may support revoking them, rather than must, and the CRL distribution point extension is optional in them. Revocation is being treated as an obligation that a sufficiently short lifetime discharges.

The IETF formalised the same position. RFC 9608 defines a noRevAvail extension, identified as the fifty-sixth extension in the standard arc, with a NULL value and criticality that must be false. An authority that will publish no revocation information for a certificate must include it, it must not appear in CA certificates, and a certificate carrying it must not also carry a CRL distribution point or a freshest CRL extension. Firefox already implements the practical shortcut: certificates whose lifetime is under ten days skip revocation checking entirely.

CERT=/etc/ssl/certs/app.lab.example.pem

# After a suspected key compromise, remaining validity is the exposure.
for DAYS in 7 14 30 60; do
    if openssl x509 -in "$CERT" -noout -checkend $(( DAYS * 86400 )); then
        echo "more than $DAYS days of exposure remain"
    fi
done

What to do when a key is compromised

Put the three findings together and the incident procedure follows.

Rotate the key first, because that is the only step that removes the attacker’s ability to impersonate the service going forward. Reissue over the new key and deploy it everywhere the old one was used. Request revocation of the superseded certificate with the reason that reflects reality, since key compromise carries a twenty-four hour obligation on the authority and is the class of revocation most likely to reach an aggregated browser set. Then treat the remaining validity of the old certificate as an exposure window, and consider what compensating controls apply to it: monitoring for the old serial appearing in certificate transparency-adjacent telemetry, alerting on handshakes presenting the old public key, and where the estate allows it, moving that service onto a shorter lifetime so the next such window is measured in days.

Production discipline

1. Do not build a control on client-side revocation. If your security argument depends on clients rejecting a revoked certificate, it depends on behaviour most clients do not have.
2. Request revocation anyway, with the correct reason. It is a compliance obligation, it feeds the aggregated sets that do reach browsers, and its absence is conspicuous during an audit.
3. Measure exposure as remaining validity. After a compromise the number that matters is days until the old certificate expires, not hours until the revocation is published.
4. Shorten lifetimes where you can. Every reduction directly bounds the exposure of the next compromise, with no dependency on client behaviour.
5. Retire OCSP assumptions from procedures and monitoring. Checks that query a responder for a publicly issued certificate may now be testing an endpoint that no longer exists.

Cross-course references

• Linux for Production Sysadmins - Part LXXI (TLS) covers revocation in practice on the host, including why short lifetimes displaced status checking for public certificates.
• Git, CI/CD & GitOps for Infrastructure Engineers - Part XCIV (IncSecretLeak) covers the incident shape this lesson responds to, where credential material has escaped and containment is measured in what still works for an attacker.
• Observability for Production Sysadmins - Part LXIV (TLSMonitoring) covers watching endpoints for the certificate they actually present, which is how you detect an old public key still in service.

Quiz