SL/TLS 憑證的最長有效期限已正式縮短至 200 天（部分憑證機構或瀏覽器規範定為 199 天或 198 天）。這項由全球憑證產業論壇（CA/Browser Forum）推動的重大變革，旨在降低憑證被駭客盜用或密鑰洩漏的風險，並提高加密技術的靈活性以應對量子運算挑戰。這代表原本一年只需手動更新一次的網站管理者，現在一年至少需要更新兩次以上

自 2026 年 3 月 15 日起，新簽發的公開信任 TLS 憑證最長只有 200 天。

不是網站只能使用 200 天，而是憑證要更常更新

大家習慣稱它為「SSL 憑證」，但現在實際使用的安全協定主要是 TLS。它負責驗證網站身分，並加密瀏覽器與網站伺服器之間傳輸的資料。

例如，使用者在購物網站輸入密碼或信用卡資料時，TLS 憑證會協助確認連線對象確實是該網站，而不是冒充的釣魚網站。瀏覽器網址列出現 HTTPS，也代表目前連線受到憑證保護。

這次改變的不是網站壽命，而是單張公開信任 TLS 憑證的最長有效期限。憑證到期前完成更新，網站仍能持續正常提供 HTTPS 服務。

200 天新制從什麼時候開始？

CA/Browser Forum 已通過公開信任 TLS 憑證的分階段縮短方案。2026 年 3 月 15 日至 2027 年 3 月 14 日之間簽發的新憑證，有效期不得超過 200 天。

規範同時建議憑證不要直接設定到完整 200 天，因為一天以 86,400 秒計算，任何超出的零碎時間都可能被算成額外一天。實際購買或簽發時，因此可能看到 199 天或略短的有效期。

憑證有效期縮短時程

200 天並不是最終目標。現行時程會在 2027 年縮短至 100 天，並在 2029 年進一步縮短至 47 天。

已經安裝的 SSL 憑證會立刻失效嗎？

不會。判斷標準是憑證的「簽發日期」，不是規則公告日期。

例如，一張在 2026 年 3 月 10 日簽發、原定使用 398 天的憑證，不會因為 3 月 15 日新制生效就被強制縮短成 200 天。它仍可使用到憑證原本標示的到期時間，除非憑證被撤銷或發生其他安全問題。

從 2026 年 3 月 15 日開始重新申請、更新或重新簽發的公開信任憑證，才會受到 200 天上限影響。網站管理者不必提前刪除現有憑證，但必須確認下一次續期流程是否已經準備好。

哪些 SSL 憑證受到影響？

這項規則主要適用於由公開憑證機構簽發，並用來驗證網際網路伺服器的 TLS 憑證。一般企業官網、購物網站、會員系統、API 服務及公開後台，通常都在影響範圍內。

例如，公司向公開 CA 購買網域憑證，讓 Chrome、Safari 或 Edge 能直接信任網站，這類憑證就必須遵守新的有效期限。

企業內部自行建立的私有 CA、自簽憑證，或只供內部系統使用的憑證，不一定直接受到這項公開 Web PKI 規則限制。電子郵件簽章、程式碼簽章及其他用途的數位憑證，也不能直接套用相同結論。

為什麼要把有效期縮短？

憑證有效期越長，錯誤資料或遭竊金鑰可以被利用的時間就越久。縮短期限能讓網站更頻繁地重新驗證網域控制權，並加快淘汰不安全或已失效的憑證資料。

例如，公司出售網域或更換雲端服務後，舊憑證若仍能長時間使用，可能增加憑證被錯誤使用的風險。有效期縮短後，這類舊授權資料能被沿用的時間也會下降。

但安全提升伴隨新的維運壓力。過去一年處理一次更新的公司，進入 200 天階段後，可能每年要更新約兩次；到了 47 天階段，人工更新將變得非常不可靠。

憑證到期會發生什麼事？

TLS 憑證過期後，瀏覽器通常會顯示「連線不安全」、「您的連線不是私人連線」或憑證失效警告。使用者可能無法正常進入網站，也可能因警告畫面而直接離開。

