后端面试：ACME ARI 如何避免证书集中续期风暴？

题干与适用场景

一支平台团队管理十万张证书，旧客户端按固定 cron 或剩余寿命百分比续期，导致请求集中在同一小时。候选人需要解释 RFC 9773 的 RenewalInfo 资源、建议窗口和重试语义，并给出 CA、客户端、缓存、告警和回退设计。高质量回答会区分协议建议、客户端决策和最终证书配置。

面试官考察点

• 是否理解 ARI 是 ACME 的续期信息扩展，而非替代 ACME 订单流程。
• 是否能准确解释 suggestedWindow、Retry-After 与随机选点。
• 是否知道 replaces 如何关联旧证书、同一账户和冲突订单。
• 是否考虑未实现 ARI、时钟偏差、缓存、限流和 CA 故障。
• 是否用续期成功率、窗口分布和剩余寿命证明效果。

回答前需要澄清的问题

1. 证书由哪个 CA 签发，客户端是否能升级到支持 ARI 的版本？
2. 续期窗口需要多快响应紧急吊销或大规模替换？
3. 失败重试、到期保护和人工接管的目标是什么？
4. CA 的 RenewalInfo 接口是否允许匿名 GET、CDN 缓存和按 IP 限流？
5. 旧客户端没有 ARI 时，是否能分批改 cron 或增加随机抖动？

30 秒回答框架

“RFC 9773 让 ACME 服务端通过 RenewalInfo 给客户端建议续期窗口。客户端读取 suggestedWindow，在窗口内均匀随机选择时间，并遵守 Retry-After、指数退避和原有错误重试。订单用 replaces 关联前一张证书，服务端可据此追踪替换、优先处理或拒绝重复替换。我要让 RenewalInfo 可缓存且受限流保护，监控窗口内请求分布和到期余量；不支持 ARI 的客户端继续使用带抖动的回退计划。”

分步骤深入解答

1. 先说明 ARI 解决什么问题

固定续期间隔、按证书到期日倒推和按有效期百分比都会把请求聚成尖峰，CA 无法动态调整。ARI 允许 CA 根据负载、即将发生的吊销或证书生命周期变化，向客户端建议新的时间窗口。它不会替客户端创建订单，也不会跳过 ACME 的账户、授权和验证步骤。

2. 读取 RenewalInfo 资源

支持 ARI 的目录对象声明 renewalInfo URL。客户端使用证书 Authority Key Identifier 的 keyIdentifier 与序列号构造资源路径，执行匿名 GET。响应包含 RFC3339 时间戳窗口和可选的解释链接。

GET /renewal-info/<aki>.<serial> HTTP/1.1
Host: acme.example.com
Accept: application/json

HTTP/1.1 200 OK
Retry-After: 21600
Content-Type: application/json

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end": "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

Retry-After 在 ARI 中表示希望客户端再次检查的间隔，不应被误读为只对当前 HTTP 请求的最小等待时间。

3. 选择随机续期时间

客户端应在窗口内均匀随机选择时间；窗口已过去就尽快续期。无法精确睡眠的 cron 客户端，在下一次唤醒时比较目标时间。每次尝试仍服从账户限额、网络退避和订单失败记录。

4. 处理重试和无效窗口

连接超时、请求超时和 5xx 属于临时错误，可做有上限的指数退避。缺失或非法 Retry-After、无效窗口、DNS 失败和非 5xx 错误属于长期错误，应在本地默认间隔后重查并使用回退续期计划。窗口结束时间不晚于开始时间时，客户端不能把它当作正常窗口。

5. 用 replaces 保留替换关系

客户端在新订单中加入 replaces，指向明确的前一张证书。服务端应检查旧证书与账户、标识符的关系，并拒绝已经被其他有效订单替换的证书。这样可以支持紧急替换追踪、优先级策略和吊销后清理，而不会把同一证书的并发续期都当成独立新证书。

6. 设计服务端和运维保护

RenewalInfo 是可匿名 GET 的非机密资源，应使用正确的缓存键、CDN 或边缘缓存和 IP 限流，避免接口本身成为拒绝服务放大点。服务端根据客户端数量设置合理的 Retry-After，同时观察窗口内 QPS、缓存命中率、5xx、续期成功率、到期余量和未实现 ARI 的客户端比例。

高质量示范回答

“我会先把问题拆成 CA 建议、客户端调度和订单关联。RFC 9773 让目录对象暴露 renewalInfo，客户端按证书 AKI 与序列号查询，读取 suggestedWindow 后均匀随机选点；Retry-After 控制再次拉取频率，失败仍执行有上限的指数退避。订单带 replaces，服务端校验账户和标识符并防止重复替换。RenewalInfo 可匿名读取，所以我会用 CDN 缓存、规范化缓存键和限流保护。监控窗口内分布、到期余量和回退客户端；不支持 ARI 时，使用带随机抖动的旧计划，并在 CA 紧急事件中保留人工加速通道。”

常见错误

• 把 ARI 当成自动续期服务 → 它只提供建议窗口 → 客户端仍负责创建和完成订单。
• 忽略 Retry-After 语义 → 频繁轮询会制造新尖峰 → 按服务器建议间隔并设合理上下限。
• 窗口内让所有客户端同一秒执行 → 仍会形成微型风暴 → 均匀随机选点并保留退避。
• 把 replaces 当作任意证书 ID → 可能越权关联其他账户 → 校验账户、标识符和已替换状态。
• 只监控签发成功率 → 到期余量和 ARI 覆盖率可能恶化 → 同时看窗口分布、回退比例和剩余寿命。

追问及应对

为什么 RenewalInfo 可以匿名 GET？

资源只表达建议时间窗口，不被视为机密；匿名 GET 也便于缓存，减轻客户端和 CA 负载。服务端仍须规范缓存键、限流和防止恶意构造请求，不能因为无需认证就忽略拒绝服务风险。

ARI 窗口已经在过去怎么办？

客户端应尽快尝试续期，同时遵守错误退避和账户限额。服务端把窗口置于过去通常表示紧急替换，客户端不能再等待下一次正常周期。

没有实现 ARI 的客户端如何平滑迁移？

先给固定计划增加稳定的随机抖动和分片，再按客户端版本逐步启用 ARI。监控回退比例、续期失败和到期余量；在覆盖率不足时不能假设 CA 已经把所有请求均匀化。

如何测试十万张证书的效果？

用带相同到期日的合成证书压测 RenewalInfo、缓存和订单路径，比较启用前后的每分钟请求分布、峰值、P95 续期延迟、失败重试量和到期余量。注入 5xx、无效窗口、时钟偏差和 CA 限流，验证客户端不会形成同步重试。