截至2026年，Let's Encrypt已为超过3亿个域名提供证书服务，ACME也从最初的社区草案发展为IETF正式标准（RFC 8555），成为现代PKI体系中最重要的协议之一。本文将从架构设计、验证机制、工作流程、安全模型等维度，对ACME协议的技术原理进行系统性深度解析。

一、ACME协议概述

1. 设计目标

ACME协议的核心设计目标可概括为四点：自动化、安全、可扩展、去中心化。它旨在消除证书管理中的人工操作，通过标准化的RESTful API实现域名控制权验证与证书生命周期管理的全自动化，同时保证验证过程的密码学安全性。

与传统CA的人工审核、邮件验证、文件上传等方式不同，ACME将所有操作抽象为标准化的HTTP接口，客户端程序（如Certbot、acme.sh、lego等）通过调用这些接口即可完成全部证书管理操作，极大降低了部署与运维成本。

2. 版本演进

ACME协议经历了两个主要阶段：

• ACME v1：Let's Encrypt最初的实现版本，基于早期社区草案，采用基于路径的API设计，支持HTTP-01、TLS-SNI-01、DNS-01等验证方式。由于TLS-SNI-01存在安全缺陷已被废弃，v1协议已于2021年逐步停用。
• ACME v2（RFC 8555）：IETF标准化版本，引入了更严谨的目录发现机制、JWS签名认证、订单模型、授权对象等核心概念，新增TLS-ALPN-01验证方式，支持通配符证书，架构更具扩展性与安全性。

当前主流实现均基于ACME v2标准，也是本文讨论的核心版本。

二、ACME核心架构与核心概念

1. 客户端-服务器模型

ACME采用典型的客户端-服务器架构：

• ACME服务器：部署在CA侧（如Let's Encrypt的boulder系统），提供RESTful API端点，负责验证域名控制权、签发与撤销证书。
• ACME客户端：运行在用户服务器上的软件，负责生成密钥、发起请求、完成验证挑战、部署证书。

所有通信均基于HTTPS传输，请求体采用JSON格式，且所有操作请求必须使用客户端账户私钥进行JWS（JSON Web Signature）签名，确保请求的身份真实性与完整性。

2. 核心实体概念

RFC 8555定义了几个关键实体，构成了ACME协议的状态机模型：

（1）目录（Directory）

ACME服务的入口端点，返回所有可用API的URL列表，包括新建订单、新建账户、获取非数、撤销证书等端点。客户端首次接入时通过GET请求目录地址发现服务能力，实现了服务端配置变更的平滑兼容。

（2）账户（Account）

客户端在服务端的身份标识，由客户端生成的RSA或ECDSA密钥对绑定。账户包含联系人信息、状态、外部账户绑定等属性。所有后续操作均通过账户密钥签名进行认证，替代了传统的用户名密码体系。

（3）订单（Order）

证书签发请求的抽象载体，对应一次证书签发流程。订单包含待签发的域名列表、状态、授权引用、最终证书颁发URL等信息。客户端通过创建订单启动签发流程，服务端返回需要完成的验证挑战。

（4）授权（Authorization）

每个域名对应一个授权对象，表示服务端对该域名控制权的验证过程。授权对象包含域名标识符、状态、过期时间以及可用的挑战方式列表。当某一挑战验证成功后，对应授权变为"valid"状态，客户端获得该域名的签发授权。

（5）挑战（Challenge）

具体的域名验证手段，即客户端需要完成的证明任务。ACME标准定义了多种挑战类型，每种类型对应不同的验证信道与操作方式。客户端选择一种可执行的挑战并完成部署，随后通知服务端进行校验。

三、核心域名验证机制详解

域名控制权验证是ACME协议的核心，也是CA签发证书的信任基础。ACME v2标准主要支持三种验证方式，各自适用于不同场景。

1. HTTP-01 验证

这是最常用的验证方式，基于HTTP信道完成。

（1）验证原理：服务端生成一个随机令牌（token），客户端需要将特定内容部署在域名下 /.well-known/acme-challenge/ 路径中。服务端从公网访问该URL，若返回内容与预期一致，则证明客户端拥有该域名的Web服务器控制权。

