IETF 协议规范进度

IETF 草案标准进展

草案名称: draft-ietf-acme-dns-persist
Draft-002025-06-18

初始规范草案提交。提出了 dns-persist-01 验证机制，旨在规避传统 dns-01 中每次签发均需高权限修改并暴露 DNS API 密钥的安全短板。

Draft-012026-03-24

ACME 工作组活跃草案。细化了委托关系、Account Thumbprint 绑定规则、重定向限制以及防止子域名越权的安全控制机制。

IESG ReviewTBD

提交至互联网工程指导组 (IESG) 评议审查。解决工作组之外的更广泛同行安全反馈及最后的文本审核。

RFC ProposedTBD

正式获批并分配编号出版为 Proposed Standard，成为全球 ACME 客户端与各大 CA 机构普遍遵循 of 证书颁发标准协议。

运行环境对比

各大证书颁发机构 (CA) 支持矩阵

提示：点击下方状态单元格可查看详细的探针探测日志。

运行环境Let's EncryptGoogle Trust ServicesZeroSSLBuyPass
Staging (测试环境)已支持已支持N/A (无测试环境)N/A (已停服)
Production (正式环境)不支持不支持不支持N/A (已停服)
Let's Encrypt
Staging (测试环境)已支持
Production (正式环境)不支持
Google Trust Services
Staging (测试环境)已支持
Production (正式环境)不支持
ZeroSSL
Staging (测试环境)N/A
Production (正式环境)不支持
BuyPass
Staging (测试环境)已停服
Production (正式环境)已停服

我们提供了一个开放的、兼容 CORS 的静态 API 接口供您的监控脚本或运维面板集成。您可以随时请求下方的 API 地址，它将实时返回与本站完全同步的 JSON 状态数据。

GEThttps://acme-monitor.pages.dev/api/v1/status

传统 `dns-01` 的安全隐患

传统的 `dns-01` 验证挑战，在每次证书签发或续期时都需要向域名的 DNS 记录中添加一个随机值的临时 TXT 记录（_acme-challenge）。这意味着您的 Web 服务器、证书自动管理脚本或边缘网关上，必须长期保存拥有高写入权限的 DNS 厂商 API 密钥。如果服务器被攻破，攻击者能控制您的整套 DNS 系统，修改任意记录甚至劫持企业流量，产生了极大的“安全爆炸半径”。

`dns-persist-01` 的安全革命

而持久化挑战 `dns-persist-01` 引入了一次性配置机制。域名管理员只需要在 DNS 中添加一条一次性的持久验证指向记录（_validation-persist），显式授权特定的 CA (如 letsencrypt) 以及特定的 ACME Account Thumbprint。配置完成后，随后的证书续签完全由 CA 自动验证，Web 服务器不再需要连接或保存任何 DNS API 密钥，从而将 DNS 权限从生产机器中完全剥离，实现了真正的安全隔离。

DNS 验证记录示例

# 在您的域 (example.com) 中添加一条持久化 DNS TXT 记录 # 记录主机 (Host): _validation-persist # 记录内容指定了信赖的 CA (letsencrypt.org) 和 ACME 账户指纹 _validation-persist.example.com. IN TXT "ca=letsencrypt.org;account=https://acme-staging-v02.api.letsencrypt.org/acme/acct/305547"

* 注意：具体的 TXT 记录协议设计与绑定语义正随着 IETF ACME 草案迭代进行微调，以杜绝反向越权安全隐患。