01 · DCV的制度位置
域名控制验证（Domain Control Validation）是CA/B Forum基线要求（BR）为DV/OV/EV证书共同规定的强制环节：CA必须确认"证书申请者对证书中每个DNS标识符具有控制权"。在ACME出现前，DCV通过人工配置验证文件或DNS记录完成；ACME将其自动化为三种标准化的密码学挑战（Challenge）。DCV同时也是钓鱼与欺诈证书的主要注入点——DV证书的审核强度仅限"控制该域名"，而攻击者完全可以真实控制一个仿冒域名。因此DCV方法的选择本质上是回答一个问题：你愿意把"域名控制权"的证明委托给哪条网络路径与哪个凭据体系？
BR的方法约束（现行要点）：①验证必须使用CA生成的随机数且证明须在有限时间内完成；②HTTP类验证与TLS-ALPN验证分别限定在标准端口（80/443）；③允许的方法清单与细节以BR第3.2.2.5节及CA/B持续修订的文档为准；④验证数据存在复用期，超过复用期须重新验证——SC-081v3正在将该复用期从398天压缩至10天（见第07节）。
02 · 三种挑战方法详解
2.1 HTTP-01
客户端在域名80端口路径/.well-known/acme-challenge/<token>放置"token+账户密钥指纹"的响应体，CA从多视角（MPIC生效后）发起HTTP GET验证。风险画像：证明依赖边界网络的80端口可达性与路径路由正确性——共享主机、反向代理规则错误、CDN缓存策略、区域性网络劫持均会导致验证失败或被劫持；在边界被劫持的场景下，攻击者可借被劫持路径通过验证。适用：单服务器、无通配符需求、80端口可暴露的标准Web部署。
2.2 DNS-01
客户端在_acme-challenge.<域名>下发布TXT记录（值为token+密钥指纹），CA查询权威DNS验证。风险画像：证明委托给DNS控制面——DNS提供商API凭据成为"域名控制权的可编程凭证"：凭据泄露意味着攻击者可为其解析到的任何域名完成验证（即便非其所有，若配合区域劫持则可为任意域名骗取证书）；凭据通常具有全 zone 写权限，远超ACME所需的最小权限。另一方面，DNS-01是唯一支持通配符证书（*.example.com）的挑战方式，且不要求任何入站端口。适用：通配符需求、多节点负载均衡、80/443不可暴露的内网边缘。
2.3 TLS-ALPN-01（RFC 8737）
客户端在443端口以特殊ALPN协议（acme-tls/1）提供包含验证值的临时自签证书，CA建立TLS连接校验。风险画像：证明与证书私钥的实际服务位置绑定，抗Web路径劫持能力强于HTTP-01；但要求443端口独占可用（与生产证书共用端口时需要特殊SNI调度），且不支持通配符。TLS-SNI-01（其前身）因共享主机环境下的安全缺陷于2018年被各CA废弃，是DCV方法安全性迭代的重要先例。适用：单节点、追求最小DNS依赖、443端口可控的场景。
| 维度 | HTTP-01 | DNS-01 | TLS-ALPN-01 |
|---|---|---|---|
| 依赖凭据 | Web服务器文件写权限 | DNS提供商API凭据（高敏感） | 443端口TLS配置能力 |
| 通配符支持 | 不支持 | 唯一支持 | 不支持 |
| 入站端口 | 80 | 无 | 443 |
| 多节点/负载均衡 | 弱（需保证任一验证请求均命中正确响应） | 强（DNS全局生效） | 弱（需SNI级调度） |
| 主要攻击面 | 路径劫持、边界路由劫持、缓存投毒 | API凭据泄露、DNS区域劫持/投毒、委托链滥用 | 端口占用冲突、SNI调度错误 |
| 适用场景 | 标准单节点Web | 通配符、多云、CDN、无入站端口 | 单节点高保证验证 |
03 · 选型决策矩阵
- 需要通配符 → DNS-01是唯一选项，治理重心全部落在DNS API凭据上（见下节）。
- 无通配符+单节点+80可暴露 → HTTP-01为最低复杂度路径；若同时443由本节点独占且对DNS依赖敏感，可评估TLS-ALPN-01。
- 多节点负载均衡 → 优先DNS-01：HTTP-01在多节点下的"任一路径正确性"需额外工程保证（共享存储、一致性同步），TLS-ALPN-01需SNI级流量调度；DNS-01的天然全局性使多节点部署最简单。
- 关键业务域名 → 方法冗余：主用DNS-01，备用HTTP-01（经_acme-challenge委托或独立授权路径），避免单一验证路径故障转化为证书过期事故（第5页）。
- IP地址证书（Let's Encrypt短寿命证书已支持）→ 仅HTTP-01与TLS-ALPN-01可用（DNS-01不适用于IP标识符）。
04 · DNS凭据安全治理（DNS-01核心议题）
4.1 最小权限模型
- 受限API令牌：主流DNS提供商支持按zone、按记录类型、按操作类型的细粒度令牌——应授予"仅可写
_acme-challenge子域TXT记录"的最小权限；不支持细粒度的提供商建议通过下文委托模式隔离。 - 委托模式（推荐）：将
_acme-challenge.example.com以NS记录委托至专用验证区域（或专用DNS服务商），ACME凭据仅对委托区域有效——凭据泄露的影响面被限制在验证命名空间，且生产解析记录不可被篡改。这也是draft dns-account-01挑战标准化的目标之一（以账户稳定值替代高频令牌轮换，进一步降低凭据运维成本）。 - 凭据生命周期管理：API令牌入密钥管理系统（KMS/Vault）、禁止出现在CI日志与工单系统、设定有效期并自动轮换、使用独立的每集成凭据以实现审计归因。
4.2 常见反模式
高危反模式：①将主DNS提供商的全权限API密钥下发给每台需要证书的主机——单主机失陷即全域名解析权失陷；②凭据硬编码在续签脚本中且与代码库同仓；③使用个人账号生成的长期API令牌且无轮换；④为图省事使用"允许任意子域"的宽泛通配委托。上述任一模式的暴露后果都远超"证书无法续期"。
05 · 网络层劫持与MPIC多视角验证
5.1 威胁实证
BGP前缀劫持与DNS路径操纵可使攻击者将CA的验证流量重定向至其控制的服务器，从而为不属于自己的域名骗取证书。普林斯顿大学CITP的研究（2018年USENIX Security论文《Bamboozling Certificate Authorities with BGP》）系统证明了该攻击在真实互联网条件下对CA的可行性；后续研究持续观测到针对域名验证路径的劫持尝试。这是MPIC机制的直接立法动机。
5.2 MPIC机制与分阶段强制
MPIC（Multi-Perspective Issuance Corroboration，Ballot SC-067v3，2024年通过）要求CA从多个地理/网络拓扑上独立的远程视角对域名验证与CAA查询结果进行corroborate：单一视角被劫持时，其余视角结果不一致即可阻断签发。分阶段强制时间表（以BR现行文本为准）：2025年9月15日起至少2个远程网络视角（含quorum要求），2026年3月15日起3个，2026年6月15日起4个，2026年12月15日起5个；2026年3月15日及以后的阶段另要求远程视角分布于至少2个不同RIR区域、彼此相距至少500公里，进一步抬高了一致性要求。Let's Encrypt自2020年起即运行多视角验证（其生产实践为该机制的重要原型）。
5.3 组织侧影响
- 验证一致性要求提高：组织域名在部分网络视角下不可达/解析不一致（分区域DNS、GeoDNS、防火墙白名单视角IP）将直接导致验证失败——须将CA的多视角探测纳入可用性测试。
- anycast与GeoDNS的副作用：多视角可能命中不同PoP并获不同响应，需保证_acme-challenge等验证记录全局一致。
- 残余风险评估：MPIC抬高路径劫持成本，但不覆盖域名注册账户被盗、DNS提供商账户失陷等控制面攻击（第6页）。
06 · CAA与签发授权
CAA（RFC 6844，2013年；属性标签扩展RFC 8657，2019年）允许域名经DNS CAA记录声明"哪些CA可为本域名签发证书"。2017年起BR要求公开信任CA在签发前必须检查CAA，检查窗口为签发前8小时内。治理价值与边界：
- 低成本收窄信任面：声明单一/少数CA可签发后，其他CA的误签或恶意签发病理即被阻断——是"防错签"而非"防滥用"的第一道闸。
- 与ACME联动的注意点：①使用CDN/云厂商代管证书时，其代管CA必须出现在CAA白名单；②CAA检查由CA执行且受MPIC多视角覆盖，组织无需自行监控但应知晓其检查结果具有时效性；③SC-085v2自2026年3月15日起要求CA在对已启用DNSSEC的域名执行CAA与域名验证查询时校验DNSSEC签名——域名侧开启DNSSEC但配置错误（签名过期、密钥轮换不完整等）将直接导致验证失败、阻断签发，DNSSEC部署质量成为续签的前置条件（与SC-081v3同日生效，叠加效应显著）。
- 边界声明：CAA不约束已获授权的CA内部流程，也不替代账户/凭据保护（第6页）。
6.1 CAA记录配置示例
以仅允许Let's Encrypt签发、并声明违规签发报告渠道为例：
example.com. CAA 0 issue "letsencrypt.org" ; 授权该CA为本域名签发 example.com. CAA 0 issuewild "letsencrypt.org" ; 授权签发通配符证书 example.com. CAA 0 iodef "mailto:cert-abuse@example.com" ; 违规签发报告邮箱（RFC 6844）
配置注意：①使用CDN/云厂商代管证书时，须将其上游CA的CAA标识一并列入白名单，否则代管续签将失败；②CAA记录的变更同样受MPIC多视角一致性（第05节）与DNSSEC校验（SC-085v2）约束——CAA本身是"高频验证链路"的一环；③CAA记录中未列明的CA默认即不可签发，显式";"空值记录可用于表达"禁止一切签发"的强约束（多CA混用时慎用）。
07 · 验证复用期收紧的影响（SC-081v3联动）
BR允许CA在限定窗口内复用既有域名验证结果（避免每次签发重复验证）。SC-081v3将该复用期与证书有效期同步压缩：2026年3月15日起200天、2027年3月15日起100天、2029年3月15日起10天（OV/EV组织身份信息的复用期则自2026年3月15日起由825天同步压缩至398天）。终态下，47天证书的每次续签（30天周期）都将落在10天复用期之外——每次续签都必须重新完成DCV。这对组织意味着：
- DNS-01的验证频率将提升一个数量级：TXT记录的发布/传播/清理全流程进入小时级循环，DNS提供商API的速率与稳定性成为续签链路的产能瓶颈；
- 多视角验证失败概率随次数线性放大：验证路径的全局一致性（解析一致性、80/443可达性）必须从"年审"变为"持续水位"；
- 监控指标须新增DCV维度：验证失败率、验证时延、CA侧授权有效期消耗等应纳入证书可观测性体系（第7页）。
前瞻：dns-persist-01等免轮换挑战草案的目标正是对冲复用期收紧带来的验证频率压力（一次持久绑定、长期免高频凭据操作）。组织在规划2027—2029年自动化架构时应跟踪该草案标准化进度（第8页）。
本节参考来源（本页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
CA/B Forum Baseline Requirements（TLS BR）第3.2.2节（域名验证方法）与CAA检查要求：cabforum.org。
IETF RFC 8737（TLS-ALPN-01，2020年）：rfc-editor.org/rfc/rfc8737；RFC 6844（CAA，2013年）与RFC 8657（CAA扩展，2019年）：rfc-editor.org/rfc/rfc8657。
CA/B Forum Ballot SC-067v3（MPIC多视角签发验证，2024年通过）及BR分阶段实施时间表：cabforum.org；Let's Encrypt多视角验证实践说明（官方博客，2020年起）。
Princeton CITP / USENIX Security 2018《Bamboozling Certificate Authorities with BGP》——MPIC的主要实证依据。
CA/B Forum Ballot SC-081v3（2025年4月11日通过）：证书有效期与DCV复用期分阶段收紧；SC-085v2（CAA查询DNSSEC校验，2026年3月15日生效）。
IETF草案：dns-account-01 / dns-persist-01挑战（ACME工作组草案档案，datatracker.ietf.org）；Let's Encrypt IP地址证书验证限制说明（2025年公告，HTTP-01与TLS-ALPN-01）。