如果让你手动给一个网站申请 SSL 证书，大概要经历生成密钥、填申请表、等邮件验证、下载证书、配服务器这一整套流程，少说也得折腾大半天。十年前，这件事几乎全靠人肉完成。把它彻底改变的，就是 ACME 协议。

ACME 全称是"自动证书管理环境"（Automatic Certificate Management Environment），其设计初衷是让网站服务器和证书颁发机构（CA）之间用程序进行自动对话，证书的申请、验证、签发、续期全程不需要人工插手。今天你在浏览器地址栏看到的那个小锁头，背后很大一部分是靠 ACME 在默默干活。

ACME 的早期版本（v1）自 2015 年起便随率先采用该协议的 Let’s Encrypt 投入实际使用（Let’s Encrypt 于 2016 年 4 月正式开放服务）。它确实把证书申请自动化了，但留下两个明显的短板。一是它不支持通配符证书——也就是能同时覆盖 *.example.com 下所有子域名的那一种，企业想保护一堆子站点，只能一个个单独申请。二是它的账号和验证流程设计得比较笨重，注册账号和同意服务条款是分开的两步，请求结构也和后来的标准不一样。更关键的是，v1 始终只是一份"工作组草案"，没被正式确立为互联网标准。

真正让 ACME 站稳脚跟的是第二版，也就是 2019 年 3 月正式发布的 RFC 8555。这一版和 v1 不兼容，但带来的变化是根本性的。最直观的一条：它支持通配符证书了，而根据 RFC 8555 的规定，通配符域名只能通过 DNS 验证（往域名里加一条 TXT 记录证明你控制了这个域）来完成签发，安全性反而更高。协议流程也被重写了——从"先验证再申请"改成"先下订单再验证"，更贴合实际签发逻辑；原来请求体里那个 resource 字段被挪到了 HTTP 头部的 url 里；账号注册和条款同意合并成一步。此外还加了外部账户绑定（EAB），让商业 CA 能把 ACME 账号和已有的客户系统挂钩，以及对账号密钥做轮换等运维能力。早期的两个验证方式 TLS-SNI-01/02 因安全漏洞被弃用，换成了更稳的 TLS-ALPN-01。

RFC 8555 不是终点。这几年 IETF 的 ACME 工作组在标准之上又叠加了不少扩展：支持 IP 地址证书的 RFC 8738（2020 年 2 月）、支持短有效期自动续签证书（STAR）的 RFC 8739（2020 年 3 月），面向物联网设备证书自动签发场景的方案也正在推进中。2025 年 6 月，ACME 续期信息扩展 ARI（RFC 9773）正式发布——它让 CA 可以主动告诉客户端"你该提前续期了"，在大规模吊销等突发状况下能避免网站集体掉线。

值得一提的是，2025 年 4 月，CA/Browser Forum 通过投票（SC-081v3），分阶段压缩公开信任 SSL/TLS 证书的最长有效期：2026 年 3 月 15 日起为 200 天，2027 年 3 月 15 日起为 100 天，2029 年 3 月 15 日起进一步降至 47 天。证书越来越短命，人工续期越来越不现实，ACME 这类自动化协议的重要性反而被推到了前台。从最初"帮小网站省点麻烦"，到今天撑起整个公钥信任体系的自动化底座，ACME 这十年的演进，其实就是 Web 安全从"能用就行"走向"必须自治"的缩影。

中域永信基于 ACME v2（RFC 8555）标准开发的 AutoSSL 证书管理系统，将证书的申请、验证、部署、续期等环节交由系统自动处理，可减少证书运维中的人工操作、降低证书过期未续的风险，适用于证书数量较多、续期频率较高的企业场景。具体功能与支持范围，以中域永信官网及产品说明为准。【广告】

技术内容参考：IETF RFC 8555（2019年3月）、RFC 8738（2020年2月）、RFC 8739（2020年3月）、RFC 9773（2025年6月）及 CA/Browser Forum Ballot SC-081v3（2025年4月通过）。

免责声明：以上分析仅供参考，不构成正式法律意见。广告合规以监管机关个案认定为准。