摘要

  • Chrome 没有让所有 Entrust 证书在同一天失效，而是用最早的证书透明度时间戳划线：线前证书继续获得默认信任，线后签发则受到拦截。
  • 这条线揭示了公有 Web PKI 的真实权力结构：CA 可以签发密码学上有效的证书，却不能要求浏览器永远把它视为公共可信凭据。

假设两张 Entrust 证书采用同样的算法、拥有相同的有效期。一张最早的 Signed Certificate Timestamp 落在 2024 年 11 月 11 日 23:59:59 UTC，另一张晚了一秒。按照 Chrome 公布并在 Chrome 131 及以后版本执行的规则，这一秒足以让前者正常建立连接，而后者在默认配置下触发整页警告。

这里发生的不是“证书提前到期”。变化的是证书背后的默认信任许可。

Entrust 掌握签发、验证、吊销、合规解释和事故响应；网站运营者掌握采购、部署与迁移；Chrome 掌握其用户默认接受哪些根。三者权力相连，却不能互相替代。即使 Entrust 认为证书符合自身流程，也不能单方面恢复 Chrome 根存储的认可；Chrome 可以改变默认信任，却不能替客户完成证书替换。

为什么 Chrome 选择时间戳

Chrome 没有立即移除所有受影响根下的全部证书，而是采用面向未来的限制。最早 SCT 不晚于截止时点的证书不受这次行动影响；之后进入透明度日志的证书则失去默认信任。这样既减少了现有站点突然中断，也把每个 Entrust 客户的下一次续签变成了迁移节点。

这是精确的技术治理。彻底移除根可能在一个版本中打断庞大的既有安装面；SCT 截止线则把既有证书和未来业务分开。短期连续性得到保留，但 Entrust 后续公共 TLS 签发对 Chrome 用户的商业价值被显著削弱。

Chrome 同时保留了企业自主管理的边界。在支持的平台上，企业管理员可以把对应根明确安装为本地可信根，从而覆盖默认限制。这个例外没有恢复“全互联网都应信任”的地位，它只是允许一个组织为自己管理的设备承担选择责任。公共默认信任与内部私有信任因此被清楚分开。

真正被审查的是运营记录

Chrome 表示，决定来自六年来持续出现的合规失败、未兑现的改进承诺，以及公开事故报告中缺少可测量进展。这是 Chrome 的判断，并非法院裁判；但它说明单个错签事件不是全部。根计划在评估的，是 Entrust 是否拥有可靠的发现、披露、修复和验证闭环。

Entrust 自己的回应进一步说明了激励冲突。公司称近期错签源自对 CA/Browser Forum 要求的误解，并承认为了给客户更多灵活性，曾提供规则并不支持的吊销延期。延期可以减少某个客户当下的停机，却把风险继续留给没有参与协商的依赖方。公共信任规则的目的之一，正是防止 CA 与客户把外部风险当作双边服务问题处理。

Entrust 随后宣布把 CA 产品合规团队纳入更广泛的合规与运营体系，设立跨职能变更控制委员会和技术评审委员会，加快自动化，强化承诺追踪并修改公开事故响应。它们都是相关控制，但公开资料不能证明这些措施已经长期有效。Chrome 的核心意见也正是：承诺必须由可观察的持续改进来兑现。

信任不是产品外面的标签

CA 销售签发和生命周期服务，但决定经济价值的是浏览器与操作系统是否已经把它的根分发给依赖方。这个分发渠道不是 CA 自己创造的。它由根计划依据政策、共同要求和公开事故记录持续授予。

因此，合规不是完成产品之后再补的文件工作。事故披露、吊销执行、承诺交付和证据留存本身就是生产系统。任何一项失灵，都可能让 CA 失去最关键的分发渠道。另一方面，浏览器的处置会把迁移成本推给大量站点，所以也必须给出明确范围、日期、测试方法和例外边界。

Chrome 的分阶段截止既是安全行动，也是市场干预。它没有否定 Entrust 的所有私有 PKI 或其他证书业务，但让新的公共 TLS 签发面临 Entrust 无法单方面解除的浏览器约束。客户得到的是迁移时间，而不是永久豁免。

证据边界

公开材料没有给出受影响客户数量、迁移规模或收入损失，也无法证明 Entrust 的改革效果。Chrome 的决定也不代表所有浏览器和操作系统根计划。某个站点是否受影响，取决于证书链、SCT 时点、续签日期、浏览器版本和企业本地信任配置。

可以稳妥得出的结论更窄：当根存储的管理者不再接受 CA 的运营控制记录时，公共默认信任可以通过一条可验证的技术规则撤回。

来源