域名已经接入 CDN，控制台也显示验证通过，托管证书却一直停在申请中。反复删除域名、重新提交申请，可能让排查更难：验证记录换了，申请状态重置了，原来的错误信息也没有留下。
先保存本次申请的证书名称、覆盖域名、状态和错误提示，再判断失败发生在哪一步。CDN 域名接入验证、证书域名验证、CA 签发和边缘节点部署分别有各自的条件；其中一项通过，不能直接证明整条流程已经完成。
本文面向使用 CDN 托管证书的站长与运维人员，示例查询适用于装有 dig、curl 和 OpenSSL 的环境。域名均为示例，执行前请替换。不同平台的 CA、验证方式和状态名称可能不同，应以本次订单及官方文档为准。
用错误提示确定排查入口
把申请失败时的完整提示抄下来，而不要只记住“证书有问题”。常见入口可以这样区分：
| 看到的状态或提示 | 优先检查 |
|---|---|
| 域名验证待完成、记录找不到 | TXT/CNAME 记录名、内容、托管区域和实际 DNS 响应 |
| CAA 拒绝、签发机构未授权 | 生效的 CAA 记录及本次签发 CA |
| DNS 查询错误、SERVFAIL | 权威 DNS 响应、DNSSEC 和委派链路 |
| AccessDenied、没有权限提交或读取证书 | 对应平台的账户、角色和操作权限 |
| 已签发，但访客仍看到旧证书 | 证书绑定、域名覆盖范围及边缘部署状态 |
这张表用于选择查询起点。具体错误含义仍需对照平台说明。例如 AWS ACM 将 CAA_ERROR、域名验证拒绝等失败原因分别列出，不能把所有签发失败都归因于同一条 DNS 记录。[1]
查询申请域名，而不只看 DNS 控制台
在证书申请中找出完整域名集合，例如 www.example.com、example.com 或 *.example.com。一个证书覆盖多个名称时，应逐个检查对应的验证与授权要求。
先查询常用递归解析器实际返回什么：
dig www.example.com CAA +noall +answer +comments
dig www.example.com CNAME +noall +answer +comments
dig example.com CAA +noall +answer +comments
看清响应状态和回答内容。NOERROR 且 CAA 回答为空，与 SERVFAIL 是两种情况；前者还需继续判断有效授权来源，后者首先是 DNS 查询失败。DNS 控制台里的记录如果没有出现在实际查询结果中，签发方也未必已经看到它。
CAA 的有效记录查找会涉及别名和父域，规则由 RFC 8659 定义。不能仅凭某个子域的一次空回答，就认定这个名称完全没有 CAA 限制。[2] 有 CNAME 时，应检查链路中的域名，并根据签发平台的诊断结果确认它看到的有效 CAA 集合。
同一个 DNS 名称存在 CNAME 时，通常不能再同时配置其他类型的普通记录。[3] 若 CDN 接入要求某个名称保留 CNAME，应在平台支持的位置配置授权或验证记录，避免为了加一条 CAA 把业务解析改坏。
对照本次 CA，检查 issue 和 issuewild
CAA 用来表达域名允许哪些证书颁发机构签发证书。它不等同于 CDN 控制台登录权限，也不能替代域名控制权验证。
常见记录可以写成：
example.com. CAA 0 issue "letsencrypt.org"
这是一条授权 Let’s Encrypt 的示例。使用其他 CA 的 CDN 托管证书，不能照抄这一行就认为问题已经解决。先查看平台的 CA 支持清单、订单信息或官方排障文档，再决定需要授权的机构标识。[4]
普通证书主要看 issue；通配符签发有 issuewild 时使用对应的通配符授权规则，没有 issuewild 时再按 issue 规则处理。多个授权记录可以允许多个 CA；空的签发机构值通常用于限制签发，但必须结合整个有效记录集合解读。[2]
若 CAA 值还带有验证方式或 ACME 账户限制，机构标识一致也未必满足全部条件。应核对这些附加限制是否适用于当前托管申请。[4]
如果平台提示需要补充 CA 授权，建议按下面的顺序修改：
- 导出现有 CAA 记录，记录 TTL 和修改前的内容。
- 找出本次申请使用的 CA，以及平台是否可能在多个 CA 之间选择。
- 在保留现有业务授权的基础上，添加平台明确要求的机构标识。
- 等待实际 DNS 查询返回更新后的集合，再重试一次申请。
托管证书平台可能使用不同 CA。Cloudflare 的官方文档说明，Universal SSL 在相应条件下会自动添加 CAA 授权，但 Advanced Certificate Manager 不会同样自动添加。[5] 因此需要先确认所用产品的处理方式，再检查它要求的 CA 集合。 不建议通过删除全部 CAA 来试错；调整前也应确认现有证书续期是否依赖原来的授权。
域名接入记录与证书验证记录要分别核对
“域名已添加到 CDN”与“CA 已验证域名控制权”是两个检查项目。平台要求的验证记录，可能是 TXT，也可能是专门的 CNAME，应按当前订单提供的名称和值逐字填写。
例如 DNS-01 方式常用 _acme-challenge 名称：
dig _acme-challenge.example.com TXT +noall +answer +comments
不要把这个名称当成所有平台的通用要求。某些托管证书提供另一种专用验证名称，必须查询订单实际要求的完整名称。DNS 面板自动追加域名时，填写完整名称可能造成域名重复，需要在提交后查询确认。
Let’s Encrypt 的 HTTP-01 验证通过 80 端口访问挑战文件，不能用于通配符证书；DNS-01 验证使用 TXT 记录，并可用于通配符名称。[6] 这是对应验证方式的要求，并不表示所有 CDN 托管证书都要去源站放置挑战文件。
如果当前订单使用 HTTP 验证，核对指定的挑战路径是否能从外部访问，是否被鉴权、WAF、错误的重定向或旧缓存影响。平台要求 DNS 验证时，应优先完成其 DNS 记录，不要额外改动源站验证目录。
有 SERVFAIL 时，先恢复正常的 DNS 响应
CAA 检查依赖可用的 DNS 查询。记录看起来正确，查询却返回错误时，签发仍可能受阻。DNSSEC 配置异常也是 Let’s Encrypt 官方 CAA 排障文档列出的检查项。[4]
可以对比不同解析器的结果，并查询域名当前的权威服务器：
dig @1.1.1.1 www.example.com CAA +noall +answer +comments
dig @8.8.8.8 www.example.com CAA +noall +answer +comments
dig example.com NS +short
进一步查询当前权威服务器时，将下面的示例名称替换为实际 NS：
dig @ns1.dns-provider.example example.com CAA \
+noall +answer +comments
跨解析器结果不同，可以作为缓存或解析链路差异的线索，不能单凭一次差异就确认故障原因。若权威记录正确，但验证型解析器持续报错，应核对近期是否迁移了 DNS 托管、调整了 DNSSEC 或留下不匹配的 DS 记录。DNSSEC 更改涉及域名注册商和 DNS 托管方，需要依照双方流程处理。
不要把取消 DNSSEC 当作默认修复动作。先确定错误位置，保留原配置，并在修复后复查 CAA 与验证记录。
区分 CA 授权与账户操作权限
CAA 放行之后，平台账户还可能没有执行相应操作的权限。只有当控制台或接口明确出现账户权限错误时，再检查角色、资源范围与所需操作，避免无依据地扩大授权。
例如 AWS ACM 的操作权限受 IAM 策略控制，与域名 DNS 中的 CAA 记录分别管理。[7] 给某个账户增加权限不会自动修正 CAA，修改 CAA 也不会让一个无权限账户获得申请或读取证书的能力。
核查时记录失败操作的名称和资源范围，把权限限制在完成该操作所需的范围。DNS 验证涉及的 DNS 账户权限，也需要与证书平台账户分别检查。
已签发之后，检查 CDN 实际返回的证书
控制台状态变成“已签发”后，还要确认它已经绑定到需要使用的 CDN 域名，并完成平台的部署流程。访客访问 CDN 域名时看到的证书，与 CDN 回源到服务器时使用的证书，应分别检查。
可以查看当前域名实际返回的证书信息：
openssl s_client -connect www.example.com:443 \
-servername www.example.com </dev/null 2>/dev/null | \
openssl x509 -noout -subject -issuer -dates
curl -I https://www.example.com/
第一条命令用于查看服务器返回的证书主体、签发者和日期；它本身不构成完整的可信性验收。第二条请求保留正常的 HTTPS 验证，用于检查访问时是否出现证书错误。[8][9] 验收时不要添加跳过证书验证的选项。
平台状态、证书信息和实际访问都检查通过之后，把验证记录、CAA、续期方式和监控责任写入站点运维记录。使用 DNS 验证的托管证书，应按平台续期说明保留必要记录；新证书目前能用，也不意味着下一次续期一定具备相同条件。
官方参考资料
资料核验日期：2026 年 10 月 13 日。平台能力及 CA 清单以当前官方文档为准。示例命令用于排查说明，未在读者的生产环境上执行。