Certificate Revocation Guide: CRL, OCSP, CRLite and Short-Lived Certificates Explained

Certificate revocation is how a certificate authority declares a certificate untrustworthy before it expires, and for most of the web it has never worked as well as people assume. Revocation is the mechanism that is supposed to stop a stolen private key or a misissued certificate from being used, through Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). Since 2023 the public web has moved decisively: the CA/Browser Forum made OCSP optional, Let's Encrypt switched its OCSP service off in August 2025, browsers check revocation from locally pushed data, and short-lived certificates are replacing revocation with fast expiry. This explainer covers how each mechanism works, what changed and what it means for public TLS, private PKI, mTLS and code signing. It is for security engineers, PKI owners and platform teams who already know the basics in the PKI Basics Guide.

Key takeaways

• OCSP is ending on the public web: CA/Browser Forum ballot SC-063 made OCSP optional and CRLs mandatory for publicly trusted TLS CAs, and the largest CA, Let's Encrypt, turned its OCSP responders off on 6 August 2025.
• Browsers do not ask the CA: Chrome relies on CRLSets and does not generally perform online checks, and Firefox checks a local CRLite filter built from CT logs and CRLs, refreshed every 12 hours.
• Short-lived certificates make expiry the revocation: SC-063 defines short-lived certificates that need no revocation; from 15 March 2026 they must be valid for no more than 7 days.
• Private PKI is a different problem: your own clients (mTLS services, VPNs, Windows smart card logon, OT devices) only check revocation if you configure them to and if the CRL or OCSP endpoint is reachable.
• Soft-fail is the default almost everywhere: if a client cannot fetch status, most accept the certificate, so an attacker who can block the revocation check defeats it.

What it is

An X.509 certificate binds a public key to an identity for a validity period. Revocation ends that binding early. Common reasons are key compromise, a CA discovering it issued a certificate in error, the subscriber no longer controlling the domain, or a device or service being retired. Revocation does not delete a certificate; it publishes a signed statement that relying parties should stop trusting it.

There are three ways to communicate that statement, plus one way to avoid needing it:

How it works

CRLs

A CRL is a list signed by the CA (or a delegated CRL issuer) containing the serial number, revocation date and optional reason code of each revoked certificate, plus thisUpdate and nextUpdate times. Certificates point to their CRL in the CRL Distribution Points extension. Large CAs partition (shard) CRLs so no single file grows too large. Under SC-063, publicly trusted CAs must publish a full CRL or a complete set of partitioned CRLs, issue a new CRL within 24 hours of recording a revocation, and otherwise refresh at least every 7 days if all certificates carry an OCSP pointer, or every 4 days in all other cases.

OCSP

The client sends the issuer name hash, issuer key hash and serial number to the responder URL found in the Authority Information Access extension. RFC 6960 defines three answers: good (no certificate with that serial in its validity period is revoked), revoked, and unknown (the responder does not serve that issuer). Responses are signed by the CA or by a delegated responder whose certificate carries the id-kp-OCSPSigning extended key usage and is issued directly by that CA. An optional nonce binds a response to a request to prevent replay, but most public responders serve pre-generated responses without one. Clients must check that thisUpdate is recent enough and that nextUpdate has not passed.

Stapling and Must-Staple

With stapling, the TLS server attaches a recent OCSP response to the handshake. The TLS Feature extension (RFC 7633), known as Must-Staple, tells clients to reject the certificate if no staple is presented. With public CAs retiring OCSP, Must-Staple certificates are no longer an option from those CAs, and services that requested them need to drop the flag at renewal.

Browser revocation data

Chrome's CRLSets are built by crawling CRLs disclosed to the CCADB and, for intermediates, CRLs found through Certificate Transparency. Chromium states that online OCSP and CRL checks are not generally performed by Chrome, though OCSP can be enabled by enterprise policy. Mozilla's CRLite, enabled for all desktop users in Firefox 137, encodes every revocation for CT-logged certificates in a cascade of Ribbon filters. Mozilla reports about 300 kB of downloads per day on average against roughly 300 MB for the underlying CRLs, with updates every 12 hours, and Firefox 142 disables OCSP for domain-validated certificates.

Short-lived certificates

SC-063 introduced an optional short-lived certificate category with an initial maximum validity of 10 days, reduced to 7 days for certificates issued on or after 15 March 2026. CAs need not revoke them or include CRL or OCSP pointers. Let's Encrypt offers a six-day shortlived profile. Separately, ballot SC-081 reduces the maximum validity of all publicly trusted TLS certificates from 398 days to 47 days by March 2029; see the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Why it matters

