Nobody Reads the Revocation List: Certificate Lifetime as the Revocation Mechanism

Certificate Revocation Lists

The CA publishes a signed list of revoked serial numbers at a URL named in each certificate's crlDistributionPoints extension. The TLS Baseline Requirements (version 2.3.1, dated 4 October 2026) require a CA issuing subscriber certificates to publish a new CRL within 24 hours of recording a revocation, and at least every 4 days otherwise, or every 7 days if all its certificates carry an OCSP pointer. Lists may be sharded so no single file holds the whole population. Entries must stay on the list until the revoked certificate's own expiry date.

The failure is size. A client that wants to check a site must fetch the list for that certificate's shard before it trusts the handshake. Huston's April sample, a Let's Encrypt list updated on 22 April 2026, carried 1,562 serials with a nextUpdate of 1 May, nine days later. Mozilla counts roughly 3,000 active CRLs across the web PKI totaling about 300 MB. Huston's summary of the economics: "CRLs only really work efficiently when nobody revokes certificates."

Online Certificate Status Protocol

RFC 6960 lets a client ask a responder about one serial and get a signed answer: good, revoked or unknown. Each response carries thisUpdate and nextUpdate, and the RFC says responses whose nextUpdate has passed "SHOULD be considered unreliable." Huston's description is apt: an OCSP response is "effectively a CRL lookup" done by the CA on the client's behalf.

The failures are privacy, latency, availability and, decisively, what the client does when the responder does not answer. RFC 6960 itself warns that "a vulnerability to denial of service is evident" and that unsigned error responses can be forged. If a client fails closed, the CA's responder becomes a single point of failure for every site it covers. If it fails open, an attacker on the path drops the query and the revoked certificate passes. Clients chose to fail open.

Stapling and Must Staple

With OCSP stapling, the server fetches its own signed status and attaches it to the handshake. The client makes no query, so nothing leaks and the CA's load falls. The Must Staple certificate extension was meant to close the fail open hole by telling clients to refuse a handshake with no staple.

Two problems sank it. Huston points out the logical one: a server that already knows its certificate is revoked can simply stop serving it, so the staple protects only against a server operator who is the attacker, and that attacker will not staple. Let's Encrypt states the practical one: Must Staple "has failed to get wide browser support after many years," and popular web servers implement stapling in ways that risk downtime. Let's Encrypt stopped issuing it in 2025.

Chrome: CRLSets

Chromium's documentation describes CRLSets as "the primary means by which Chrome quickly blocks certificates in emergency situations," with a secondary function of carrying some number of non emergency revocations. Google crawls CRLs disclosed to the Common CA Database, and for intermediates those found through Certificate Transparency, then includes "a subset" of the revoked certificates. The same page states that "Online (i.e. OCSP and CRL) checks are not generally performed by Chrome," though enterprise policy can turn OCSP back on. It also notes that the code is public but "the process by which they are generated is not."

Mozilla's measurement of the result: recent CRLSets weigh about 600 kB and include about 1% of all revocations, roughly 35,000 of about 4 million. A CRLSet is a policy about which revocations matter, executed by the browser vendor.

Firefox: CRLite

CRLite encodes every revocation from every CRL into a compact probabilistic structure that answers "is this serial revoked?" locally with no false negatives for covered certificates. Mozilla enabled it for all desktop users in Firefox 137. Clients download an average of 300 kB a day, a full snapshot of about 4 MB roughly every 45 days with deltas between, and refresh every 12 hours. Mozilla calls it a thousand times more bandwidth efficient than daily CRL downloads, and contrasts it with CRLSets: half the bandwidth, twice the update frequency, all revocations.

It also measured what OCSP had been costing: OCSP requests blocked the TLS handshake for 100 ms at the median, and median handshake time fell from 56.4 ms to 39.9 ms as CRLite coverage rose to 80%. With that data in hand, Mozilla disabled OCSP for domain validated certificates in Firefox 142.

The short lived exemption

The requirements define a Short lived Subscriber Certificate, for certificates issued from 15 March 2026, as one valid for 7 days (604,800 seconds) or less. For those, section 4.9.1.1 says the CA "MAY support revocation," and the 24 hour and 5 day revocation deadlines that bind every other certificate do not apply. Such certificates need not carry a CRL distribution point if they carry no OCSP pointer either.

Revocation is now formally optional for a whole class of publicly trusted certificates. The rule makers did not make the broadcast faster. They defined a lifetime short enough that the broadcast is no longer worth sending.

Let's Encrypt runs ahead of the mandate

Let's Encrypt has published its own staged path. The opt in tlsserver profile moved to 45 day certificates on 13 May 2026. The default classic profile moves to 64 days with a 10 day authorization reuse period on 10 February 2027, then to 45 days with a 7 hour authorization reuse period on 16 February 2028. The shortlived profile, generally available since 15 January 2026, issues certificates valid for 160 hours, and IP address certificates must use it. The announcement for that profile gives the reason in one sentence: "revocation is an unreliable system so many relying parties continue to be vulnerable until the certificate expires."

