Let’s Encrypt 縮短憑證有效期：檢查 ACME 續期設定
Let’s Encrypt 計劃由 2027 年 2 月 10 日起，把新簽發 TLS 憑證的有效期由 90 日縮短至 64 日，並於 2028 年再降至 45 日。這項變動尚未在正式環境生效，但香港的中小企網站、開發者，以及自架 NAS、HomeLab 和反向代理的用戶，若仍靠固定日期的 Cron job 續期，現在便應檢查設定。
關鍵不在於憑證有效期變短本身，而是舊有自動化是否把「90 日」當成不變前提。據 XDA 引述的 Let’s Encrypt 資訊，支援 ACME Renewal Information（ARI）的客戶端可由憑證機構提供合適續期時間；未支援者則應約在憑證有效期的三分之二時續期。
哪些續期設定有風險
最典型是以固定日數安排的設定，例如「每 60 日續期」。在 64 日憑證下，這只剩約 4 日緩衝；DNS 驗證、網絡連線或 ACME 服務其中一環短暫失敗，便可能來不及重試。當有效期降至 45 日後，60 日才續期更會直接錯過到期日。
同樣值得翻查的，還有 Cron、shell script 或排程工具內寫死的 60、80、83 等日數。這不表示所有出現這些數字的工作都會失效，但凡它們用作續期門檻或排程週期，便要確認其計算方式。相反，按「距離到期日固定 30 日」觸發的工具，在 64 日及 45 日有效期下仍有運作空間；不過仍要核實實際版本和客戶端邏輯，不能把個別工具的表現套用到所有 ACME 客戶端。
| 續期邏輯 | 64 日憑證 | 45 日憑證 | 評估 |
|---|---|---|---|
| 固定第 60 日續期 | 僅約 4 日緩衝 | 已過期 | 應修改 |
| 有效期約三分之二續期 | 約第 43 日 | 約第 30 日 | 較合適 |
| 距到期 30 日續期 | 約第 34 日 | 約第 15 日 | 仍可行，但須確認重試機制 |
| ARI 指示續期時間 | 由 CA 提供時窗 | 由 CA 提供時窗 | 優先考慮 |
先盤點憑證與實際提供者
檢查時，應先列出所有對外和內部 HTTPS 入口：網站、反向代理、NAS 管理介面、虛擬化平台及 API。逐一確認目前憑證的到期日、使用的 ACME 客戶端、驗證方式，以及續期是由 Cron、systemd timer、內建排程還是容器處理。
另一個常見盲點是只看瀏覽器的鎖頭。若服務前方有反向代理，瀏覽器看到的可能只是代理的 wildcard 憑證，未必是直接連到 NAS 或管理介面時所提供的憑證。應分別以實際網域和直連地址檢查，並查看客戶端日誌，確認續期請求真的有送出和完成部署。
ARI 優先，沒有便以三分之二為目標
ARI 的價值在於，續期時機不再完全由本地腳本猜測，而可由憑證機構按情況給出建議時窗。XDA 的個人實作顯示，支援 ARI 的 acme.sh 可採納較早的續期時間；Caddy 則以有效期比例處理續期。這些例子可作檢查方向，但不代表所有版本或所有部署方式都有相同行為。
未能使用 ARI 的環境，可把策略改為約三分之二有效期續期：64 日憑證約在第 43 日、45 日憑證約在第 30 日開始。這會保留多次重試空間，尤其適合依賴 DNS-01 驗證的環境；同時要留意報道提到的授權重用期亦會由 30 日縮短至 10 日，失敗後不能假設舊有驗證狀態可長時間沿用。
自動化亦需要告警。建議為憑證剩餘日數、續期失敗及誤用 staging 測試憑證設提示；例如在距離到期 14 日前仍未成功更新便通知管理者。這樣即使排程仍在執行，也不會因靜默失敗而到期後才發現。
Let’s Encrypt 的 staging 環境據報已開始簽發 64 日測試憑證，適合在不影響正式網站前提下驗證現有流程。下一步值得留意的，是各個 NAS、控制台與 ACME 客戶端會否及時加入 ARI 支援，以及舊有固定日數腳本能否在 2027 年前完成調整。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- XDA Developers — Let's Encrypt is cutting certificate lifetimes to 64 days, so I automated my renewals — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
