摘要

  • 被 CA 识别的 accounturi 和 validationmethods 只收紧它们所在的 issue 或 issuewild 属性；前者绑定请求账户，后者限定验证方法，两者都不替代 CA 标识域名的匹配。
  • 参数支持是可选且因 CA 而异，但一旦多个签发系统使用同一 CA 标识域名，它们就必须一致识别这些参数；无法统一时应使用不同标识域名。
  • CAA 授权可以叠加，另一条宽松属性可能继续放行；而且 CAA 管的是当下签发，不会使已经签出的证书自动失效。

一次证书平台迁移很容易只验证最显眼的入口。新 ACME 账户能续期，新的 DNS 限制也按预期拒绝了另一个账户，项目便被标记为完成。可同一组织可能还有托管签发接口、企业 API 或尚未退役的非 ACME 通道。只要它们在客户 CAA 记录中使用同一个 CA 标识域名，它们就不是三个互不相关的产品测试，而是一项共同的解释承诺。

RFC 8659 先规定 CAA 的基本作用：它表达 CA 当前是否被授权为指定名称签发证书，而不是浏览器如何验证已有证书。查询会在 CAA 查找中跟随别名，并沿名称向上寻找第一个非空 RRset；一张证书请求中的每个名称都要检查。记录后来变严，并不会追溯撤销此前签出的证书。

RFC 8657 在这个授权判断中加入两种可选限制。CA 识别 accounturi 时，请求必须来自该 URI 标识的账户，同时属性中的 CA 标识域名仍须匹配。属性不带这个参数，任何账户都可能满足它；参数出现多次、URI 无效或 CA 不认识该 URI，这一条属性便不能授权请求。

账户 URI 是公开标识，不是账户密钥。支持扩展的 ACME 系统应识别 ACME 账户对象的 URI；非 ACME 系统可以另行分配 URI。把字符串写入 DNS 不等于交出凭据，也不能把一个 CA 的账户权限搬到另一个 CA。

validationmethods 限定的是授权方法。逗号分隔的列表中至少要有一种被采用的方法；空列表不允许任何列出的方法。ACME 方法使用登记标签，非 ACME 方法可能需要 CA 自己定义的标签。因此，DNS 中的合法拼写并不自动获得语义，域名持有人必须先确认目标 CA 明确支持它。

Let's Encrypt 的公开文档提供了一个边界清楚的例子：其 CAA 标识为 letsencrypt.org，并说明账户 URI 形式以及 http-01、dns-01、tls-alpn-01 的支持。这是一个服务方的公开声明，不是对每个后台入口的独立一致性审计，更不能推出行业普遍支持。

RFC 8657 对组织内部的要求更硬。使用同一个 CA 标识域名的所有签发系统，必须一致识别相同参数。标准明确提到 ACME 与非 ACME 系统并存，也提到合并后的系统。如果无法确保一致，CA 可以为不同系统使用不同的标识域名；它不能在共用标识下宣布支持，却让旧入口赋予限制不同含义。

账户命名也会在合并时暴露问题。一个 CA 识别的各个标识域名之间，账户 URI 必须保持无歧义。两个旧系统都存在“账户 1042”时，直接合并编号清单会产生碰撞。URI 中包含权威部分可以保留来源。这里要求的不是不相关 CA 共用账户库，而是同一 CA 不把两个主体压成同一个公开标识。

即便每个解析器都正确，DNS 写法仍可能放宽结果。CAA 授权是相加的：一条绑定账户的方法限制，不会取消另一条同样适用、却没有参数的 issue。通配符还走另一分支；存在 issuewild 时，通配符请求用它而忽略 issue，普通名称则仍看 issue。只测其中一类名称，不能证明另一类也受同样约束。

critical 标志也不能充当“所有参数都必须理解”的总开关。它处理的是未知或不支持的属性标签。给 issue 设置 critical，并不会迫使 CA 识别它不支持的 accounturi 或 validationmethods 参数。标签和参数是两个判断层级。

授权与实际签发还可能相隔一段时间。RFC 8657 提到缩短授权有效期或在签发附近重新检查 CAA，以缩小这个窗口；文中的大约一小时只是示例，不是普遍期限。迁移期间临时放宽一次，可能产生在窗口关闭后仍有效的证书。

因此，验收记录必须能连接这些事实：请求中的每个名称、实际 RRset、别名与委派路径、DNSSEC 结果、适用属性、CA 标识、账户 URI、验证方法、处理入口、决定时间与最终证书。只有新入口成功，证明不了共用名称背后的旧入口已经遵守同一规则。

来源

  1. RFC 8657——CAA 账户 URI 与 ACME 验证方法绑定扩展
  2. RFC 8659——DNS 证书颁发机构授权资源记录
  3. Let's Encrypt——CAA 文档
  4. Heng Lu——互联网治理核心的代理问题
  5. Heng Lu——为何 BTW Media 存在，以及为何产品是现实而非倡议