Summary

  • APNIC reports that a revoked Let's Encrypt certificate appeared on a CRL in Geoff Huston's APNIC 62 test; Chrome and Safari did not reject it in that demonstration, while Firefox did.
  • The observation concerns one test and an enforcement chain. A CA's signed record, its distribution and a browser's decision are different events; it does not establish that every revocation or browser configuration behaves alike.
  • Shorter certificate lifetimes limit one clock but do not make revocation immediate. OCSP, stapling and proposed DNSSEC/DANE alternatives each move the dependency rather than erase it.

The most important object in the demonstration was not the browser window. It was a serial number in a certificate revocation list. Once a certification authority has placed a certificate there, the credential has an adverse status in the authority's record. But a person making a web connection is protected only if the software in that connection obtains usable evidence and acts on it. Between those two statements lie distribution, caching, client policy and time.

APNIC's 21 September account of Technical Session 1 describes a test by its Chief Scientist, Geoff Huston. He issued and revoked a Let's Encrypt certificate. The revoked credential appeared on a CRL. Chrome and Safari, in the observed run, did not recognize the revocation; Firefox did. These are the reported outcomes of that exercise. The summary does not supply a reproducible matrix of builds, platforms, settings, network conditions, status feeds and exact connection times. It cannot support a claim that either browser always accepts or always rejects a revoked certificate.

The distinction is more than a cautious footnote. Certificate validation is often pictured as a single green or red result. In reality, the issuing CA attests to an identity or domain-control check, sets a validity interval and publishes a way to learn about early withdrawal. A site presents the credential it has deployed. A CRL distribution point publishes a CA-signed list, potentially through caches. A browser chooses whether and how to consult that list or another source, how recent an answer must be and what to do when the status service cannot be reached. The CA cannot force every client to execute its record merely by signing it.

Huston's earlier technical analysis explains why a CRL is not a real-time switch. A signed list carries its own publication and next-update times; a relying party may keep an older, still-valid copy until its next update. Fetching a large list during each TLS handshake is expensive. APNIC's conference report cites a weekly list with 17,527 revoked certificates and describes the September test within a seven-day publication cycle. Neither number measures the number of people exposed or the time that any particular browser accepted this certificate. They describe the distribution problem, not a population outcome.

OCSP changes the shape of the query. A client can ask for the status of one certificate rather than retrieve a whole list. That creates a potentially identifying request to the status service, another network dependency and a decision about a timeout or unavailable responder. Signed answers can be cached, and their own thisUpdate and nextUpdate matter. A response that was authentic when made is not necessarily the freshest account of a later revocation. OCSP stapling lets the server bring a signed answer to the handshake, reducing a client's direct lookup and some privacy cost, but a server with a revoked certificate has little incentive to volunteer a new adverse answer. A signed, previously good staple also has a time boundary. These are different mechanisms, not interchangeable proof that the current client stopped.

There is an especially tempting error in reading the chronology. Huston's April article includes an earlier browser/OCSP observation in which Safari behaved differently from the September CRL demonstration. That is not a contradiction to be repaired by averaging two tables. It is a reminder that test mechanism and conditions matter. The defensible September finding is narrow: in APNIC's reported run, the published CRL entry did not translate into rejection by two tested clients, and it did by one.

Short-lived certificates offer another answer to the gap. If a client enforces the notAfter date, a credential cannot be used indefinitely merely because a revocation signal never reaches it. But a lifetime measured in days is not an immediate response to a key stolen now; the residual validity window still exists. Issuers and operators also need reliable renewal and deployment, or a smaller validity window can become a service-availability problem. Huston argues for DNSSEC-backed DANE and DNS cache expiry as a different design with potentially shorter-lived keying material. That is an architectural proposal in his APNIC 62 presentation, not evidence that browsers have migrated to a universal replacement.

For an operator, the lesson is to keep several receipts separate. Record when a key problem was learned, when revocation was requested, when the CA published the changed status, what version of the CRL or signed OCSP answer was retrievable at a given location, and what named client build actually did under a stated configuration. If a site rotated its own certificate, record where the old one stopped being served. None of these alone is the reader's outcome. Together they can establish which boundary failed and for how long it was observable.

APNIC did not report a compromised bank, an attack on these browsers, or a measured share of users harmed by this one demonstration. It showed something more useful for governance: a correct adverse record can coexist with different client decisions. The question is no longer simply whether the CA revoked. It is whether the last actor in the chain treated that record as a reason to stop.

Sources