摘要

  • Authorization Domain Name（ADN）是 CA 实际验证申请人控制权的域名，不一定与证书申请中的完全限定域名（FQDN）完全相同。
  • SC101 指出，旧定义存在一种危险读法：先从左侧删除标签，再跟随 CNAME，可能把验证移到别名服务商控制的目标，却错误扩张到客户的子域名。
  • 新规则先选验证方法，再由该方法决定能否跟随 CNAME、能否裁剪标签；若两步都允许，必须先处理 CNAME，之后才裁剪。
  • v2.2.9 自 8 月 6 日起成为现行文本，但其第 3.2.2.4 节允许 CA 在 11 月 15 日前选择本节或 v2.2.7 的同名条款。投票通过不等于所有签发系统已经走同一条路径。

现行文件并不等于唯一现行算法

TLS Baseline Requirements v2.2.9 的日期是 2026 年 8 月 6 日。修订表把 SC101 列为“澄清 Authorization Domain Names”，相关日期表则把 11 月 15 日列为新推导要求的合规日。

真正决定过渡性质的不是表格，而是第 3.2.2.4 节中的明文：11 月 15 日之前，CA 可以遵守现行条款，也可以遵守 v2.2.7 的第 3.2.2.4 节；从当日起，才必须遵守现行条款。这不是执行者默认宽限，也不是监管者事后酌情放行。旧路径被新规则正式收编为一个有截止日的选项。

因此，一份 9 月签发报告即使准确引用 v2.2.9，也可能没有回答最关键的问题。系统可能已经运行 SC101 新算法，也可能合法调用旧条款。两者都可以被“符合 v2.2.9”覆盖，因为 v2.2.9 本身提供了这项选择。文件版本与执行分支不是一回事。

SC0101v2 表决记录 显示，参与投票的 27 家证书签发方全部赞成，Apple、Google、Microsoft、Mozilla 四家证书使用方也全部赞成，没有反对票与弃权票；记录称门槛均已达到，法定人数为 17。讨论期从 6 月 12 日持续到 19 日，投票期为 23 日至 30 日，知识产权审查期则在 8 月 6 日结束。

这些材料充分证明规则获得通过，却不能证明几十个彼此独立的验证平台、配置、测试、CP/CPS 文档和审计样本在同一天完成变更。规范共识是一条记录，部署事实是另一条。

CNAME 只指向目标，不转让客户子域的控制权

申请人希望证书包含一个或多个 FQDN。CA 选用获准的验证方法，证明申请人控制某个域名。这个被验证的域名就是 ADN。部分方法允许 ADN 从申请名演算而来，而不是永远等于申请名。

这种设计有实际价值。若政策认可更高层的授权范围，域名所有者不必为每一个主机重复同一套证明。但演算规则一旦模糊，便利也会变成越权通道：DNS 把流量导向某个服务商，并不意味着服务商获得客户命名空间中所有子域的控制权。

SC101 的说明称，旧定义把描述性概念与规范性步骤挤在一起，没有说清多个动作能否单独、连续或反复执行。一种严峻的解释是：CA 可以先删除 FQDN 左端的标签，再跟随一个或多个 CNAME。

假设 example.com 的 CNAME 指向 example.org。能够控制 example.org 的运营方可以证明自己掌握别名目标，却不会因此自动控制 blog.example.com。如果验证器先把 blog 删掉，再沿别名去往 example.org，目标运营方的能力就可能被误读成对客户子域的授权。表决说明以 CDN 运营商举例，指出这种解释可能使其为任意客户子域取得证书。

来源没有说某家 CDN 或 CA 实际利用了这一缺口，也没有列出具体误签证书。本文同样不作这项推断。问题在于旧文字容许不同的授权边界，而不是已经证实了一起攻击。

新算法先锁定方法，再决定可用动作

SC101 的关键不是给 ADN 换一个更长的定义，而是把决定拆开并排列顺序。

验证从申请 FQDN 开始。CA 首先选择验证方法。方法选择随后决定 CNAME 步骤是否可用、裁剪步骤是否可用、两者是否都可用，或两者都不可用。某些方法在域名本身执行验证；某些方法使用带下划线前缀的技术名称。后者不能仅凭类比继承前者的别名能力。

