後端面試：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 限流，驗證客戶端不會形成同步重試。