某個週一早上，nginx 突然開始 502
某家電商平台的維運團隊在週一早上收到一連串告警：對外 API 開始回傳 502，追下去發現是憑證過期。查證後更頭痛 — 這張憑證是三個月前才手動換過的，效期只剩 90 天而不是團隊習慣的一年。沒有人記得規則已經改了。
這不是個案。TLS/SSL 憑證的最大有效期限，正在以近乎失控的速度被壓縮：現行 398 天、2026 年 3 月降到 200 天、2027 年 100 天、2029 年只剩 47 天。與此同時，CA/Browser Forum 與 NIST 也在同步收緊演算法強度要求 — 弱雜湊、弱金鑰長度、過時協定版本一個接一個被列入淘汰清單。
過去「一年續一次、記在行事曆上」的人工換版模式，在效期進入週級數之後注定會出包。這篇文章要做三件事：拆解這波效期與演算法要求演進背後的規則變化、分析對維運與合規團隊的實際衝擊，並盤點目前市面上可以承接這個壓力的掃描工具、自動化憑證更新工具，以及 F5、nginx、JBoss 這類企業常見應用的自動化換版做法。
新聞分析：兩條同步收緊的規則線
效期縮短：CA/Browser Forum 的投票歷程
TLS/SSL 憑證效期縮短的完整時程表（398→200→100→47 天），Code Signing 憑證縮短至 460 天 — PKI 產業趨勢那篇文章已經整理過，這裡不重複畫時程表，只補上那篇文章沒談到的部分：這條時程不是憑空出現的，而是 CA/Browser Forum 一連串投票（Ballot）的結果，背後有明確的推手。
- Apple、Google（Chrome Root Program）長期主張更短的憑證效期能降低撤銷機制（CRL/OCSP）的失效風險 — 憑證效期越長，一旦私鑰外洩或憑證需要撤銷，攻擊視窗就越長，而撤銷檢查機制本身又不可靠（用戶端未必即時查驗撤銷狀態）。
- 這場拉鋸在 Ballot SC-063（2024 年提案 47 天最終方案）之後拍板定案，最終版本比業界原本預期的更激進，直接把 2029 年目標訂在 47 天 — 略多於 40 天，這個天數留給自動化流程一點緩衝，但幾乎不留給人工作業任何空間。
- 值得注意的是，這條規則只適用於公開信任（publicly-trusted）憑證，企業內部 PKI 若走私有 CA，理論上不受強制，但實務上大多數組織仍會選擇跟進，原因在下一節會說明。
演算法強度要求：不只是效期縮短
效期縮短只是第一條線，第二條線是演算法強度要求本身也在持續收緊，而且這條線的時程比效期縮短更早、也更零散，容易被忽略：
| 演算法/協定 | 淘汰/收緊時間點 | 依據 |
|---|---|---|
| SHA-1（憑證簽章） | 2016-2017 年主流瀏覽器停止信任 | CA/Browser Forum Baseline Requirements |
| RSA < 2048 bits | 已列為 Broken/Weak，禁止新發 | NIST SP 800-131A、CA/B Forum BR |
| TLS 1.0 / 1.1 | 2020 年主流瀏覽器與 PCI DSS 全面停用 | RFC 8996、PCI DSS 4.0 |
| DH-1024、3DES、RC4 | 已列為 Broken | NIST SP 800-131A Rev.2 |
| ML-KEM（FIPS 203）/ ML-DSA（FIPS 204） | 2024 年 NIST 正式標準發布，2027 年後逐步要求混合部署 | NIST PQC 標準、CNSA 2.0 |
這張表跟 cbom_scanner 文章裡「Strength tag」的分類邏輯完全對應 — broken / weak / warning 三個等級，本質上就是這條演算法淘汰時程在某個時間點的快照。效期縮短逼你更頻繁地換憑證，演算法要求收緊則決定你換上去的憑證用什麼規格 — 兩條線疊加在一起，才是完整的壓力來源。
後量子演算法的部分更值得留意：NIST 已於 2024 年正式發布 ML-KEM、ML-DSA、SLH-DSA 三套標準，CA/Browser Forum 與各國主管機關正在制定混合憑證（Hybrid Certificate）的過渡規範。這部分的簽發端實作，NG-CA — Pure Rust + Luna HSM 後量子 CA 那篇文章有完整拆解，這裡只強調一點：效期越短的憑證，越有機會提早導入新演算法 — 因為換版週期本身就是演算法升級的天然視窗。
影響分析：人工流程撐不住週級效期
對維運團隊的衝擊
把三條資訊放在一起看，衝擊就很清楚：
| 傳統人工換版流程 | 2029 年後的實際要求 | |
|---|---|---|
| 換版頻率 | 每年 1 次，行事曆提醒 | 每 47 天 1 次，全年約 7-8 次 |
| 換版觸發方式 | 人工檢查到期日、開票申請 | 必須自動偵測、自動觸發 |
| 演算法規格確認 | 換版當下順手檢查 | 每次換版都要重新驗證是否符合當下最新要求 |
| 跨平台部署 | 逐台手動上傳、reload | 需要跨 F5/nginx/JBoss 等平台的一致化自動部署 |
| 疏漏後果 | 偶爾忘記，補救時間充裕 | 忘記即中斷服務，補救視窗以天計 |
換算成人力成本：一組維運團隊若手上有 50 張對外憑證，效期一年時大約平均每週要處理 1 張；效期 47 天時，同樣 50 張憑證要在 47 天內全部換完一輪，等於每天都有換版工作要做。這已經超出任何團隊靠人工排程能撐住的規模，自動化不再是「效率優化」，而是「不做就會出事」的營運底線。
對合規與稽核的衝擊
效期與演算法要求的收緊，也直接推高了持續盤點的必要性。cbom_scanner 那篇文章的結論已經點出這一點：一次性盤點會迅速過時，CBOM 必須被當成持續訊號。放進這篇文章的脈絡，這句話有更具體的意涵 — 稽核與合規團隊如果只在年度稽核時盤點一次憑證清單，等交出報告時，清單上一半以上的憑證可能已經換過版、演算法規格也可能已經不符合當下要求。掃描頻率必須追上換版頻率，換版頻率又追著效期政策跑 — 這是一條完整的因果鏈，缺一環都會斷。
輔助掃描工具：從盤點到觸發
自動化換版的第一步，仍然是「知道哪些憑證需要換」。這正是掃描工具的角色 — 延續 cbom_scanner 文章的邏輯，週期性掃描輸出的 CBOM（Cryptography Bill of Materials）JSON，可以直接餵給下游的自動化流程：
# 從最新一次掃描結果，抓出 30 天內到期或已列為 weak/broken 的憑證清單
jq '.components[]
| select(.cryptoProperties.assetType == "certificate")
| select(
((.certificateProperties.notValidAfter | fromdateiso8601) - now) < (30*86400)
or (.tags // [] | any(. == "weak" or . == "broken"))
)
| {cn: .certificateProperties.subjectName, hosts: [.occurrences[].location]}' cbom-latest.json這份輸出就是自動化換版流程的觸發清單（trigger list）：不再是人工翻 Excel 找到期日，而是每次排程掃描結束後自動產生一份「需要處理」的目標清單，直接餵給續簽/部署流程。掃描與換版之間的介面，就是這樣一份結構化、可機讀的清單。
自動化憑證更新工具地圖
有了觸發清單之後，下一步是自動簽發/續簽。這個環節目前已經有相對成熟的生態：
| 工具/協定 | 定位 | 適用場景 |
|---|---|---|
| ACME 協定（RFC 8555） | 業界事實標準，Let’s Encrypt 推廣普及 | 任何支援 ACME 的 CA 皆可對接，是自動化的協定基礎 |
| Certbot / acme.sh | ACME 客戶端 | 單機/小規模環境，搭配 cron 或 systemd timer 定期續簽 |
| cert-manager | Kubernetes 原生憑證生命週期管理 | 容器化環境，透過 CRD 宣告憑證需求，自動對接 ACME CA 或內部 CA |
| Venafi、Keyfactor | 企業級憑證生命週期管理（CLM）平台 | 大型組織需要跨雲、跨平台、跨團隊的集中治理與稽核軌跡 |
| HashiCorp Vault PKI | 短期憑證動態簽發引擎 | 需要極短效期（甚至小時級）的內部服務間通訊 |
這些工具解決的是「憑證本身怎麼自動續簽」的問題。但實務上真正卡關的，往往是下一步 — 續簽完的憑證，要怎麼自動送到 F5、nginx、JBoss 這些正在跑流量的應用上，而不中斷服務。
跨平台自動化換版支援：F5、nginx、JBoss
這三種平台的憑證更新機制天差地遠，這也是企業自動化換版專案中最容易卡住的環節：
| 平台 | 換版機制 | 主要痛點 |
|---|---|---|
| F5 BIG-IP | 透過 iControl REST API 上傳憑證/私鑰、更新 SSL Profile 綁定 | 常見於 HA（Active-Standby）配對部署，兩台必須同步更新，且需要處理憑證 bundle 與 chain 的正確順序 |
| nginx | 覆蓋憑證檔案後執行 nginx -s reload，或搭配 webhook 觸發 | reload 本身不中斷連線，但檔案覆蓋時機與 reload 觸發需要嚴謹的順序控制，避免 race condition |
| JBoss / WildFly | 更新 keystore 後透過 Management CLI（jboss-cli.sh）熱更新 SSL/TLS 設定，或觸發 reload | Java keystore 格式（JKS/PKCS#12）轉換、undertow subsystem 設定較複雜，部分版本仍需重啟才能生效 |
常見的整合模式有三種：
- cert-manager + webhook adapter：在 Kubernetes 環境內用 cert-manager 管理憑證生命週期，續簽完成後透過 webhook 通知外部平台（F5、nginx）拉取新憑證並觸發部署，適合容器化程度高的組織。
- ACME 客戶端 + 平台專屬 hook script：Certbot/acme.sh 支援續簽後自動執行
deploy-hook，可以掛上呼叫 F5 iControl REST API、觸發 nginx reload、或執行 JBoss CLI 指令的腳本，適合中小規模、平台種類固定的環境。 - 企業 PKI 平台原生外掛：Venafi、Keyfactor 等 CLM 平台通常內建 F5、nginx、Java Keystore 的原生整合模組，換版流程、審核、稽核軌跡一站式處理，適合大型組織需要集中治理多個平台的場景。
不管走哪一種模式，核心原則是一致的：換版動作必須是冪等（idempotent）且可重跑的自動化腳本/流程，而不是一次性手動操作。效期進入週級數之後，任何依賴人記得執行的步驟，遲早會被忘記。
下一步：把三塊拼起來
這篇文章談的其實是同一條治理鏈上的最後一塊拼圖：
- 盤點（cbom_scanner）— 先知道現況有哪些憑證、哪些演算法
- 掌握趨勢（本文）— 理解效期與演算法要求怎麼收緊、影響有多大
- 自動化換版（本文）— 讓觸發清單自動變成跨平台的部署動作
三塊拼起來，才是一個能撐過 47 天效期的完整循環，而不是三個各自為政的專案。
結語
47 天不是一個嚇人的數字，而是一個訊號：PKI 產業已經正式宣告，人工管理憑證的時代結束了。效期縮短與演算法強度要求收緊是同一股力量的兩個面向 — 都是在逼所有人把憑證管理從「行事曆提醒」升級成「自動化系統」。
對於還在用 Excel 追蹤憑證到期日的團隊，現在正是重新設計流程的時機：先把掃描做成週期性訊號，再把續簽與跨平台部署串成自動化管線。等到 2029 年 47 天生效時，這應該已經是一套跑順的日常流程，而不是一場臨時抱佛腳的專案。
延伸閱讀：
- PQC 遷移的第一步：用 cbom_scanner 替內網密碼學資產建檔 — 自動化換版之前，先把家底盤清楚
- 2026 年 Code Signing 憑證重大變革：有效期限縮短至 460 天 — 完整的 TLS/SSL 效期縮短時程表
- NG-CA — Pure Rust + Luna HSM 後量子 CA — 簽發端如何實作混合 PQC 憑證