（2）具体计算过程：

1）服务端生成随机token，返回给客户端

2）客户端计算密钥授权值： keyAuthorization = token + "." + base64url(sha256(accountPublicKey))

3）客户端在Web根目录创建文件 /.well-known/acme-challenge/{token} ，文件内容为keyAuthorization

4）客户端通知服务端验证，服务端向 http://{domain}/.well-known/acme-challenge/{token} 发起HTTP请求

5）若响应状态码为200且内容匹配，验证通过

（3）优缺点：部署简单，无需DNS解析权限，仅需Web服务器可访问；但无法验证域名的完全控制权（仅验证Web服务控制权），且不支持通配符证书，80端口必须对外开放。

2. DNS-01 验证

基于DNS信道的验证方式，是通配符证书的唯一验证手段。

（1）验证原理：客户端需要在域名的 _acme-challenge 子域名下添加一条TXT记录，记录值为特定哈希结果。服务端通过DNS查询该TXT记录，验证通过即证明客户端拥有该域名的DNS管理权。

（2）具体计算过程：

1）服务端生成随机token，返回给客户端

2）客户端计算keyAuthorization（同HTTP-01）

3）对keyAuthorization进行SHA-256哈希，再做base64url编码得到digest

4）客户端在DNS中添加记录： _acme-challenge.{domain}. TXT "digest"

5）等待DNS传播后，客户端通知服务端验证

6）服务端执行DNS查询，比对TXT记录值与预期值是否一致

（3）优缺点：验证域名的完全控制权，支持通配符证书，无需开放80/443端口；但部署相对复杂，需要DNS服务商API支持，且DNS传播存在延迟，验证耗时较长。

3. TLS-ALPN-01 验证

基于TLS扩展的验证方式，专门针对仅开放443端口的场景设计，替代了已废弃的TLS-SNI-01。

（1）验证原理：客户端在443端口上配置临时TLS证书，该证书的subjectAltName扩展包含待验证域名，且通过ALPN扩展协商"acme-tls/1"协议。服务端发起TLS握手时使用该ALPN协议，获取临时证书并验证其中的特殊扩展字段。

（2）核心设计：临时证书中必须包含一个类型为1.3.6.1.5.5.7.1.31的关键扩展，扩展值为keyAuthorization的SHA-256哈希。服务端通过校验该扩展值完成验证。由于使用了独立的ALPN协议标识，验证流量不会与正常HTTPS流量混淆，且不会影响正常站点服务。

（3）优缺点：仅需443端口，适合无法开放80端口的环境，安全性高于TLS-SNI-01；但需要ACME客户端直接处理TLS握手，集成复杂度较高，多数Web服务器原生不支持。

四、完整证书签发工作流程

一次完整的证书签发流程包含七个核心阶段，体现了ACME协议的状态机设计思想。

阶段1：目录发现与非数获取

客户端首先向ACME目录URL（如Let's Encrypt的 https://acme-v02.api.letsencrypt.org/directory ）发送GET请求，获取所有API端点地址与服务元数据。同时客户端从 newNonce 端点获取一个新鲜随机数（nonce），用于防止重放攻击，每个nonce只能使用一次。

阶段2：账户注册

客户端生成一对账户密钥对（通常为ECDSA P-256或RSA 2048），构造JWS签名的注册请求，发送至 newAccount 端点。请求体包含联系人邮箱、服务条款同意等信息。若该公钥未注册过，服务端创建新账户并返回账户URL；若已存在则直接返回现有账户。

账户URL是后续操作的身份标识，所有请求必须使用对应私钥签名。

阶段3：创建订单

客户端构造证书签发订单，指定需要包含的所有域名（支持多域名SAN证书），发送至 newOrder 端点。服务端返回订单对象，包含订单状态（pending）、每个域名对应的授权URL、最终证书提交的CSR URL。

阶段4：获取授权与挑战

