摘要

  • Mozilla 的现行政策把根存储维护、期间审计与把订户信息写入具体证书前的验证实践明确分开。
  • 政策文本或覆盖一段时期的审计，都不能倒推出一份请求、一次验证观察、一次签发、后来的撤销状态或某个客户端的实际结论。

自 2026 年 7 月 1 日生效的 Mozilla Root Store Policy 3.1 有一个难得的优点：它把数项都正确的事情并列陈述，却没有宣布它们可以彼此替代。Mozilla 在其软件发行中附带 CA 证书和面向不同用途的信任位；对范围内根和技术上能够签发有效服务器或邮件证书的中间证书，政策要求在纳入前及其后至少每年进行特定审计。与此同时，订户提交的信息在进入证书前必须经独立来源或替代通信渠道验证；用于 TLS 的证书还要求 CA 按既定方法确认订户有权使用域名并控制 IP 地址。

每一个句子都有治理价值；没有一个句子会自动变成下一个句子的证据。

审计面对的是一条鉴证边界：被覆盖的系统、准则、期间、方法、被抽样测试的材料、结论和限制。政策要求期间性审计资料至少每年更新。对于 2027 年 7 月 1 日或以后开始的年度审计期间，某些具网站信任位的范围内 CA 还须取得 Detailed Controls Report。该报告的目标是说明系统边界、控制措施、实施、测试和运行有效性。它是重要的监督材料；却不是所有证书请求的流水账，更不是某一签发当时的完整证明。

拿起一张证书，差异会立即显现。序列号、颁发者、有效期和主题备用名称描述了一个对象；它们不说明接到了哪份请求，当时适用哪一版程序，哪个人或自动控制有权行动，独立来源观察到了什么，观察是否仍在允许窗口内，或为何某把密钥被绑定到这些名称。合格审计师的一份意见不会因为存在，就自动补齐这些连接。

反向替代同样不成立。签发记录可以表明一个对象已经生成，却不能证明整个控制环境在审计期间始终有效、所有运行地点都被覆盖、后来没有发生需要处理的事实，或每个衍生发行版都维持相同的根信任处理。Mozilla 的政策本身说明，基于其软件的发行者可以增加、删除 CA 证书或更改信任位。因此政策约束的是 Mozilla 的默认发行集合，而不是所有可能的发行版本。

签发也不等于后来的接受。NSS 文档把证书块和信任块区分开，并将根定义为证书加上信任设置。客户端仍要在自己的软件状态和本地条件下构建并评估路径。主机名、时间、扩展、路径构建、撤销信息、应用用途和连接时观察到的目标服务，都是另外的问题。这不是对任何具体客户端失败的暗示，而是审计材料或 CA 侧记录在缺少客户端证据时所能证明的边界。

实用的答案是一份有边界的签发证据回执。它应在受保护条件下保留请求标识、申请名称与密钥指纹、程序与政策版本、获授权的决策者或自动控制、独立来源或替代渠道的观察及其时间窗口；随后保留序列号、颁发者、有效期、相关扩展和签发时点。后续撤销应作为另一条记录保留查询时间和响应语境。客户端结果也应再次单列，注明构建或策略边界、主机名、路径和时间，而不收集不必要的用户数据。

这不要求公开域名控制材料、客户档案或防御性细节。它要求的是停止让一种陈述取代另一种陈述。敏感证据可以在适当权限下复核；必须持久保存的是连接图：哪项决定支持哪一个对象，依据哪一版规则，后来实际引用的是哪一个观察。

证据边界

已审阅来源没有指认任何 CA、订户、证书、审计意见、DCR、事件或依赖方事件；也没有证明任何不合规。这里提出的回执是编辑性分析，不是 Mozilla、CA/Browser Forum、NSS 或 RFC 的要求。

来源

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS：Updating NSS’s Root Store
  3. RFC 5280