摘要

  • APNIC报道，一张Let's Encrypt证书在撤销后已出现在CRL中；Huston的演示里，Chrome和Safari没有据此拒绝连接，Firefox则识别了撤销。
  • 这是一组特定条件下的观察，不是“所有撤销失效”或某款浏览器永远不检查状态的证据。
  • 缩短证书期限、OCSP、装订响应与DNSSEC/DANE方案分别调整时间或信任边界，均不能凭名称保证客户端即时拦截。

真正需要追问的是清单与用户之间的距离。CA可以撤销一张证书，给清单签名，并在发布点提供最新版本；网站仍可呈现它本地保存的旧证书。浏览器是否下载清单、能否拿到相关版本、如何对待查询失败，以及何时中止连接，属于另一层决策。颁发者写下“不再可信”，并没有取得对所有客户端的直接控制权。

APNIC于9月21日发布的技术会议报告记录了首席科学家Geoff Huston的演示：他签发并撤销Let's Encrypt证书，该证书出现在CRL中；报告称测试中的Chrome和Safari没有识别撤销，Firefox识别了。报道未提供足以重现实验的浏览器版本、操作系统、设置、网络环境及每次连接的完整时间轴。因此，不能把这三个结果外推至所有设备、所有状态来源或所有未来版本。

撤销至少有六个钟：安全问题被发现、CA受理撤销、CA生成并发布记录、分发与缓存更新、客户端读取并执行，以及证书原定到期。Huston在四月的技术分析解释，CRL有签名、发布时间及下次更新时间。尚在有效窗口内的旧清单可能留在客户端；逐次握手下载大清单又有明显代价。APNIC会议报道举出一个每周更新、含17,527个撤销条目的清单。这个数字描述分发负担，并非遭遇风险的用户数。

OCSP改为询问单张证书的状态，减少整份清单传输，却让状态服务可能看到用户访问、增加一次网络依赖，并迫使浏览器在超时或服务失联时作出取舍。签名响应也有自己的时间窗口；“签名有效”与“反映此刻状态”不是一句话。装订式OCSP由服务器在握手时携带响应，可以降低客户端直连状态服务的延迟及隐私成本，但一台仍呈现已撤销证书的服务器，未必愿意送上新的不利证据。此前签为“有效”的响应更须看其日期。

四月分析另有一组浏览器OCSP观察，其中Safari的表现与这次CRL演示不同。这不是要抹去的矛盾，而是测试对象不同的提醒：查询机制、缓存、平台及策略都会改变结果。九月证据能够支持的是这一次“同一记录，客户端结果分歧”，而不是浏览器永久排名。

缩短证书有效期可以限制旧凭据的剩余可用时长，前提是客户端确实检查到期时间、运营者可靠地续发并部署；几天的寿命仍不能像毫秒级的事故响应那样即时收回信任。Huston在APNIC 62演示材料中讨论DNSSEC与DANE，以DNS缓存到期机制承载更短期的密钥信息。这是一种架构建议，不是已在浏览器普遍部署的替代答案。

运营者需要分别保存CA撤销记录、当时可获取的CRL或OCSP版本、各地边缘节点实际送出的证书，以及指定客户端构建版本的连接结果。不能把“CA已发布”当作“客户已受保护”的收据。APNIC没有报告银行被攻破，也没有测出此次实验的受害人数；它揭示的是一道经常被绿色勾选框遮住的执行边界。

来源