ARI是什么？ACME自动续签证书为什么不能再“自己算时间”了
以前一直觉得证书续签这件事挺简单的，我们用各种 acme 客户端去申请证书，证书有效期 90 天，提前一点时间 acme 客户端会自动帮我们续掉，可以说什么时候续大家（包括acme客户端）心里都有数的，但刚刚却被惊出一身冷汗。
最近开始折腾 IP HTTPS 证书还写了一篇教程，大概讲的是如何用acme.sh申请IP证书自动续签并给宝塔面板部署，本来想去查看一下 acme.sh 的配置文件写的证书部署命令有没有错误（因为最开始我把证书文件和私钥文件的路径写反了），结果一看 .conf 里却写了个：
1 | Le_NextRenewTimeStr='2026-02-17T02:06:43Z' |
说人话，就是差不多等到60天后再续期，但是众所周不知，IP 证书的有效期只有 7 天，如果 60 天后再续期的话黄花菜都已经凉了，本来我以为工具计算错误了，后面看了代码：
我才意识到一件事，原来他根本没算，上面代码意思也很简单，默认续期时间是60天，如果你自己不指定或者传参错误，那程序就直接用默认的60天，也就是说不是工具写错了，而是这套“自己算时间”的逻辑，已经跟不上证书有效期逐步缩短的时代了，这也是 ARI 出现的背景。
ACME 一开始，根本没定义「什么时候续」
想要了解清楚整个背景，还要看一下 ACME（全称：Automated Certificate Management Environment） 这个协议本身，如果我们把时间拨回到 ACME 刚被标准化的时候，会发现一件挺有意思的事，ACME从一开始解决的目标就非常克制、也非常工程化。在核心规范 RFC 8555 里，协议关心的只有三件事：
- 你怎么证明你控制了这个标识符—— 域名、IP，或者其他资源
- CA 如何基于这个证明给你签发证书
- 证书到期后，如何再次完成签发流程
在这里突然想起了一句台词，我来鹅城只办三件事：公平！公平！还是公平！！！
所以如果你去翻 RFC 8555 的正文，会发现它对下面这些内容写得非常详细：
- challenge / response 的流程
- order、authorization、certificate 的状态机（听到状态机这个词是不是很懵圈：简单来说一件事在不同阶段，只允许做特定动作，就比如你打游戏新手村还没过，就不能去刷副本）
- 如何撤销证书、如何重新下单
但有一个问题，在整个规范里几乎没有被正面定义，那就是证书“应该在什么时候续签”？RFC 8555 并没有给出类似：
- “建议在证书有效期剩余 X% 时续签”
- “CA 会告知客户端续签时间窗口”
相反，规范的态度非常明确：
- ACME 只负责“能不能签”，
- 不负责“什么时候签”。
换句话来说，协议定义的是能力，而不是「策略」，举个更通俗的例子：这像不像长辈或者领导常说的那句：“这个东西，你心里有数就行。”
目标是明确的，但什么时候该跟进、什么时候该收尾、什么时候算做到位，全都没明说，只能靠你自己判断节奏。
这也就意味着，从 ACME 诞生的第一天起：“续签时机”就被默认成了客户端自己的责任。
于是，几乎所有 ACME 客户端——无论是 acme.sh、certbot，还是后来的各种实现——都只能自己设计续签策略，因为 ACME 申请下来的证书基本是都是90天的，所以大家最后都走向了同一套经验规则：
- 证书有效期 90 天
- 剩余 30～60 天时续签
- cron 每天跑，等时间到了再说
以宝塔面板为例，最开始给 Let’s 证书的续签策略是等到第 60 天的时候尝试续期（不过大家放心：随着 CA/B 宣布将证书有效期逐步缩短到 47 天之后，我们调整成了剩余时间不足三分之一的时候就开始尝试续签新的证书）
在 90 天证书的世界里，这套逻辑非常稳定，几乎没人觉得有问题，但问题来了。
短期证书一出现，这套逻辑开始失灵
使这套逻辑被打破的原因大概可以归纳为一点，那就是证书有效期逐步缩短到47天，这也从某种角度催化出了短期证书（short-lived certificate）成为了一套正式方案，或者说不得不用的方案（你想通过 ACME 客户端申请免费的 IP 证书，你只能用这套方案）
以 Let’s Encrypt 为例：
- IP 证书只能走 short-lived profile
- 有效期最长只有 160 小时
- 必须全自动续签，不能靠人记（其实也不是不可以，如果你不嫌麻烦）
那么问题来了，ACME 客户端看到的是什么？准确的来说应该是想的是什么？
哦豁～我又申请下来了一张证书，我来算一下什么时候续期，既然用户没有指定续期时间，那就等60天之后再续期吧，嘿嘿～
但是他不想知道或者并不知道：
- 这是一张 IP 证书
- 这张证书有效期不到 7 天
- 给我颁发这张证书的 CA 希望我在什么时间续期这张证书
于是就出现了今天早上吓的我直冒冷汗的事情，一张有效期不足 7 天的证书，续期时间居然是 60 天以后，看起来好像是个 bug ，但时代变了。其实 acme.sh 是手动可以指定续期时间的，你只需要手动加一下参数就好：
那这时候聪明的你一定想到，如果有个机制可以告诉 ACME 客户端，这张证书应该在什么时间来续签不就好了，那么恭喜你，发明了 ARI (ACME Renewal Information)
ARI 是干嘛的？一句话就够了
ARI = ACME Renewal Information，不过它并不是某个客户端实现里的“新功能”，而是 ACME 协议在后续规范中新增的一项正式扩展能力，来解决客户端不知道应该在什么时候续期证书的问题。
ARI 由 IETF 在 RFC 9773 中引入，用于解决一个 ACME 长期存在、但此前从未被标准化的问题：续签时间的信息，应该如何由 CA 传达给客户端。
在 ARI 出现之前：
- ACME 协议并没有定义任何“续签建议”的表达方式
- 客户端只能基于证书有效期自行计算续签时机
而 RFC 9773 引入 ARI 后，协议层首次允许 CA 明确告诉客户端：这张证书的建议续签窗口（renewal window）
那这也就意味着一个出现了一个非常清晰的变化：以前大家都是靠经验在猜，或者依靠经验设置一些规则，而现在 CA 可以直接告诉我应该在哪个窗口期完成续签，这样就也不需要我猜来猜去了。
简单的来说ARI 并不会改变 ACME 的签发流程，它只会做一件事：那就是把“什么时候该续”这件事，从原来的实现经验，升级为现在协议可表达的信息。
为什么 ARI 对 short-lived 尤其重要？
7 天（其实不足 7 天）证书和 90 天证书在运维层面可以说完全不是一回事，在 90 天证书的时代，你算的不准也没关系，早几天晚几天续费都无所谓，比如在第 60 天续期和第 67 天续期没什么区别，大概率也不会出什么事情。
但当证书缩短到 7 天的时候，情况就变了，我猜你大概率应该不敢算不准了哈哈，这大概会导致两种极端的情况：
- 续得太晚，直接过期，服务当场翻车
- 续得太随意，今天续、明天又续，时间逻辑看起来一团乱（不过至少算是续上了）
于是你作为运维，看到的大概率就会是这种非常拧巴的状态：证书文件本身是对的，而且HTTPS 访问也是正常的。但配置文件里、日志里写着的NextRenewTime、计划时间怎么看都不怎么合理。
所以这时候你会很难判断一件事：“它现在这样，到底是正常的，还是哪里已经埋雷了？”而有了 ARI 之后，逻辑就会变得非常干脆：你不用再关心这是 7 天证书，还是 90 天证书，CA 会明确告诉你：这张证书，什么时候续最合适，你只需要听CA的指挥就好。续签节奏，也不再是客户端或者你的“个人理解”，而是 CA 给出的“官方答案”，出问题又可以甩锅了（bushi，开个玩笑哈哈
那现在的现状是怎样？
现实情况其实非常真实，也非常工程化（暂时还不亲民）。大概可以总结为三点：
ARI 已经是正式的 ACME 扩展规范
- CA 侧（比如 Let’s Encrypt）已经在推进支持
- 客户端侧，还在逐步跟进、逐步落地
所以你现在看到的现象，往往会是这样的：short-lived 证书本身没有任何问题，实际的续签行为，也没问题（不包括续签的时机），但日志和列表中所展示出来的“计划续签时间”仍然沿用旧的计算逻辑，于是就出现了看起来好像哪里不太对，实际续签也没有任何问题（指的是你指定续签周期之后）这并不是你理解错了，而是协议已经往前走了半步，但客户端实现却还在追。
或许在不远的将来，大多数的客户端都会实现对 ARI 协议的支持，比如 acme.sh 其实早在草案阶段就尝试去支持了 ARI ，不过还不知道因为什么原因还没有合并到主线。
但总的来说，这终归是 ACME 生态成熟的标志，靠经验-靠约定-再到靠协议，ARI 也正是这个演进过程中重要的一环。
END
ARI 的出现，并不是为了“修一个 bug”，而是为了让 ACME 进入下一个阶段。
当证书不再是 90 天的固定节奏，
当 short-lived 成为常态，
唯一可靠的续签时间，
也就不再应该由客户端自己去猜了。
如果你现在已经在用 IP short-lived 证书，那你现在看到 ARI，基本就等于提前看到了 ACME 或者说主流 ACME 客户端的下一步演进方向了。
