RFC 8555 - 自动化证书管理环境 (Automatic Certificate Management Environment, ACME)

互联网工程任务组 (IETF)
请求评论: 8555
类别: 标准跟踪
ISSN: 2070-1721

作者:
R. Barnes (Cisco)
J. Hoffman-Andrews (EFF)
D. McCarney (Let's Encrypt)
J. Kasten (University of Michigan)

发布日期: 2019年3月

摘要 (Abstract)

使用X.509的公钥基础设施 (Public Key Infrastructure using X.509, PKIX) 证书用于多种目的，其中最重要的是域名认证。因此，Web PKI中的证书颁发机构 (Certification Authorities, CAs) 被信任验证证书申请人合法代表证书中的域名。截至本文撰写时，这种验证是通过一系列临时机制完成的。本文档描述了CA和申请人可以用来自动化验证和证书颁发过程的协议。该协议还提供了其他证书管理功能的设施，例如证书吊销。

本备忘录的状态 (Status of This Memo)

这是一份互联网标准跟踪文档。

本文档是互联网工程任务组 (IETF) 的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导组 (IESG) 批准发布。

目录 (Table of Contents)

1. 简介 (Introduction)
2. 部署模型和操作体验 (Deployment Model)
3. 术语表 (Terminology)
4. 协议概述 (Protocol Overview)
5. 字符编码 (Character Encoding)
6. 消息传输 (Message Transport)
- 6.1 HTTPS请求
- 6.2 请求认证
- 6.3 GET和POST-as-GET请求
- 6.4 请求URL完整性
- 6.5 重放保护
- 6.6 速率限制
- 6.7 错误
7. 证书管理 (Certificate Management)
8. 标识符验证挑战 (Validation Challenges)
- 8.1 密钥授权
- 8.2 重试挑战
- 8.3 HTTP挑战
- 8.4 DNS挑战
9-12. 关键章节摘要
- 9. IANA考虑事项
- 1. 安全考虑
- 1. 操作考虑
- 1. 参考文献

1. 简介

Web PKI中的证书最常用于认证域名。因此，Web PKI中的证书颁发机构被信任验证证书申请人合法代表证书中的域名。

证书类型反映了CA对证书主体信息的不同验证级别:

域名验证 (Domain Validation, DV): 最常见的类型，CA只需验证申请人有效控制域名
组织验证 (Organization Validation, OV): 验证组织的真实身份
扩展验证 (Extended Validation, EV): 最严格的验证，包括详细的身份核实

现有的Web PKI证书颁发机构倾向于使用一组临时协议进行证书颁发和身份验证。对于DV证书，典型的用户体验是:

生成PKCS#10证书签名请求 (Certificate Signing Request, CSR)
将CSR复制粘贴到CA的网页中
通过各种方式证明域名控制权 (电子邮件验证、文件验证等)
手动下载颁发的证书

ACME的目标: 标准化和自动化整个流程，使证书获取和更新完全自动化。

2. 部署模型和操作体验

典型ACME工作流程:

客户端 (ACME Client)                    ACME服务器 (CA)
       |                                        |
       |  1. 创建账户                           |
       |--------------------------------------->|
       |     <-- 账户URL                       |
       |                                        |
       |  2. 提交证书订单                       |
       |--------------------------------------->|
       |     <-- 订单对象 + 授权挑战           |
       |                                        |
       |  3. 完成域名验证挑战                   |
       |     (HTTP-01 或 DNS-01)               |
       |--------------------------------------->|
       |     <-- 验证成功                      |
       |                                        |
       |  4. 完成订单 (提交CSR)                 |
       |--------------------------------------->|
       |     <-- 证书URL                       |
       |                                        |
       |  5. 下载证书                           |
       |--------------------------------------->|
       |     <-- PEM格式证书链                 |

自动化好处:

⚡ 零人工干预: 完全自动化的证书申请和更新
🔄 频繁更新: 支持短期证书 (Let's Encrypt默认90天)
💰 降低成本: 消除手动流程成本
🔒 提高安全性: 短期证书减少泄露风险

3. 术语表

ACME客户端 (ACME Client)
实现ACME协议的客户端软件，代表证书申请人与CA交互。

ACME服务器 (ACME Server)
CA运行的服务器，实现ACME协议以自动颁发证书。

账户 (Account)
客户端在ACME服务器上的注册，关联密钥对和联系信息。

订单 (Order)
客户端请求颁发证书的请求对象。

授权 (Authorization)
证明客户端控制标识符 (通常是域名) 的对象。

挑战 (Challenge)
ACME服务器要求客户端完成的验证任务。

标识符 (Identifier)
证书中要认证的名称，通常是域名。

4. 协议概述

ACME协议基于HTTPS和JSON，使用JSON Web Signature (JWS) 进行请求认证。

4.1 核心资源类型

Directory: 服务器API端点的目录
Account: 客户端账户信息
Order: 证书订单
Authorization: 域名授权
Challenge: 验证挑战
Certificate: 颁发的证书

4.2 典型流程

步骤1: 账户创建

POST /acme/new-account HTTP/1.1
Host: acme.example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "jwk": {...账户公钥...},
    "nonce": "6S8IqOGY7eL2lsGoTZYifg",
    "url": "https://acme.example.com/acme/new-account"
  }),
  "payload": base64url({
    "termsOfServiceAgreed": true,
    "contact": [
      "mailto:[email protected]"
    ]
  }),
  "signature": "...签名..."
}

