摘要

  • DNS-01 证明某个 ACME 账户持有账户私钥，并能让 CA 在指定验证名称看到预期摘要。CNAME 或 NS 委托可以交出这项窄权限，而不交出顶级区、网站或企业身份。
  • 授权、通配符范围、CSR、签发、存储、部署、CT 发现与撤销是不同状态。删除 TXT 或供应商登录账号不会同时终结它们。

离场流程没有走到 DNS

把挑战标签委托给专用区本来是一种良好隔离。Let’s Encrypt 明确记录，其 DNS-01 查询可沿 CNAME 或 NS 到另一验证区，因此 Web 服务器不必持有能改动整个域名的 API 凭据。

但只要委托、ACME 账户和账户私钥仍可使用，技术签发能力就还存在。开篇是控制测试，不影射真实事故：应用权限被删除，不代表 DNS 中公开授予的能力也已消失。

摘要连接的是两项事实

RFC 8555 先提供至少 128 位熵的随机 token。客户端把 token 与账户密钥组成 key authorization，计算 SHA-256，再把 base64url 摘要发布到 _acme-challenge.<标识符> 的 TXT 中。

验证成功说明请求方能以该账户签名，也能在当时的验证名称给出正确 DNS 数据。更换 token 或账户密钥会改变摘要；旧 TXT 不是通用口令。这项结果不识别人、公司或顶级区所有者。

ACME authorization 对象保存账户可代表哪个标识符、当前状态和有效期。它之后可以过期、停用或被服务端撤销。审计记录应写清账户、authorization ID、标识符、方法、验证时刻与失效时刻，而不是只写“域名已验证”。

权限很窄，却足以签发

只控制 _acme-challenge 通常不能修改顶级区的 A、MX 或 NS，但对于会沿委托验证的 CA，这已经可以完成签发。DNSSEC 可以真实认证委托和 TXT；它证明签名命名空间确实作了该选择，却不能判断供应商合同今天是否仍有效。

证据链必须保存原始名称、每一跳 CNAME、NS 分界、最终权威区账号、DNSSEC 状态、TTL 以及 CA 相关观察点的答案。控制台上的“已删除”不能证明递归缓存已过期。

通配符范围藏在授权对象里

申请 *.example 时，RFC 8555 返回不带 *. 的基础域 authorization，并设置 wildcard: true。TXT 名看似只是基础域验证，证书范围却覆盖一组名称。因此通配符标志必须随订单和 CSR 一起审查。

RFC 9444 还定义了可选的祖先域授权：服务器策略可以允许祖先 authorization 支持子域证书。不能假定任何 CA 都支持；应记录服务端实际返回的授权标识符和策略分支。

CSR 只封住名称集合

finalize 时，CSR 必须与初始订单包含完全相同的标识符，不能在挑战完成后偷偷增加 SAN。它并不决定谁应持有证书私钥、证书装到哪里，或应用赋予它什么角色。

应分开记录订单、授权、CSR、签发、入库、部署与首次握手。签出而未部署，与越权部署不是同一事件。

CAA 可以进一步缩小签发面。RFC 8657 为 issue 和 issuewild 定义可选的 accounturi 与 validationmethods。只有命名 CA 一致支持时约束才有效，而且仍不能替代域验证；规范还警告，子域控制被委托后，继承的 CAA 限制可能失效。

清理挑战不等于撤销证书

删 TXT 终结一条答案；删 CNAME 或 NS 要等缓存收敛才终结一条路径；停用账户或 authorization 又是不同状态。它们都不会自动撤销已经签出的证书。

ACME 另有签名撤销请求：签发账户、对证书全部标识符仍有授权的账户，或证书私钥可以提供协议规定的撤销权限。OCSP 再公开 good、revoked 或 unknown。CT 让异常签发可见，但 SCT 既不是完整证书验证，也不是自动撤销。

用失败测试证明边界

删除供应商的应用和 CI 权限但保留挑战委托，再尝试新订单；轮换账户密钥却发布旧摘要；在 CSR 添加订单外 SAN；并行验证精确名称与通配符；删除权威委托后，在 TTL 前后从不同解析点观察。

最后，先签发但不部署，再删除挑战记录，确认既有证书状态不会凭空改变。每个控制都应在自己声称负责的边界上拒绝。