摘要

  • IETF ACME 持久 DNS 挑战草案第 02 版允许 CA 用某个账户历史上用过的任一公钥 SHA-256 JWK 指纹匹配记录，而不只看当前密钥。
  • 账户密钥轮换会让旧私钥失去认证新请求的能力，却不会自动撤销与其公钥指纹关联的 DNS 授权；删除 TXT 记录和缩短 persistUntil 也各有延迟边界。
  • 运营方需要覆盖授权全生命周期的回执，记录命中的密钥代次、DNS 观测与缓存期限、账户状态、CAA、授权复用到期点；账户停用才是草案给出的即时全局停止手段。

事故响应表上有两个绿色勾。09:00，ACME 账户完成密钥轮换；09:05，域名侧删除 _validation-persist TXT 记录。旧私钥已经不能签署新的认证请求，权威 DNS 也不再显示旧授权。按常见凭据盘点方法，这件事似乎已经结束。

证书颁发机构手里却可能还保存着删除前取得的验证数据。根据第 02 版 ACME DNS Persistent Challenge，它可以一直复用到对应授权到期。密钥轮换、DNS 可见性与授权复用不是同一个时钟。

第 02 版发布于 2026 年 9 月 20 日。Datatracker 历史显示，它是状态为 I-D Exists 的工作组 Internet-Draft。正文写着 Standards Track，但 Datatracker 尚未填写 intended status，也没有 shepherd、领域主管或 IESG 进程。这不是 RFC，不是 IETF 最后征求意见，更不是任何 CA 已经部署的证明。

机制的核心是一条位于 _validation-persist 之下的记录。值中包含 dns-persist-01、一个 43 字符且不带填充的 base64url SHA-256 JWK 指纹，以及把域名、指纹与 ACME 账户 URL 绑定起来的哈希。RFC 7638定义指纹，RFC 6920提供摘要命名方法。CA 先按当前密钥计算；若不匹配，再从最近到最早查询该账户保留的公钥历史。

这段逆向搜索正是第 02 版的关键变化。01 到 02 的差异要求支持持久验证的服务器，在账户整个生命周期内保留其使用过的每一把公钥的 SHA-256 JWK 指纹。工作组仓库可以观察草案演进，却不会把提案自动变成生产规则。

这样设计有明确理由。ACME允许账户更换密钥；如果持久记录只认当前密钥，正常安全维护会使其失效，域名运营方还得重新写入一条本来就为了减少重复操作而设置的记录。保留的是公开指纹，不是旧私钥。它能说明授权最初绑定到哪把钥匙，却不能替旧钥匙签署新订单。

但连续性也产生残余权限。假设 CA 在 K1 为当前密钥时验证了记录，并保存可复用结果。账户随后切到 K2。K1 私钥已不能认证请求，可验证结果仍属于同一有效账户。如果需要重新查询，服务器也能因为历史中仍有 K1 指纹而匹配原记录。轮换改变了当下的签名主体，不必然撤回过去的 DNS 授权。

删除记录同样不会瞬时生效。递归解析器可以在 TTL 结束前继续返回缓存答案。草案特意强调，DNS TTL 不是验证数据的复用期：前者约束解析器缓存，后者决定 CA 多久可以依赖已经取得的控制证明。域名方可以用 persistUntil 限制授权上限，但之后删除记录或把数值改短，都不会追溯压缩已经取得的验证数据。

因此至少有四本时钟。账户密钥时钟决定现在由哪把私钥认证；DNS 时钟包含权威发布与缓存到期；ACME 授权时钟决定 CA 可以复用验证多久；可选的 persistUntil 则是在本次验证时由域名方给出的上限。推动其中一个，不会自动推动另外三个。

草案提供了一项立即覆盖全账户的停止手段：停用 ACME 账户。处理持久验证的 CA 必须确认账户仍为有效状态；一旦停用，历史公钥带来的连续性不再成立。这比删除单个记录更强，也更宽——它停止整个账户，而非只撤回一个域名。事故预案必须同时包含两种动作，不能把它们写成同义词。

域名绑定还有一个显式例外。默认哈希包含域名，只允许在该名称使用；记录也可指定 domain_name=*，从而让同一账户和密钥跨域复用。方便性扩大了关联暴露与故障半径：观察者更容易判断多个域共享一套 ACME 控制面，一次权限失守也可能覆盖更多标识符。

通配符签发又是另一条策略边界。RFC 8555把标识符授权放在订单处理中，草案只规定持久 DNS 证据如何取得和复用。运营记录应保存精确 FQDN、标识符与通配范围，不能把一次成功解析泛化成对整个客户区域的控制。

CAA 也保持独立。RFC 8657 的 accounturi 参数使用真实 ACME 账户 URL，持久 TXT 记录则把该 URL 纳入哈希。TXT 匹配不等于完成 CAA 检查，CAA 放行也不证明持久授权存在；两项决策都应进入签发凭据。

DNSSEC 可以加强观测路径，却不会合并上述权限。草案建议在可用时验证 DNSSEC；若执行验证且失败，挑战应失败。RFC 4033说明 DNSSEC 能为答案提供来源认证与完整性。它不会判断一条缓存答案是否仍符合机构意图，也不会决定账户应否保持活跃。

草案还允许委托预配置。第三方在经过认证的 POST-as-GET 确认账户有效后，可以获得公开账户 URL 与公钥指纹来制作记录，无需私钥。这样可以把 DNS 运营方和 ACME 账户控制者分开，也更需要记录谁提出、批准并安装了这项授权。

截至截稿，IANA ACME 注册表尚未列出 dns-persist-01。CA/Browser Forum 的 SC-088v3 表决提供行业背景：参与投票的签发方与使用方一致支持一种账户限定的持久 TXT 验证方法。这不证明本版 IETF 草案已部署，也不表示两套规则完全相同。

运营补口是一份覆盖授权生命周期的回执。每次验证应保存准确 FQDN 和标识符范围、记录摘要与观测时间、权威和递归证据、TTL 与缓存地平线、CA 身份、是否使用 domain_name=*、受保护的账户标识、命中的当前或历史密钥代次、账户实时状态、CAA 与 DNSSEC 结果、persistUntil、授权到期点，以及实际消费该结果的订单和签发时间。

有了这份回执，撤销声明才可检验。复盘人员可以区分：密钥已经轮换但历史匹配仍被允许；权威侧已经删除而解析器仍能返回旧值；没有发生新验证但 CA 仍在复用旧结果；或者账户停用在签发前已真正切断路径。否则，团队只能拿今天的 DNS 查询解释由昨天状态决定的证书事件。

草案在发布前仍可能变化，实施方也可能选择更短复用期、更严格多视角查询或更窄通配策略。但制度边界已经清楚：持久授权把控制从一次在线证明转移到一段受管理的历史。轮换是维护；撤回必须命中仍然有效的那项授权。

来源