若所选方法允许两步，且 CA 确实要同时使用，那么必须先跟随 CNAME 链，再删除左侧标签。先后顺序保留了“控制别名目标”与“控制客户子域”之间的差别，不能让预先裁剪扩大别名看似覆盖的范围。最后得到的名称才是 ADN，所选方法证明的是对它的控制。

工程实现必须服从完整规范及其方法表，而不能把本文的概括当成伪代码。不过，证据系统至少应能显露这些中间状态：输入 FQDN、所选方法、该方法允许的动作、当时观察到的 CNAME 链、每次裁剪、最终 ADN 与实际验证证据。

规则制定过程本身有可冻结的凭据。表决页面链接到一个不可变的 GitHub 差异比较，历史文件页 保留现行版与旧版，6 月 18 日会议记录还解释了 v2 新增的另一项生效日期。这些资料能够重建规则如何形成，却无法指出某次签发执行了哪个代码分支。

过渡凭据应保留整条推导链

普通日志常把过程压缩成“验证成功”。在双规则并存期，这个结果字段丢掉了最需要审查的信息。最低限度的签发凭据应连接：

签发时间 + 申请 FQDN + 所选验证方法 + BR 版本/条款 + CNAME 观测值与链路 + 按顺序记录的裁剪动作 + 最终 ADN + 验证证据身份与时间 + CP/CPS 版本 + 实现/配置版本 + 测试或审计引用 + 已知例外

签发时间决定当时哪些规范选项仍合法。申请名与最终 ADN 显示授权边界是否移动。方法决定允许哪些转换。BR 版本区分 v2.2.7 与 v2.2.9。CNAME 观测值冻结容易变化的 DNS 状态。裁剪序列让审查者检查“别名在先”是否真正发生。CP/CPS 说明机构宣称的做法，软件与配置版本则把宣称接到可执行系统上。

这些字段应绑定到持久的签发或证书标识；系统条件允许时，还可用哈希暴露后续替换。挑战秘密和敏感运维数据不必公开，可以受访问与保存策略保护。目标是让获授权的审查者还原当时的决定，而不是把证书后台全部公开。

这份字段组合是 Daniel Kade 提出的分析工具，不是 CA/Browser Forum 未写出的隐藏义务。现行规则本来就包含日志、CP/CPS 与审计要求。本文主张的是：当规范明示两套算法都可用时，已有证据体系必须额外回答“究竟用了哪一套”。

CP/CPS 是声明，不是执行轨迹

CA 需要通过 Certificate Policy 与 Certification Practice Statement 对规则作出公开承诺，RFC 3647 为此提供常用框架。一份严谨的修订可以说明提前切换日期、受影响方法、部署范围与回滚机制。

但文档不会执行算法。它可能在最后一个生产节点升级前发布，也可能在代码上线后才完成。分批部署会形成混合状态，故障切换可能启用不同配置，截止日前创建的任务也可能在截止日后重试。审计必须把政策文本、部署状态与单次签发记录接在一起。只保存其中一个，便会用“本来应该怎样”替代“实际上怎样”。

共同规则与根计划执行属于不同层次

TLS Baseline Requirements 开篇说明，它们是公共信任 TLS 证书的必要但不充分条件；只有依赖方应用软件供应商采纳并执行之后，才对 CA 形成强制约束。CA/Browser Forum 制定共同底线，根计划仍然控制自己的信任库与执行政策。

Mozilla Root Store Policy 是公开例子：它吸收共同要求，同时保留 Mozilla 自身可能优先或更严格的条款。Apple Root Program Policy 也展示了产品根计划这一独立层次。引用二者只是划清权力边界，不是评价其 SC101 执行。

Forum 表决、CA 的 CP/CPS、验证器的单次运行、根计划的处理决定，是四份不同凭据。仓库中已有关于 Entrust 与 Google 根计划权力的草稿，讨论的是最后一层。本文限定在更早也更窄的问题：两条明示合法的 ADN 路径中，这张证书究竟走了哪一条？

不确定之处在各家实现，而不在截止日

公开材料清楚给出 v2.2.9、过渡选项与 11 月 15 日。它们没有公开每家 CA 的完整部署状态。没有发布实施公告，不能直接判定未升级；笼统宣称符合 v2.2.9，也不能证明已经提前启用新算法。

在缺少签发级证据时，严谨结论是“规则版本尚未得到证明”，而不是“违规”或“已经迁移”。

来源