Summary

  • Geoff Huston revoked a Let’s Encrypt test certificate on 21 April 2026 and found its serial number in the issuer’s revocation list. After 48 hours, the three browser versions he tested still accepted it.
  • In his later APNIC 62 presentation, Firefox rejected the same certificate after a couple of weeks; Chrome and Safari still accepted it in his test. His question was who turns a published warning into a decision at the point of use.

The certificate had done everything asked of it, including dying on schedule. Geoff Huston issued a Let’s Encrypt test certificate, revoked it four hours later on 21 April 2026 and checked the issuer’s certificate revocation list. Its serial number was there. Then he opened the site. The browsers behaved as if they had missed the funeral.

In Huston’s first-person APNIC account, Firefox 148.0.2, Chrome 147.0.7727.117 and Safari 25.4 accepted the connection 48 hours after revocation. That is a dated experiment with one certificate and named browser versions. It is still a sharp way to expose the missing handoff: the authority had published a new status; the relying software had to learn it and act on it. A line in a list cannot close a TLS connection by itself.

Time changed one result. In his APNIC 62 conference slides, Huston returned to the same certificate after what he called a couple of weeks. Chrome and Safari still let it through in his test; Firefox now rejected it. The April post and September talk therefore record different observation points, not a tidy three-browser verdict for all time. The interval is the story. A safety mechanism that eventually notices a revoked credential leaves a window in which “revoked” and “accepted” can both be true.

Huston works through the machinery behind that awkward coexistence. A browser can fetch a certificate revocation list, ask an online status responder, rely on a status response stapled by the server, or consume a vendor’s curated revocation feed. Lists can be heavy. Online checks add latency, availability dependence and a trail of where users connect. A stapled response is efficient, but a server presenting a certificate it knows is revoked has little incentive to volunteer bad news. Each route assigns a different party the cost of freshness.

The appealing shortcut is to make certificates expire sooner. Huston asks whether 45 days or six days solves an early revocation. Both shorten the interval of possible misuse; neither eliminates the need to react before expiry. Push the validity period down to hours and the existing issuance system faces a new workload. The clock on the credential becomes an engineering decision about how much stale trust everyone will tolerate.

His provocation is on the final slides: put service-key information in DNS, sign it with DNSSEC, let a short time-to-live specify when a cached answer must be refreshed, and potentially carry the validation chain into the TLS handshake. DANE and stapled DNSSEC are his proposed alternative design here, not the way today’s Web suddenly operates. The thought experiment is valuable because it puts the question where the browser meets the service: who can say the key is current, how long does that answer last, and who is obliged to check again?