客户端依次访问每个授权URL，获取该域名可用的挑战方式列表。客户端根据自身环境选择一种可执行的挑战类型（如HTTP-01），获取对应的token与挑战URL。

阶段5：部署挑战并触发验证

客户端按照所选挑战类型的要求完成部署（如放置验证文件、添加DNS记录），确认部署生效后，向对应挑战URL发送POST请求，通知服务端开始验证。

服务端收到通知后，从多个网络位置执行验证检查（Let's Encrypt采用多视角验证，防止单一路径的DNS劫持）。验证过程是异步的，客户端需要轮询授权URL查看状态变化。验证成功后授权状态变为"valid"，通常有效期为30天。

阶段6：提交CSR

当订单中所有域名的授权均变为valid状态后，订单状态更新为"ready"，客户端可以提交证书签名请求（CSR）。

客户端生成证书密钥对（与账户密钥独立），构造CSR文件，将其base64url编码后放入请求体，发送至订单的finalize URL。服务端校验CSR合法性与授权有效性，通过后签发证书，订单状态变为"valid"。

阶段7：下载证书

客户端访问订单返回的certificate URL，下载签发好的证书链。通常返回PEM格式，包含服务器证书与中间证书，客户端可直接部署到Web服务器中。

五、证书续期与撤销机制

1. 自动化续期

ACME协议的核心价值之一就是实现自动化续期。由于Let's Encrypt证书有效期仅90天，续期操作至关重要。

续期流程与首次签发基本一致，客户端可在证书到期前30天内发起新订单。由于授权存在30天有效期，若授权仍在有效期内，服务端会直接复用已有授权，无需重复验证，实现快速续期。

生产环境通常通过cron定时任务或systemd timer定期执行续期脚本，检测证书剩余有效期，不足阈值时自动触发续期流程并重载Web服务。

2. 证书撤销

ACME协议支持两种撤销方式：

• 账户密钥撤销：使用申请该证书的账户私钥对撤销请求签名，这是最常用的方式
• 证书密钥撤销：使用证书本身的私钥签名撤销请求，适用于账户密钥丢失但证书密钥仍在的场景

撤销请求发送至 revokeCert 端点，请求体包含base64编码的证书DER内容与撤销原因码。服务端验证通过后将证书加入CRL并更新OCSP响应。

六、安全设计与防护机制

1. 请求认证与防重放

所有修改操作均采用JWS签名，每个请求必须包含有效的nonce。服务端维护已使用nonce池，确保每个nonce只能使用一次，有效防止重放攻击。同时JWS签名绑定请求体内容，确保传输中数据不被篡改。

2. 多视角验证

Let's Encrypt等主流CA实现了多视角验证（Multi-Perspective Validation），服务端从全球多个不同网络位置同时发起验证请求，只有全部位置验证通过才视为成功。这一设计大幅提高了DNS劫持、BGP劫持等网络攻击的实施难度。

3. 速率限制

为防止滥用，ACME服务端实施多层速率限制：每个注册域名每周签发证书数量限制、每个IP每3小时创建账户数量限制、每个账户每3小时订单数量限制、验证失败速率限制等。既保障了正常用户使用，也遏制了自动化攻击与滥用。

4. 密钥分离设计

协议明确区分账户密钥与证书密钥，两者独立生成、独立使用。账户密钥用于身份认证，证书密钥用于TLS握手。即使服务器上的证书密钥泄露，攻击者也无法撤销证书或申请新证书，因为账户密钥可独立保管。

ACME协议通过精巧的状态机设计、标准化的RESTful接口与多样化的验证机制，彻底重构了SSL证书的签发与管理模式，将原本需要数小时人工操作的流程压缩至数秒内自动完成。它不仅是Let's Encrypt成功的技术基石，更是推动全网HTTPS普及的关键力量。

Dogssl.com拥有20年网络安全服务经验，提供构涵盖国际CA机构Sectigo、Digicert、GeoTrust、GlobalSign，以及国内CA机构CFCA、沃通、vTrus、上海CA等数十个SSL证书品牌。全程技术支持及免费部署服务，如您有SSL证书需求，欢迎联系!