1. Introduction (简介)

Web PKI 中的证书 [RFC5280] 最常用于认证域名 (Domain Names)。因此, Web PKI 中的证书颁发机构 (Certification Authorities, CAs) 被信任验证证书申请人合法代表证书中的域名。

不同类型的证书反映了 CA 对证书主体信息的不同验证级别。"域名验证" (Domain Validation, DV) 证书是迄今为止最常见的类型。在 DV 证书颁发过程中, CA 唯一需要执行的验证是确认请求者有效控制该域名 [CABFBR]。CA 不需要尝试验证请求者的真实身份。(这与 "组织验证" (Organization Validation, OV) 和 "扩展验证" (Extended Validation, EV) 证书不同, 后者的流程还旨在验证请求者的真实身份。)

现有的 Web PKI 证书颁发机构倾向于使用一组临时协议 (Ad Hoc Protocols) 进行证书颁发和身份验证。对于 DV 证书, 典型的用户体验如下:

生成 PKCS#10 [RFC2986] 证书签名请求 (Certificate Signing Request, CSR)。
将 CSR 复制粘贴到 CA 的网页中。
通过以下方法之一证明对 CSR 中域名的所有权:
- 在 Web 服务器的特定位置放置 CA 提供的挑战 (Challenge)。
- 在与目标域名对应的 DNS 记录中放置 CA 提供的挑战。
- 在与域名对应的 (希望是) 管理员控制的电子邮件地址接收 CA 提供的挑战, 然后在 CA 的网页上响应。
下载颁发的证书并将其安装在用户的 Web 服务器上。

除了 CSR 本身和颁发的证书外, 这些都是完全临时的程序, 通过让人类用户遵循 CA 的交互式自然语言指令来完成, 而不是通过机器实现的已发布协议。在许多情况下, 这些指令难以遵循, 并导致严重的挫折和困惑。作者进行的非正式可用性测试表明, 网站管理员通常需要 1-3 小时才能为域名获取和安装证书。即使在最好的情况下, 缺乏已发布的标准化机制也会阻碍 HTTPS 和其他依赖 PKIX 的系统的广泛部署, 因为它抑制了与证书颁发、部署和吊销相关任务的机械化。

本文档描述了一个可扩展框架, 用于自动化证书颁发和域名验证过程, 从而允许服务器和基础设施软件在无需用户交互的情况下获取证书。使用此协议应该能够极大地简化 HTTPS 的部署, 以及基于传输层安全 (Transport Layer Security, TLS) [RFC8446] 的其他协议中基于 PKIX 的身份验证的实用性。

应当注意的是, 虽然本文档的重点是验证域名以在 Web PKI 中颁发证书, 但 ACME 支持在其他 PKI 上下文中使用其他标识符的扩展。例如, 在撰写本文时, 正在进行使用 ACME 颁发证明 IP 地址的 Web PKI 证书 [ACME-IP] 和证明电话号码的安全电话身份重访 (Secure Telephone Identity Revisited, STIR) 证书 [ACME-TELEPHONE] 的工作。

ACME 还可以用于自动化证书管理的某些方面, 即使在仍然需要非自动化流程的情况下也是如此。例如, 外部账户绑定 (External Account Binding) 功能 (参见第 7.3.4 节) 可以允许 ACME 账户使用已授予外部非 ACME 账户的授权。这使得 ACME 能够处理尚无法完全自动化的颁发场景, 例如 "扩展验证" 证书的颁发。