走向45天TLS憑證：網站管理員要先補上自動續期缺口

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-13

Let's Encrypt的公開TLS憑證預設效期將進一步縮短。iThome 報道指出，現時90天的安排會在2027年2月10日改為64天，並計劃於2028年降至45天。對使用自訂網域的網站、網店、初創及企業網絡服務而言，影響未必是要更換憑證供應者，而是原有續期流程能否在更短周期內穩定完成。

最重要的限制在於，這是分階段實施的未來安排，並非即時將所有憑證改成45天。已使用自動續期、且ACME client支援ACME Renewal Information（ARI）的管理員，按 iThome 所引述的Let's Encrypt說法，一般毋須作大幅改動。不過，「已有自動化」不等於流程一定適用：若排程、腳本或人工覆核仍暗藏固定日數假設，效期縮短後便可能留下營運空隙。

45天周期改變的是營運節奏

憑證效期縮短的安全理由很直接。iThome 報道指出，安排旨在縮短私鑰外洩或憑證錯誤簽發後的風險暴露時間。從營運角度分析，代價是憑證簽發、網域驗證、安裝及服務 reload 的循環會更頻密；依賴人手在到期前處理一次的做法，容錯空間將明顯收窄。

64天是很實際的過渡測試，而非遙遠的政策訊息。iThome 指出，Let's Encrypt會由10月14日起在staging環境簽發64天憑證，讓管理員測試既有的續期與部署程序。網站團隊應把這視為演練機會：測試成功不只代表取得新憑證，還要確認新檔案確實送達所有需要的server、前端代理或負載平衡節點，並由相關服務讀取。

先找出固定日數與隱藏的人手步驟

iThome 報道特別提醒，如續期機制以距離到期日的固定天數觸發，便需要重新檢視。來源建議把續期時點改為約在憑證生命週期三分之二時處理，並搜尋cron job、wrapper script及runbook內的83、80、60天等硬編碼數值。這類設定在90天制度下看似正常，到了64天甚至45天時，可能令工作根本沒有在有效期內啟動。

實務上，第一步是建立簡單但完整的憑證清單：每個網域由哪個帳戶簽發、使用哪個ACME client、驗證方法是甚麼、憑證安裝到哪個位置，以及由哪項作業負責reload。若使用Certbot或其他ACME client，應確認現行版本及設定是否支援ARI，並查閱實際續期紀錄，而不要只憑當初的安裝狀態判斷它仍在運作。

第二步是把「簽發成功」與「上線成功」分開驗證。ACME工作完成後，流程仍可能在複製檔案、更新權限、同步多台機器或服務reload時失敗。對有多個網站節點、容器或CDN來源server的團隊，這尤其值得檢查。從系統設計角度看，將部署及reload納入同一可重複執行的自動程序，會比把最後一步留給值班人員更能承受短效憑證的節奏。

ARI可減少猜測，但不能取代監察

ARI的作用，是讓Let's Encrypt向支援它的ACME client提供合適的續期時間。這可避免客戶端只按自行估算的到期日排程，因此是45天制度下有價值的機制。可是，ARI只處理「何時嘗試續期」的一部分；DNS、HTTP驗證、帳戶權限、網絡連線或部署程序出問題時，仍需要由營運方發現及處理。

因此，告警設計應圍繞流程失敗，而不只顯示憑證尚餘多少日。可分別監察續期job是否有執行、ACME驗證有否被拒、是否成功取得新憑證、部署版本是否更新，以及服務reload是否完成；同時保留到期日預警作最後防線。這樣做的好處，是故障發生當刻已有訊號，毋須等到證書接近到期才發覺問題。

對以CI/CD管理基建的團隊，亦應檢查密鑰、DNS API權限及環境變數是否會在重建或權限調整後失效。對由託管平台代管憑證的網站，重點則是確認平台是否負責全程續期，以及自訂網域、額外子網域和轉移中的網域是否同樣被涵蓋。這些屬於營運上的合理檢查，而非可由單一憑證工具自動保證的事項。

網域驗證也會更頻密

iThome 亦指出，Let's Encrypt將收緊網域驗證授權的重複使用期限，由現時30天縮至10天，並在2028年再縮短至7小時。這意味著即使憑證簽發流程本身已自動化，依賴舊有驗證結果反覆使用的部署方式，日後也可能不再適用。尤其是需要更新DNS TXT紀錄、跨部門取得網域控制權，或由外判供應商代管DNS的機構，應提早梳理誰有權及時完成驗證。

香港網站管理員目前最合適的做法，是在64天staging憑證可用時完成一次端到端測試，清理固定日數設定，並把續期、部署、服務reload與失敗告警串成可稽核流程。下一步值得觀察的是各ACME client及託管服務對ARI和短效憑證的支援情況；到2028年進入45天周期時，仍倚賴人手續期或分散腳本的系統會最先承受壓力。