步骤2: 创建订单

{
  "identifiers": [
    {"type": "dns", "value": "example.com"},
    {"type": "dns", "value": "www.example.com"}
  ]
}

步骤3: 完成挑战

见第8节。

步骤4: 完成订单

提交CSR。

步骤5: 下载证书

从证书URL下载PEM格式的证书链。

5. 字符编码

ACME使用UTF-8编码所有字符串。

6. 消息传输

6.1 HTTPS请求

所有ACME通信必须 (MUST) 使用HTTPS。

6.2 请求认证

ACME使用JWS签名认证请求:

{
  "protected": "base64url(JSON({
    "alg": "ES256",          // 签名算法
    "kid": "account_url",    // 账户密钥ID
    "nonce": "...",          // 防重放随机数
    "url": "..."             // 请求URL
  }))",
  "payload": "base64url(...)", // 请求体
  "signature": "..."          // 签名
}

6.3 GET和POST-as-GET请求

ACME主要使用POST请求，即使获取资源也使用POST-as-GET (空payload)。

6.4 请求URL完整性

JWS的url头参数确保请求不被重定向。

6.5 重放保护

6.5.1 Replay-Nonce

服务器在响应中包含Replay-Nonce头:

Replay-Nonce: oFvnlFP1wIhRlYS2jTaXbA

6.5.2 "nonce" JWS头参数

客户端在后续请求的JWS头中包含此nonce。

6.6 速率限制

服务器可能实施速率限制，返回429状态码。

6.7 错误

ACME使用RFC 7807问题详细信息格式:

{
  "type": "urn:ietf:params:acme:error:rateLimited",
  "detail": "请求过于频繁",
  "status": 429
}

7. 证书管理

7.1 资源

7.1.1 Directory (目录)

{
  "newNonce": "https://acme.example.com/acme/new-nonce",
  "newAccount": "https://acme.example.com/acme/new-account",
  "newOrder": "https://acme.example.com/acme/new-order",
  "revokeCert": "https://acme.example.com/acme/revoke-cert",
  "keyChange": "https://acme.example.com/acme/key-change",
  "meta": {
    "termsOfService": "https://example.com/acme/terms",
    "website": "https://www.example.com/",
    "caaIdentities": ["example.com"]
  }
}

7.1.2 Account对象

{
  "status": "valid",
  "contact": [
    "mailto:[email protected]"
  ],
  "termsOfServiceAgreed": true,
  "orders": "https://acme.example.com/acme/acct/1/orders"
}

7.1.3 Order对象

{
  "status": "pending",
  "expires": "2024-12-31T00:00:00Z",
  "identifiers": [
    {"type": "dns", "value": "example.com"}
  ],
  "authorizations": [
    "https://acme.example.com/acme/authz/1"
  ],
  "finalize": "https://acme.example.com/acme/order/1/finalize"
}

7.1.4 Authorization对象

{
  "status": "pending",
  "expires": "2024-12-31T00:00:00Z",
  "identifier": {
    "type": "dns",
    "value": "example.com"
  },
  "challenges": [
    {
      "type": "http-01",
      "url": "https://acme.example.com/acme/chall/1",
      "token": "DGyRejmCefe7v4NfDGDKfA"
    }
  ]
}

8. 标识符验证挑战

8.1 密钥授权 (Key Authorizations)

密钥授权是挑战验证的核心:

keyAuthorization = token + '.' + base64url(SHA256(accountKey))

8.2 重试挑战