• Key compromise response: when a private key leaks, revocation and the time until clients see it set your exposure window. If clients soft-fail or never check, the real window is the remaining validity period. That is the main security argument for short validity.
• Code signing is where revocation still carries weight: signatures are usually timestamped, so a signed binary stays valid after the signing certificate expires. Only revocation, with a revocation date that invalidates signatures made after compromise, stops malware signed with a stolen key. After its 2024 production compromise, AnyDesk revoked its code signing certificate and customers had to move to releases signed with the replacement; see the AnyDesk breach and the Code Signing Security Guide.
• Private PKI and machine identity: mTLS service meshes, VPN clients, Wi-Fi EAP-TLS, smart card logon and device fleets use your CA, not a public one. Whether a revoked device certificate is still accepted depends entirely on how each relying party is configured. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Availability: OCSP responder outages and unreachable CRL URLs have broken logons and TLS connections where clients were configured to hard-fail. Revocation infrastructure is part of your critical path.
• Privacy and compliance: OCSP tells the responder which site a user visits and from which IP address, which is the reason Let's Encrypt gave for ending its service.

Decision guidance

Implementing a revocation strategy for your private PKI

1. Inventory relying parties: list every system that validates certificates from your CA and record whether it checks CRL, OCSP or nothing, and whether it hard-fails or soft-fails.
2. Classify certificates by validity: anything that can be renewed automatically in days should move to short-lived issuance; keep revocation for what cannot.
3. Make distribution points resilient: host CRLs over HTTP on redundant infrastructure, publish well before nextUpdate, and alert when a CRL is close to expiry.
4. Test revocation end to end: revoke a test certificate in a pilot group and confirm each relying party rejects it within the expected time; this is the step most programmes skip.
5. Write the key compromise runbook: who can revoke, how quickly, how to reissue at scale, and how to confirm propagation. Keep a rollback for hard-fail settings (switch to soft-fail if a CRL endpoint fails).

What to measure: time from revocation request to CRL publication; percentage of relying parties that rejected a test-revoked certificate; CRLs within 24 hours of nextUpdate without a newer issue; share of certificates issued with validity of 7 days or less; number of certificates with Must-Staple or OCSP-only pointers still in use.

Common misconceptions

• "Revoking a certificate stops it working immediately." Clients see the change only after the next CRL publication and their own cache refresh, and many never check at all.
• "OCSP is more secure than CRLs." OCSP gives per-certificate answers, but soft-fail means an attacker who blocks the responder wins, and responses are cached for days. CRLs or pushed sets give the same or better protection without the privacy leak.
• "Browsers check OCSP on every connection." Chrome does not by default, and Firefox has moved to CRLite and disables OCSP for DV certificates from version 142.
• "Short-lived certificates are less secure because they cannot be revoked." A seven-day certificate that is never checked is still bounded to seven days; a one-year certificate that clients soft-fail on is effectively bounded to a year.
• "Our internal services check revocation because the library supports it." Many TLS libraries and HTTP clients disable revocation checking by default; it has to be configured and tested.
• "Expiry handles code signing." Timestamped signatures survive expiry; only revocation removes trust in malware signed with a stolen key.

Related concepts

• Certificate Transparency: public logs of issued certificates let you detect misissuance and feed CRLite. See the Certificate Transparency Guide.
• ACME automation: the precondition for short-lived certificates. See the ACME and Automated Certificate Management Guide.
• Workload identity: SPIFFE SVIDs are short-lived X.509 or JWT credentials that rotate automatically instead of being revoked. See the SPIFFE and SPIRE Guide.
• TLS handshake validation: where revocation sits in chain building. See the How TLS Works Guide.
• Windows enterprise PKI: AD CS publishes CRLs and can run an OCSP Online Responder; misconfigured templates are a separate attack path. See the AD CS Security Guide.

Practitioner checklist

• Remove dependence on public CA OCSP: drop Must-Staple and OCSP-only monitoring from public certificates.
• Automate public certificate renewal and plan for 47-day maximum validity.
• Move internal mTLS to short-lived certificates where automation exists.
• For long-lived private certificates, run highly available CRL distribution points and monitor nextUpdate.
• Record hard-fail or soft-fail per relying party and justify each choice.
• Test revocation end to end at least annually with a test certificate.
• Keep code signing keys in HSMs, timestamp signatures and rehearse revocation with a compromise date.
• Write and exercise a key compromise and mass reissue runbook.

Standards and references

• IETF: RFC 6960 X.509 Internet PKI Online Certificate Status Protocol (OCSP)
• CA/Browser Forum: Ballot SC-063 Make OCSP Optional, Require CRLs, and Incentivize Automation
• CA/Browser Forum: Ballot SC-081 Schedule of Reducing Validity and Data Reuse Periods
• Let's Encrypt: OCSP Service Has Reached End of Life
• Mozilla: CRLite, Fast, Private and Comprehensive Certificate Revocation Checking in Firefox
• Chromium: CRLSets
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days

Related NHI Mgmt Group resources: PKI Basics Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Expiry Outages and 47-Day TLS Certificates Guide · mTLS Guide