Note the gap. The default reaches 45 days in February 2028, a year before the Baseline Requirements force 47. If your automation works with Let's Encrypt's default, it will be ready for the mandate early.

ACME Renewal Information turns the CA into the scheduler

RFC 9773, published in 2025, adds a renewalInfo resource to ACME. The client asks, for a given certificate, when it should renew, and the server answers with a suggestedWindow holding a start and an end. The client picks a random time inside it. An optional explanationURL tells the operator why the window moved, and the RFC says clients "SHOULD provide this URL to their operator." A Retry-After header tells the client when to ask again, and here it means both the minimum and the maximum wait.

The motivation section names the revocation case outright: "a CA could suggest that clients renew prior to a mass revocation event." The order field replaces links a renewal to its predecessor, so the CA can track which incident affected certificates have been rotated and can answer 409 alreadyReplaced to a duplicate. ARI is the closest thing the web PKI has to a working revocation channel: it reaches the subscriber, not every relying party, and asks the subscriber to fix it.

Hardcoded intervals break

Let's Encrypt says it plainly: "renewing at a hardcoded interval of 60 days will no longer be sufficient." Without ARI, it suggests renewing about two thirds of the way through the lifetime. That rule scales: about 30 days into a 45 day certificate, about 107 hours into a 160 hour one. Cron jobs written for 90 day certificates, renewal thresholds like "30 days before expiry," and monitoring that only alerts at 14 days left all quietly turn into outages as lifetimes fall.

Authorization reuse disappears

Today a Let's Encrypt account can reuse a domain authorization for 30 days. From February 2028 the default is 7 hours, and from March 2029 the Baseline Requirements cap all domain validation reuse at 10 days. Practically, every renewal must complete an HTTP, DNS or TLS ALPN challenge. That makes the challenge path production critical: the DNS API token your ACME client uses, the /.well-known/acme-challenge/ route on every load balancer, the CAA records that must keep naming your CA. Anything that breaks those breaks issuance within days, not months.

Every certificate you copy is now a liability

Long lived certificates were often copied by hand: into an appliance, a CDN upload form, a partner's VPN, a mobile app pin. Each copy is a renewal you must repeat on the new cadence. Let's Encrypt explicitly says "Manually renewing certificates is not recommended." The inventory question changes from "which certificates expire this quarter?" to "which certificates are not reachable by automation at all?"

What RFC 7671 says DANE replaces

The operational guidance for DANE, RFC 7671, is radical when read next to the X.509 model. For a DANE-EE(3) record, the server "MUST be considered authenticated even if none of the names in the certificate match," and "the expiration date of the server certificate MUST be ignored." Validity comes from the DNSSEC signatures on the TLSA record. Key rotation follows a cache discipline: add the record for the new key "at least two Times to Live (TTLs) or longer before the new chain is deployed," wait for stale record sets to expire from caches, then switch. Revocation is just removing the record and waiting one TTL.

Huston also points to stapled DANE, where the server supplies its TLSA record and the DNSSEC chain inside the handshake, so the client needs no live DNS query: functionally the same shape as a stapled OCSP response, but with the DNS hierarchy as the trust root.

Did Firefox catch the revoked certificate?

Huston's April 2026 post reports that after 48 hours Firefox 148.0.2, Chrome and Safari all still accepted his revoked certificate. The APNIC blog's September summary of his APNIC 62 talk reports that Chrome and Safari did not recognize the revocation and Firefox did. The September account does not give the timing or version. Both are APNIC published; this article presents both. Mozilla's documented CRLite refresh of every 12 hours would predict detection within 48 hours, so the April result is unexplained by the sources available here.

CRL entry counts

The April post shows a Let's Encrypt CRL with 1,562 revoked serials. The September summary cites a weekly updated CRL with 17,527. These are likely different shards sampled months apart rather than a contradiction, so neither figure is used here as a population size.

When Chrome stopped checking OCSP

The April post says Chrome has not performed OCSP checks since 2012. The September summary says Chrome stopped relying on OCSP in 2014. The Chromium documentation fetched for this article states current behavior but gives no date. This article avoids the year.

CRLite compression figures

The April post describes CRLite reducing about 6.7 GB of CRL data to a 1.3 MB filter. Mozilla's own August 2025 post describes about 300 MB across roughly 3,000 CRLs, a 4 MB snapshot every 45 days and about 300 kB of daily deltas. The figures likely describe different eras of the web PKI and of CRLite. This article uses Mozilla's numbers for its own system.

Has Let's Encrypt already moved to 45 days?

The September APNIC summary says Let's Encrypt "has reduced certificate validity from 90 days to 45 days." Let's Encrypt's own schedule shows 45 days only on the opt in tlsserver profile since May 2026, with the default classic profile at 90 days until February 2027 and at 45 days from February 2028. This article uses the CA's schedule.