当您申请 SSL/TLS 证书时，证书颁发机构 (CA) 不会直接颁发给您。他们需要证明您确实控制着要保护的域名。这就是域名控制验证 (DCV)的作用所在。这是在颁发任何证书之前确认域名所有权的验证过程。
这不仅仅是官僚程序。DCV 防止攻击者获取他们不拥有的域名的有效证书，这会完全破坏保持 HTTPS 安全的信任模型。CA/Browser Forum 是制定证书颁发基准要求的行业组织，规定了所有证书颁发机构必须遵循的具体 DCV 方法。
在本指南中，我们将说明 DCV 是什么、探索可用的不同验证方法，并帮助您为您的基础设施选择正确的方法。
目录
- 什么是域名控制验证 (DCV)？
- 基于电子邮件的域名验证方法
- 基于 DNS 的 DCV 方法
- 基于 HTTP/HTTPS 文件的验证方法
- 特殊验证场景
- 为您的需求选择正确的 DCV 方法
- 常见 DCV 问题及快速解决方案
什么是 DCV（域名控制验证）？
域名控制验证 (DCV) 是证书颁发机构在颁发 SSL/TLS 证书之前用于验证域名所有权的过程。它通过要求申请人通过电子邮件、上传文件到域名或配置 DNS 记录来证明对域名的权限来确认控制权。
该过程的工作原理如下：CA 生成一个独特的质询（通常是一个随机的字母数字字符串），您通过您域名的基础设施来证明控制权。这可以通过 DNS 记录、您的 Web 服务器或管理电子邮件地址。验证后，CA 知道他们向合法的域名所有者颁发证书，而不是试图冒充您的网站的人。
行业标准和合规性
CA/Browser Forum 的基准要求确切定义了 DCV 必须如何执行。这些不是建议，而是 CA 必须遵循的严格规则，否则可能会失去其在浏览器中的可信状态。
当前标准包括：
- 验证必须使用批准的 DCV 方法之一（如下所述）
- 多视角颁发证实 (MPIC) 要求从多个网络角度进行验证以防止局部化攻击
- 验证对于组织验证 (OV) 和扩展验证 (EV) 证书可重复使用 397 天
- 域名验证 (DV) 证书无法重复使用验证，每次续签时您都必须进行验证
这里有一点很重要：这些要求正在收紧。该行业正在降低最大证书生命周期和验证期。
CA/Browser Forum 为证书生命周期定义了清晰的时间表：从 2026 年 3 月 15 日起，证书现在被限制为 200 天，进一步降至 2027 年 3 月 15 日的 100 天，以及 2029 年 3 月 15 日起的 47 天。
这种收紧也影响验证周期，使频繁的重新验证和 SSL 证书自动化 越来越必要。
基于电子邮件的域名验证方法
1. 构造电子邮件验证
电子邮件验证是最常见的 DCV 方法，因为它很简单，不需要对您的基础设施进行技术更改。CA 向您域名上的特定地址发送包含验证链接或代码的电子邮件。
CA 将尝试这些通用电子邮件地址：
您不需要设置所有这些，只需从列表中设置一个有效的地址。CA 检查您域名的 MX 记录以确认可以发送电子邮件，然后发送验证请求。
电子邮件到达时，您将点击验证链接或将代码复制回证书订购平台。如果您的电子邮件配置正确，该过程通常只需几分钟。
这种方法在以下情况下效果很好：
- 您为域名建立了电子邮件基础设施
- 您偶尔订购证书，而不是大规模订购
- 您想要最简单的验证过程，无需 DNS 或 Web 服务器更改
缺点是什么？您无法轻松自动化它，如果您的电子邮件出现故障或地址无人监控，您的验证将失败。
2. 电子邮件到 DNS TXT 联系方式
这种变体结合了电子邮件和 DNS。您不使用通用地址，而是在 _validation-contactemail.yourdomain.com 的 DNS TXT 记录中发布特定的电子邮件地址。CA 读取此记录并向该地址发送验证。
为什么使用这种方法？
- 可重复使用性：配置后，它在整个验证期间保持有效
- 集中控制：您决定哪个电子邮件正好接收验证请求
- 团队友好：指向分发列表，而不是某人的个人收件箱
这里是实际设置：
_validation-contactemail.yourdomain.com. IN TXT "mailto:[email protected]"
只需使用您偏好的联系电子邮件创建此 DNS TXT 记录，CA 将自动使用它。这对于管理多个证书的组织特别有用。您可以通过一个受监控的收件箱标准化所有域名的验证。
基于 DNS 的 DCV 方法
1. DNS TXT 记录验证
DNS TXT 记录验证因其灵活性和自动化潜力而受欢迎。当您订购证书时，CA 提供一个特定的主机名和验证令牌，您将其作为 TXT 记录添加到您域名的 DNS。
基本过程：
- CA 在证书订购期间提供主机名（通常为 _dvsauth.yourdomain.com）和令牌
- 您使用该令牌作为值创建 TXT 记录
- CA 查询您的 DNS 以确认记录存在
- 验证后，他们颁发证书
该记录通常看起来像这样：
_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"
DNS TXT 验证非常适合：
- 自动化 – DNS API 使其可通过 ACME 客户端或自定义工具编写脚本
- 没有 Web 服务器的环境 – 您只需要 DNS 访问
- 通配符证书 – 我们将在”特殊场景”部分中讨论此要求
要注意一件事：DNS 传播时间。如果您的名称服务器具有高 TTL 值或传播速度缓慢，验证可能需要更长时间。大多数 CA 将重试 24 小时，但最好在添加验证记录之前设置较低的 TTL 值。
2. DNS CNAME 记录方法
CNAME 验证使用不同的记录类型但实现相同的目标。您不直接存储验证令牌，而是创建一个指向由 CA 控制的验证目标的 CNAME。
示例配置：
_dnsauth.yourdomain.com. IN CNAME random-token.dcv.digicert.com.
关键区别：CNAME 指向 CA 控制的记录，这意味着他们可以更新验证目标，而无需您更改 DNS。一些 CA 也允许这样做进行域名预验证，您设置一次 CNAME，当您订购证书时他们可以进行验证。
CNAME 验证在以下情况下效果很好：
- 您的 DNS 提供商使 CNAME 比 TXT 记录更容易管理
- 您想要 OV/EV 证书的域名预验证能力
- 您正在与支持基于 CNAME 验证流程的 CA 合作
并不是所有 CA 都提供 CNAME 验证，所以请向您的提供商确认。但在可用时，这是团队更偏好此 DNS 记录类型的固定选项。
基于 HTTP/HTTPS 文件的验证方法
1. HTTP 实际演示
基于文件的验证要求您在指定的路径上放置特定文件到您的 Web 服务器。然后 CA 通过 HTTP 或 HTTPS 访问此文件以确认您控制托管域名的服务器。
标准路径是： http://yourdomain.com/.well-known/pki-validation/fileauth.txt
CA 提供确切的文件名和内容。您在服务器上创建此文件，确保其可访问，CA 通过获取它来验证。
关键实施要点：
- 该文件必须在 端口 80 (HTTP) 或端口 443 (HTTPS) 上可访问
- .well-known 目录是 RFC 8615 中定义的标准位置
- IP 地址验证需要这个。如果您为 IPv4 或 IPv6 地址获取证书，HTTP 验证通常是您唯一的选择
如果您有直接的 Web 服务器访问权限，基于文件的验证很简单。如果您使用具有受限文件系统访问权限的托管服务或可能缓存或干扰验证请求的 CDN，则效果不理想。
故障排除提示：
- 确保重定向不会干扰。CA 必须到达确切的验证 URL
- 检查防火墙是否允许 HTTP/HTTPS 访问
- 禁用验证目录的缓存
- 验证文件权限允许公共读取访问
2. ACME 质询集成
ACME（自动证书管理环境）协议使用 HTTP-01 和 DNS-01 质询来实现自动化的 DCV。如果您使用 Let’s Encrypt 或另一个兼容 ACME 的 CA，您的 ACME 客户端会自动处理整个验证过程。
HTTP-01 质询：在 /.well-known/acme-challenge/ 处放置验证文件（类似于标准 HTTP 验证）
DNS-01 质询：在 _acme-challenge.yourdomain.com 创建 TXT 记录
您的客户端（如 Certbot、acme.sh 或 cPanel 等平台中的集成工具）处理验证和 证书续签，无需手动干预。ACME 已成为 自动化证书管理的标准，特别是对于管理大型证书库的组织。
特殊验证场景
1. 多域名和 SAN 证书验证
如果您订购 多域名证书（也称为 SAN 或 UCC 证书），您必须单独验证每个域名。单个 DCV 检查不覆盖证书上的所有域名。
示例：example.com、www.example.com 和 shop.example.com 的证书需要三个单独的验证，即使它们是相关的域名。
好消息？您可以混合验证方法。对一个域名使用电子邮件验证，对另一个使用 DNS 验证（如果这与您的基础设施匹配）。CA 的平台将跟踪每个域名的验证状态，一旦所有域名都被验证，才会颁发证书。
2. 通配符域名验证
通配符证书（覆盖 *.example.com）需要基于 DNS 的验证方法。大多数 CA 不会因为安全考虑而接受通配符的电子邮件或 HTTP 验证。
为什么通配符需要 DNS 验证？
通配符证书保护无限的子域。基于文件的验证一次只能证明一个子域的控制，电子邮件验证不能证明对所有可能子域的控制。DNS 验证证明您控制整个域名的 DNS 基础设施，这适合保护所有子域的证书。
如果您需要通配符证书，请计划使用 DNS TXT 或 CNAME 验证。这些通常是您仅有的选择。
3. 子域验证注意事项
您可以在子域级别或父域级别进行验证，具体取决于验证方法。对于 HTTP 验证，文件必须可在您验证的特定子域上访问。对于 DNS 验证，您在适当的子域级别创建记录。
一个重要的区分：对于大多数验证方法，验证父域（example.com）不会自动验证子域（blog.example.com）。除非您使用通配符证书，否则每个子域都需要自己的验证。
为您的需求选择正确的 DCV 方法
将方法与您的基础设施相匹配：
一目了然比较所有 DCV 方法
| 验证方法 | 完成时间 | 自动化能力 | 技术技能 | 通配符支持 | 可重复使用性 (OV/EV) | 最适合 |
|---|---|---|---|---|---|---|
| 电子邮件（通用） | 5-30 分钟 | ❌ 低 | ⭐ 最小化 | ✅ 是 | ❌ 否 | 一次性证书，小型部署 |
| 电子邮件（DNS TXT） | 15-60 分钟 | ❌ 低 | ⭐⭐ 低-中等 | ✅ 是 | ✅ 是（397 天） | 拥有多个证书的团队，已建立电子邮件 |
| DNS TXT 记录 | 10-60 分钟 | ✅ 高 | ⭐⭐⭐ 中等 | ✅ 是 | ✅ 是（397 天） | 自动化，通配符，大型部署 |
| DNS CNAME | 15-60 分钟 | ✅ 高 | ⭐⭐⭐ 中等 | ✅ 是 | ✅ 是（397 天） | 域名预验证，CA 管理的令牌 |
| HTTP 文件 | 5-20 分钟 | ⚠️ 中等 | ⭐⭐ 低-中等 | ❌ 否 | ❌ 否 | 直接服务器访问，IP 地址 |
| ACME (HTTP-01) | 2-10 分钟 | ✅ 非常高 | ⭐⭐⭐⭐ 中等-高 | ❌ 否 | N/A（自动续签） | 完全自动化，Let’s Encrypt |
| ACME (DNS-01) | 2-10 分钟 | ✅ 非常高 | ⭐⭐⭐⭐ 中等-高 | ✅ 是 | N/A（自动续签） | 带通配符的完整自动化 |
按场景选择方法
如果以下情况，使用电子邮件验证：
- 您有简单的一次性证书订购
- 通用管理员电子邮件地址被监控
- 您不需要自动化
如果以下情况，使用 DNS TXT/CNAME 验证：
- 您需要通配符证书
- 您正在管理多个证书
- 您没有 Web 服务器访问权限
- 您想要自动化功能
如果以下情况，使用 HTTP 文件验证：
- 您有直接的 Web 服务器访问权限
- 您正在验证 IP 地址
- 在您的组织中，DNS 更改很困难
常见 DCV 问题及快速解决方案
验证失败会发生。以下是您将遇到的最常见错误以及如何快速解决它们。
HTTP 文件验证：”404 未找到”
错误：“系统在 http://example.com/.well-known/pki-validation/[filename].txt 查询了一个临时文件，但 Web 服务器返回了以下错误：404（未找到）。”
快速解决方案：
- 手动创建目录结构：/public_html/.well-known/pki-validation/
- 设置权限：目录为 755，文件为 644
- 检查可能阻止 /.well-known/ 路径的 .htaccess 规则
- 如果域名刚添加，请等待 24-48 小时进行传播
- 测试可访问性：curl -v http://yourdomain.com/.well-known/pki-validation/test.txt
常见原因：验证文件路径不存在或不可公开访问。
HTTP 验证：”禁止 DCV HTTP 重定向”
错误：“cPanel（由 Sectigo 提供）禁止 DCV HTTP 重定向。”
快速解决方案：
- 在验证期间临时禁用 HTTPS 重定向
- 从重定向规则中排除 /.well-known/* 路径
- 检查 .htaccess、Cloudflare 页面规则或服务器配置中的重定向
- 如果使用 CDN，暂时禁用或添加异常
常见原因：您的网站将 HTTP 重定向到 HTTPS 或重定向到另一个域名，阻止了 CA 的验证尝试。
DNS 验证：”没有与…匹配的 TXT 记录”
错误：“对”_dvsauth.example.com”的 DNS 查询以获取 DCV 质询返回没有与值”[expected-value]”匹配的”TXT”记录。”
快速解决方案：
- 等待 1-24 小时进行 DNS 传播（取决于 TTL）
- 验证确切的主机名和值：dig _dvsauth.example.com TXT +short
- 检查验证令牌中的复制/粘贴错误
- 如果使用委派 DNS (NS 记录)，在正确的提供商处添加 TXT 记录
- 在添加验证记录之前将 TTL 降低到 300 秒（5 分钟）
常见原因：DNS 尚未传播，或记录有拼写错误。
DNS 验证：CAA 记录阻止颁发
错误：“证书颁发机构遇到了多个角度 CAA 检查错误。”
快速解决方案：
- 检查现有 CAA 记录：dig example.com CAA
- 将您的 CA 添加到允许的颁发者：example.com. CAA 0 issue “digicert.com”
- 使用 ping.pe 工具验证 CAA 记录全局解析
- 如果没有 CAA 记录，您不需要添加任何内容（缺席允许所有 CA）
常见原因：CAA 记录限制哪些 CA 可以为您的域名颁发证书。
电子邮件验证：未收到电子邮件
快速解决方案：
- 首先检查垃圾/垃圾邮件文件夹
- 验证这些地址存在且接收电子邮件：admin@、administrator@、webmaster@、hostmaster@、postmaster@
- 检查 MX 记录：dig example.com MX
- 将 CA 的电子邮件发送域名白名单添加到您的垃圾邮件过滤器中
- 从 CA 的控制面板请求电子邮件重新发送
常见原因：验证电子邮件被垃圾邮件过滤器捕获或管理员地址不存在。
平台特定：cPanel AutoSSL 故障
错误：“本地 HTTP DCV 错误：发生内部错误。”
快速解决方案：
- 检查 WHM > 管理 AutoSSL 日志以获取详细信息
- 等待 30 分钟并重试（通常会自动解决）
- 在 Sectigo 和 Let’s Encrypt 提供商之间切换
- 清除 AutoSSL 队列：WHM > 管理 AutoSSL > 清除待处理队列
快速诊断命令
在联系支持之前，运行这些检查：
# 验证 DNS 传播
dig yourdomain.com +short
dig _dvsauth.yourdomain.com TXT +short
# 测试 HTTP 文件可访问性
curl -v http://yourdomain.com/.well-known/pki-validation/test.txt
# 检查 CAA 和 MX 记录
dig yourdomain.com CAA
dig yourdomain.com MX使用 SSL Dragon 简化您的 SSL 证书管理
正确处理域名控制验证对于顺利的证书部署至关重要。SSL Dragon 从受信任的证书颁发机构提供证书，具有您所需的所有验证方法，无论您偏好电子邮件、DNS 还是基于 HTTP 的验证。
我们的团队可帮助您对域名验证、组织验证和扩展验证证书进行 DCV 要求导航。我们将引导您完成与您的基础设施相匹配的验证方法，并在验证问题出现时回答问题。
停止与证书验证作斗争。浏览我们的 SSL 证书选项！
