摘要

  • 2026 年 4 月 21 日，Geoff Huston 撤销了一张 Let’s Encrypt 测试证书，并在签发方的撤销名单里找到了序列号。48 小时后，他测试的三个具体浏览器版本仍接受连接。
  • 后来的 APNIC 62 讲稿记录：过了约两周，Firefox 才在他的测试中拒绝这张证书，Chrome 和 Safari 仍放行。名单写入与客户端执行之间的时差，正是这次实验的主角。

名单上的证书已经“死”了，浏览器门口却照常刷卡。Geoff Huston 先为测试站点签发一张 Let’s Encrypt 证书，四小时后于 2026 年 4 月 21 日将它撤销。他检查签发方的证书撤销列表，序列号确实在内。随后他打开页面，想看最关键的那一步有没有发生。

答案写在他的 APNIC 原始文章 里：48 小时后，Firefox 148.0.2、Chrome 147.0.7727.117 和 Safari 25.4 都接受了连接。这是一张证书、几个指定版本、一个特定时间点的测试，不能替全世界的浏览器下判词。不过它把职责边界照得很亮：签发方负责宣布状态改变，客户端负责决定是否相信眼前这次 TLS 握手。名单本身不会伸手把门关上。

等的时间再长些，结果变了。APNIC 62 的讲稿 说，Huston 隔了约两周再看，同一张证书终于被 Firefox 拒绝；Chrome 与 Safari 在他的测试里仍然放行。四月文章与九月讲稿记录的是不同观察时点，差异比一句“哪个浏览器安全”更值得研究。撤销已生效于登记处，信任却可以在用户端继续存活。

消息要怎样赶到门口？Huston 逐个拆解：客户端下载庞大的撤销列表；在线询问证书状态；由网站在握手时附带状态答复；或者依赖浏览器分发的精选名单。在线查询有延迟、可用性成本，还把用户访问了哪个站点告诉响应方。网站附带答复可以省一次往返，可一旦网站自己持有被撤销的证书，它未必愿意递上那张对自己不利的纸。每一种方案都在重新分摊“及时知道”的成本。

缩短证书寿命也不是魔法。90 天改 45 天，再改六天，损失窗口会缩小；若出事发生在第一天，提前撤销仍然必要。把有效期压到小时，又会迫使现有签发体系承受密集更新。Huston 在 讲稿结尾 提议把服务密钥信息放到 DNS，用 DNSSEC 签名，用短 TTL 限定缓存陈旧的时间，甚至在 TLS 握手中附带验证链。这是他的设计主张，并非今日网页已经普遍采用的机制。他真正追问的是一句朴素的话：用户现在看到的信任凭证，多久前还是准确的？