例如，電商網站在促銷活動當天憑證到期，即使伺服器、資料庫與付款功能都正常，顧客仍可能無法完成結帳。對企業而言，這不是單純的技術警示，而是直接影響營收與品牌可信度的服務中斷。

API 與系統串接也可能因憑證過期而失敗。行動 App、第三方付款服務、Webhook 或企業內部系統若拒絕過期憑證，會出現登入失敗、資料無法交換或排程中斷。

付費三年不代表一張憑證能用三年

部分憑證服務仍可能販售兩年或三年的訂閱方案，但這通常代表服務期間，而不是單張憑證的技術有效期。供應商仍需依規定，在訂閱期間內定期重新簽發短效期憑證。

例如，公司購買三年方案後，可能不需要每 200 天重新付款，但仍必須讓主機安裝新簽發的憑證。只完成付款、沒有完成重新簽發與部署，網站仍可能在舊憑證到期後中斷。

因此，採購人員應分清楚「服務合約期限」與「憑證有效期限」。前者決定你能使用服務多久，後者決定目前安裝的憑證何時失效。

人工更新將成為最大的風險

200 天階段仍能勉強依靠行事曆提醒，但這不是長期可行的做法。規則已確定會繼續縮短至 100 天與 47 天，人工下載、上傳、重新綁定及重啟服務，很容易漏掉其中一台設備。

例如，公司同時有官網、API、NAS、郵件閘道器與負載平衡器，憑證可能散落在五個不同位置。即使主網站已更新，只要 API 閘道器漏裝新憑證，行動 App 仍可能全面無法連線。

真正需要處理的不是「記得續約」，而是建立完整的憑證生命週期管理，包括申請、驗證、簽發、部署、檢查與失敗通知。

網站管理者應該怎麼準備？

優先改用自動化更新

系統支援 ACME 時，應優先使用自動申請與自動部署機制。常見的 Let's Encrypt、Certbot、Caddy、Traefik、雲端負載平衡器及部分主機控制台，都能降低人工更新風險。

例如，Certbot 可以在憑證接近到期前自動續期，再重新載入 Nginx 或 Apache。管理者仍要監控執行結果，但不必每次登入主機手動下載檔案。

建立到期監控與通知

不要只依賴憑證供應商寄出的通知信。應另外建立憑證到期監控，並在剩餘 30 天、14 天及 7 天時通知管理者。

例如，若供應商通知寄到已離職員工的信箱，內部監控仍能透過 Slack、LINE、電子郵件或監控平台發出警報。通知也應包含網域名稱、到期時間、負責人及部署位置。

盤點憑證實際安裝位置

同一張憑證可能安裝在 Web Server、CDN、WAF、負載平衡器、NAS 或反向代理上。只更新其中一個位置，不代表所有連線端點都已完成更新。

企業應建立憑證清冊，至少記錄網域、簽發機構、到期日、部署設備、更新方式與負責人。若憑證仍靠人工更新，也應清楚標示操作文件與回復方案。

測試自動更新是否真的成功

「已開啟自動續期」不等於「新憑證已成功上線」。DNS 驗證失敗、權限不足、防火牆限制或服務未重新載入，都可能讓更新程序看似完成，實際網站仍使用舊憑證。

例如，系統雖然成功下載新憑證，但 Nginx 沒有重新載入設定，外部使用者看到的仍是即將到期的舊憑證。監控必須從外部連線實際檢查正在提供服務的憑證，而不是只確認檔案存在。

企業現在最該做的下一步

先列出所有對外網域與 HTTPS 服務，確認哪些憑證仍靠人工更新。接著挑選一個非核心系統測試 ACME 自動簽發、部署與到期告警，確定流程能在無人操作時完成。

200 天只是第一階段。若現在仍以「一年更新一次」的方式管理憑證，到了 100 天與 47 天階段，問題不會只是工作量增加，而是網站中斷的機率會持續上升。