实操教程约 5 分钟阅读

用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne

当主域名的 DNS 不便开放 API 时，可以用 CNAME 把 _acme-challenge 委托给一个可自动化的子区域完成 DNS-01 签发，再将证书自动部署到 EdgeOne 边缘节点。本文给出前置条件、具体步骤和验证方法。

本文目录
用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne

从一个常见卡点开始

证书要续期了，ACME 客户端要往 DNS 里写 TXT 记录，但你的主域名解析在服务商 A，API 密钥涉及一堆其他业务记录，不想给自动化程序。域名还挂在 EdgeOne 上做加速，证书还得推到边缘。两条路看起来都不顺。

其实 DNS-01 有个很实用的特性：验证用的 _acme-challenge 记录可以被 CNAME 指走，指向另一个你愿意开放 API 的区域。CA 查询时会顺着 CNAME 找到真正的 TXT，验证照常通过。这样主域名只需要改一次 CNAME，之后所有的 TXT 写入都发生在专用区域里，主区域的密钥一根手指头都不用交出去。

用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 从一个常见卡点开始
用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 从一个常见卡点开始查看原图

前置条件

开始前确认这几件事：

  • 你能在主域名的 DNS 里加一条 CNAME 记录（一次性操作）。
  • 有一个用于承接验证的子区域（可以是主域下的子域，也可以是完全独立的域名），其 DNS 提供方有 API，且你的 ACME 客户端支持。
  • 一台能跑 ACME 客户端、能访问 EdgeOne 控制面 API 的机器。
  • 目标域名已通过 EdgeOne 的接入校验，清楚证书要绑定到哪个站点。

步骤

用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 前置条件
用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 前置条件查看原图

1. 规划委托目标。 选一个专用区域，比如 acme-dns.example.net。每个要签发的域名在其中对应一条记录，例如 www-example-com.acme-dns.example.net。用独立域名还是主域子区都行，关键只有一个：这个区域的 DNS API 可以安全地交给自动化程序。

2. 在主域名 DNS 里加 CNAME。 为每个要签的域名加一条：

_acme-challenge.www.example.com  CNAME  www-example-com.acme-dns.example.net

注意左边必须带 _acme-challenge 前缀，这是 CA 实际查询的名字。加完后用 dig _acme-challenge.www.example.com CNAME 确认解析生效，再继续往下走——这一步没生效，后面全是白忙。

用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 步骤
用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 步骤查看原图

3. 配置 ACME 客户端走 DNS-01。 客户端的 DNS 插件指向专用区域的 API 凭证。大多数遵循 RFC 8555 的客户端在写 TXT 前会先解析 CNAME，把记录写到委托目标而不是原始名字，这正是我们需要的行为。如果你的客户端不支持 CNAME 跟随，就得显式告诉它验证区域在哪，配置前先翻它的文档确认。

4. 首次签发。 触发一次签发，观察客户端日志：它应该把 TXT 写到了 acme-dns.example.net 里，而不是主域。签发失败时先 dig TXT www-example-com.acme-dns.example.net 看记录到底写没写进去，再查传播等待时间是否够长——DNS 传播是 DNS-01 最常见的翻车点，没有之一。

5. 部署到 EdgeOne。 拿到证书和私钥后，通过 EdgeOne 的证书管理接口上传并绑定到对应站点。部署完成后，换一个未缓存的网络或用 openssl s_client -connect your-site.example.com:443 -servername your-site.example.com 看证书链和有效期，确认边缘节点确实换上了新证书。

6. 跑通续期闭环。 手动触发一次续期（哪怕证书还很新），确认整条链路——写 TXT、签发、推送 EdgeOne——能无人值守跑完。只验证首次签发是不够的，续期才是日常。

用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 验证清单
用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 验证清单查看原图

验证清单

  • dig CNAME _acme-challenge.<域名> 返回委托目标。
  • 续期演练后，专用区域里出现了新的 TXT。
  • EdgeOne 控制面显示证书已更新，s_client 看到的 Not After 时间已顺延。
  • 主域名的其他记录在整个过程中未被触碰。

在 CertbotX 中实践

这套流程正是 CertbotX 覆盖的场景：配置 DNS-01 时直接填写 CNAME 委托的目标区域，签发和到期前自动重新签发由 ACME 流程托管，不需要 cron 自己拼。签发后的证书可以自动部署到 EdgeOne 或其他 CDN，也可以在 Agent 节点上落盘。每次部署都有记录可查，出了问题能回溯是哪一次、推到了哪里，而不是对着边缘节点猜。

用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 在 CertbotX 中实践
用 CNAME 委托把 ACME DNS-01 验证甩给专用区域，再把证书自动推到 EdgeOne：a concrete operational scene explaining this section: 在 CertbotX 中实践查看原图

几个小坑

  • CNAME 链别套娃。多级跳转有的 CA 容忍、有的客户端解析得慢，一跳最省心。
  • 专用区域的 API 凭证按最小权限给，只允许改 TXT 相关记录。
  • 别忘了 CAA 记录：如果域名设了 CAA，确认里面包含你用的 CA，否则 DNS 全对也签不下来。

延伸阅读：

← 返回资讯中心