客户端应该使用指数退避重试失败的挑战。

8.3 HTTP挑战 (HTTP-01)

验证方式: 在域名的特定路径放置文件。

挑战对象:

{
  "type": "http-01",
  "url": "https://acme.example.com/acme/chall/1",
  "status": "pending",
  "token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0"
}

客户端响应:

在http://example.com/.well-known/acme-challenge/{token}放置包含keyAuthorization的文件:

LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI

8.4 DNS挑战 (DNS-01)

验证方式: 创建特定的DNS TXT记录。

DNS记录:

_acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

其中值是:

base64url(SHA256(keyAuthorization))

9. IANA考虑

ACME注册了多个新的IANA资源:

媒体类型: application/pem-certificate-chain
Well-Known URI: /.well-known/acme-challenge
HTTP头: Replay-Nonce
JWS头参数: url, nonce
URN命名空间: urn:ietf:params:acme

10. 安全考虑

10.1 威胁模型

ACME面临的主要威胁:

未授权证书颁发: 攻击者获取他们不控制的域名的证书
账户劫持: 攻击者控制合法用户的ACME账户
拒绝服务: 攻击者阻止合法证书颁发
重放攻击: 重用旧的有效请求

10.2 授权的完整性

ACME使用以下机制保护授权:

密钥绑定: 挑战与账户密钥绑定
TLS要求: 所有通信必须加密
Nonce机制: 防止重放攻击

10.3 拒绝服务考虑

CA应该实施速率限制和资源配额。

10.4 服务器端请求伪造 (SSRF)

HTTP-01挑战可能被用于SSRF攻击，CA应该:

拒绝私有IP地址
限制重定向
超时设置

10.5 CA策略考虑

CA应该制定政策关于:

验证方法的选择
证书有效期
吊销条件

11. 操作考虑

11.1 密钥选择

推荐使用:

ECDSA P-256或P-384
RSA 2048位或更高

11.2 DNS安全

使用DNS-01挑战时，确保DNS基础设施安全。

11.3 令牌熵

挑战令牌必须具有足够的熵 (至少128位)。

11.4 畸形证书链

客户端应该验证下载的证书链的完整性。

12. 参考文献

12.1 规范性参考文献

[RFC2119] - 关键词定义
[RFC5280] - X.509证书和CRL配置
[RFC7515] - JSON Web Signature (JWS)
[RFC7518] - JSON Web Algorithms (JWA)
[RFC8555] - 本文档

ACME协议是Let's Encrypt的核心技术，使免费HTTPS证书成为现实。主要特点:

✅ 完全自动化: 从申请到更新全自动
✅ 标准化: IETF标准，多家CA支持
✅ 安全: 基于加密签名和挑战-响应验证
✅ 灵活: 支持HTTP和DNS验证方式

流行的ACME客户端:

Certbot (EFF官方)
acme.sh (Shell脚本)
Lego (Go语言)
win-acme (Windows)

相关RFC:

RFC 7515 - JSON Web Signature
RFC 5280 - X.509证书
RFC 6797 - HSTS

摘要 (Abstract)​

本备忘录的状态 (Status of This Memo)​

目录 (Table of Contents)​

1. 简介​

2. 部署模型和操作体验​

3. 术语表​

4. 协议概述​

4.1 核心资源类型​

4.2 典型流程​

5. 字符编码​

6. 消息传输​

6.1 HTTPS请求​

6.2 请求认证​

6.3 GET和POST-as-GET请求​

6.4 请求URL完整性​

6.5 重放保护​

6.5.1 Replay-Nonce​

6.5.2 "nonce" JWS头参数​

6.6 速率限制​

6.7 错误​

7. 证书管理​

7.1 资源​

7.1.1 Directory (目录)​

7.1.2 Account对象​

7.1.3 Order对象​

7.1.4 Authorization对象​

8. 标识符验证挑战​

8.1 密钥授权 (Key Authorizations)​

8.2 重试挑战​

8.3 HTTP挑战 (HTTP-01)​

8.4 DNS挑战 (DNS-01)​

9. IANA考虑​

10. 安全考虑​

10.1 威胁模型​

10.2 授权的完整性​

10.3 拒绝服务考虑​

10.4 服务器端请求伪造 (SSRF)​

10.5 CA策略考虑​

11. 操作考虑​

11.1 密钥选择​

11.2 DNS安全​

11.3 令牌熵​

11.4 畸形证书链​

12. 参考文献​

12.1 规范性参考文献​