作者｜瞻新資訊 張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）
先講一個很多人還沒注意到的變化：從 2026 年 3 月 15 日起，一張公開信任的 SSL 憑證，最長只能用 200 天。再過幾年，會更短。
如果你對憑證的印象還停留在「買一年，到期前再說」，那個世界其實已經結束了。
這篇不談加密原理，也不再比一次哪種憑證比較好——那些站上另一篇〈HTTPS 是什麼？加密原理、SEO影響與網站導入指南〉已經寫得很完整。這篇要接的是另外那一半：憑證裝上去以後的事。怎麼確保它一直有效、一張憑證到底保得到哪些網址、為什麼同一個網站有人開得起來有人開不起來，還有最常被整個跳過的一題——這件事到底該算誰的。
先講一件正在發生的事——SSL 憑證的有效期一直在被縮短
先用一個比喻。SSL 憑證比較像汽車的定期驗車，不像一次買斷的零件。它有到期日，到期就得重新驗一次，證明「這個網域現在還是你的、這家公司現在還存在」。
過去這張「驗車證」可以用一年多（最長 398 天）。現在監理規則改了，而且是一路往下調。
制定這個規則的組織叫 CA/Browser Forum，成員是憑證頒發機構與瀏覽器廠商。2025 年 4 月他們通過了一份編號 SC-081v3 的表決案，把最長效期分三階段砍下來：
| 生效日 | 憑證最長效期 | 相當於一年要換幾次 |
|---|---|---|
| 2026-03-15（已生效） | 200 天 | 約 2 次 |
| 2027-03-15 | 100 天 | 約 4 次 |
| 2029-03-15 | 47 天 | 約 8 次 |
這份表決案由 Apple 提出、Sectigo 附議，Apple、Google、Mozilla、Microsoft 四大瀏覽器廠商全部投贊成票，29 票贊成、0 票反對。也就是說，這不是某一家的主張，是整個產業講好的方向，沒有什麼轉圜空間。
順帶一提，同一份表決案還把「網域驗證資料」的重複使用期縮到 10 天。白話講就是：以後幾乎每次換發憑證，都要重新確認一次這個網域真的是你的。
我們來算一筆帳。假設一家公司有一個官網、一個購物站、一個後台系統，三張憑證。在 398 天的年代，一年大概處理三次；到了 47 天的年代，同樣三個站，一年要處理大約二十四次。這個數量已經不是「請助理排個提醒」能吸收的工作量了。
⚠️ 注意
效期縮短是分階段強制的，不是建議事項。過了生效日，憑證機構就不能再簽發超過上限的憑證——不管你願不願意付更多錢買長效期。
一句話收尾：憑證從「一年處理一次的採購」變成「一年要處理好幾次的維運」，這就是整件事的核心變化。後面幾節談的所有問題，成因都在這裡。
憑證過期那一刻，網站實際上會發生什麼
很多人以為憑證過期只是「網址列的鎖頭不見了」。實際情況比那個嚴重得多。
瀏覽器不會讓訪客直接進站，而是先擋一個滿版的警告頁。以 Chrome 為例，畫面會顯示 `NET::ERR_CERT_DATE_INVALID`，並且警告這個網站可能不安全。訪客要點「進階」，再點一次「繼續前往（不安全）」，總共兩層，才會看到你的首頁。
實務上，絕大多數訪客看到那個紅色警告就直接關掉了。對一個正在收單的網站來說，這段時間等同暫停營業。
更麻煩的是，受影響的不只是人。
- 串接你 API 的系統會直接失敗。 程式端的用戶端沒有「我知道風險，繼續前往」這個按鈕，憑證無效就是連線中斷。
- 金流、物流的回呼（webhook）會打不進來。 訂單狀態卡住，而且通常沒有人會立刻發現。
- LINE、Google 這類第三方服務的串接會停掉，因為它們對憑證有效性的要求是硬性的。
💡 小提醒
如果你的網站有跟外部系統串接，憑證過期的損失通常不是首頁進不去，而是背景那些沒有人在看的資料流默默停掉。等到有人發現訂單對不上，往往已經過了好幾個小時。
你可能會想，這種低級失誤應該只有沒人管的小網站才會發生吧？
不是。Microsoft Teams、Spotify、Ericsson 的電信核心系統、Epic Games，都曾經因為單一一張憑證過期，造成長達數小時的公開服務中斷。這幾家公司都有專職的維運團隊，也都有監控系統，照樣出事。
原因其實不難理解。憑證過期不像伺服器當機那樣會觸發告警——主機是活的、程式是好的、資料庫也正常，從系統監控的角度看過去，一切健康。真正壞掉的是「外面的人願不願意相信你」這一層，而這一層，通常根本不在監控清單上。這一點跟DDoS 攻擊那種一看流量圖就知道出事的狀況剛好相反——憑證過期安靜得多，也因此更容易拖久。
一句話收尾：憑證過期不是顯示問題，是服務中斷。而且斷掉的部分，你在瀏覽器上看不到。
一張憑證保得到哪些網址？子網域要不要另外處理
這一節是很多人真正會做錯的地方。
一張最基本的憑證，只保護你指定的那一個網址。`example.com` 的憑證，不會自動保護 `shop.example.com`。如果你後來加了一個子網域做活動頁，那個子網域是裸的——訪客一進去就看到不安全警告。
要涵蓋多個網址，有兩種做法。
萬用字元憑證（wildcard），寫法長得像 `*.example.com`。它涵蓋這個網域底下同一層的所有子網域，數量不限，而且新增子網域不用重新簽發。
多網域憑證（SAN，也叫多網域或 UCC），做法是把要保護的網址一個一個列進憑證裡。它的強項是可以跨完全不同的根網域，例如同時保護 `example.com` 和 `example.tw`。
兩者的差別整理成一張表：
| 比較項目 | 萬用字元憑證 | 多網域（SAN）憑證 |
|---|---|---|
| 涵蓋方式 | `*.example.com` 底下同一層全部子網域 | 逐一列出的指定網址清單 |
| 能不能跨不同根網域 | 不行 | 可以 |
| 新增網址 | 同一層的新子網域自動涵蓋，不用重簽 | 要重新簽發 |
| 數量限制 | 同一層不限 | 有上限，多數機構約 100 個 |
| 支援 EV 等級嗎 | 不支援 | 支援 |
| 主要風險 | 私鑰一旦外洩，全部子網域一起受影響 | 超過 25 個之後管理會變得很吃力 |
有兩個限制特別容易踩到：
第一，萬用字元只保一層。 `*.example.com` 涵蓋 `shop.example.com`，但不涵蓋 `test.shop.example.com`。多一層就要另外處理。這件事在中文資料裡提到的比例很低，但只要網站架構稍微深一點就會遇到。
第二，萬用字元憑證沒有 EV 等級。 如果你的網站因為金流或產業要求必須用 EV，那就不能走萬用字元這條路，只能逐一列或用 SAN。
⚠️ 注意
很多公司會拿同一張萬用字元憑證，同時裝在正式站、測試站和內部備援站上，因為方便。方便沒錯，但那等於把三個環境的安全性綁成同一條命——測試站的主機被入侵、私鑰被拿走，正式站的憑證也要一起作廢重簽。
至於要選 DV、OV 還是 EV 哪一個驗證等級，那是另一個問題，跟涵蓋範圍是兩個獨立的決定。那部分站上〈HTTPS 是什麼？加密原理、SEO影響與網站導入指南〉有完整的比較表，需要的話直接看那篇，這裡不重複。
一句話收尾：涵蓋範圍跟驗證等級是兩件不同的事，先確定要保護哪些網址，再決定要驗到哪個等級。
憑證裝好了，為什麼還是有人打不開
這一節講一個很詭異、但其實很常見的狀況。
情境是這樣：網站上線，你用自己的筆電打開，網址列綠鎖好好的，一切正常。兩天後客戶打電話來說，他用手機看是「不安全」。你再用自己的電腦確認一次——還是正常。你開始懷疑是不是客戶手機有問題。
客戶的手機沒問題，是憑證裝的時候少裝了一塊。
先解釋憑證是怎麼被信任的。憑證不是單獨一張，而是一條鏈。最上面是瀏覽器內建信任的「根憑證」，中間是「中繼憑證」，最下面才是你網站那張。瀏覽器必須能從你的憑證一路往上接到根憑證，才會判定為可信。
比喻一下：這像是介紹信。你拿著一封信說「我是誰」，但收信的人不認識你，他認識的是最上面那位。中間那幾層的介紹人，你得一併附上，他才串得起來。
問題就出在：很多人裝憑證時只裝了自己那一張，漏掉中繼憑證。
那為什麼桌機看起來是好的？兩個原因：
- 桌機瀏覽器會自己去補。 桌機版的 Chrome、Firefox、Edge 有一個叫 AIA fetching 的機制，發現鏈子斷了，會照著憑證裡的線索自己去把缺的那塊下載回來，整個過程沒有任何提示。
- 桌機瀏覽器會快取中繼憑證。 如果你之前逛過別的網站用同一家機構的憑證，你的瀏覽器早就存過那塊了，直接拿來用。
而手機瀏覽器、curl、wget、Python 的 requests、Node.js 的 https 模組，還有大多數監控工具，都不做 AIA fetching。鏈子斷了就是斷了，直接失敗。
所以這個問題有一個很殘忍的特性：最不可能發現它的人，就是負責驗收的那個人——因為他用的是自己那台早就快取好一堆中繼憑證的電腦。
要確認鏈子完不完整，不能用「我開起來是好的」當標準。指令行的做法是：
“` openssl s_client -connect yourdomain.com:443 -servername yourdomain.com “`
看回傳的憑證鏈有沒有完整列出中繼憑證。不習慣用指令的話，網路上有第三方的 SSL 檢測服務，貼上網址就會列出整條鏈，並且明確告訴你缺不缺東西。
💡 小提醒
驗收網站時，至少要用一支「沒有裝過你們公司任何 App、也沒逛過你們網站」的手機開一次。或者更簡單：直接跑一次第三方 SSL 檢測，把報告留存。
一句話收尾：「我這邊看起來正常」在憑證這件事上不是有效的驗證方法，因為桌機瀏覽器會默默幫你把錯誤蓋掉。
自動續約是現在的標準做法，但自動化也會壞
回到效期那件事。既然一年要換好幾次，手動就不可能了，答案是自動續約。
目前最普遍的做法是用 ACME 這套協定，搭配 Certbot 之類的工具，讓主機自己去申請、自己安裝、自己重啟服務。免費憑證機構 Let’s Encrypt 就是走這條路。
但這裡有兩件事要特別注意。
第一，Let’s Encrypt 已經不寄到期通知信了。
2025 年 6 月 4 日起，Let’s Encrypt 關閉了憑證到期的 email 通知服務，而且把 ACME 帳號裡綁定的 email 位址從資料庫刪掉了。
這件事的意義比表面上大。過去很多人的實際流程是「等收到那封信再說」——自動續約有沒有成功不確定，但反正到期前會有信提醒。現在那封信沒有了。發證方等於明白告訴你：不要靠人記得，請把它自動化，並且自己做監控。
第二，Let’s Encrypt 自己的效期也在往下走。
官方已經公布時程：`tlsserver` 這組設定從 2026 年 5 月 13 日起發 45 天憑證；預設的 `classic` 設定在 2027 年 2 月 10 日改成 64 天，2028 年 2 月 16 日再降到 45 天。另外，6 天的短期憑證已經在 2026 年 1 月 15 日正式全面開放。
效期變短，續約排程就不能再照舊。官方的建議是兩條：
- 優先改用 ARI（ACME Renewal Information）。簡單講，就是讓憑證機構直接告訴你的系統「該換了」，而不是你自己猜時間。
- 如果工具還不支援 ARI，續約時間要抓在效期的三分之二處，不能再用固定 60 天間隔。因為當憑證只有 45 天，60 天的排程永遠不會在到期前跑到。
⚠️ 注意
自動續約最常見的失敗，不是程式壞掉，是沒有人知道它壞了。續約腳本跑失敗通常只會寫進一行 log，不會有任何人收到通知。等到有人發現，通常是客戶打電話進來說網站掛了。
所以自動續約只做一半是不夠的，至少要再加一個獨立於主機之外的到期監控——從外面定期連你的網站、檢查憑證剩幾天，快到了就發訊息給人。重點在「獨立於主機之外」：如果監控跟續約跑在同一台機器上，那台機器出事的時候，兩個一起失效。
有一個免費的方法，可以查自己的網域被發過哪些憑證
既然講到監控，這裡補一個很多人不知道、但完全免費的做法。
每一張由公開信任機構簽發的憑證，在簽發後的幾秒內都會被寫進一個叫「憑證透明度」（Certificate Transparency，簡稱 CT）的公開紀錄。這套機制當初設計的目的，就是讓網域擁有者查得到「有誰以我的名義申請過憑證」。
實務上最方便的查詢入口是 `crt.sh`（由憑證機構 Sectigo 營運，免費開放）。在上面用 `%.yourdomain.com` 這種寫法搜尋，會列出你這個網域底下所有被簽發過的憑證，包含子網域。
這件事有兩個用途：
- 盤點用：你可能不記得公司到底有幾個子網域在跑、各自的憑證什麼時候到期。CT 紀錄會誠實地全部列出來，包含那些你已經忘記存在的測試站。
- 查異常用：如果出現你不認識的憑證——例如有人申請了一個跟你網域很像的名字拿去做釣魚頁——在這裡看得到。
⚠️ 注意
這裡有一個很常見的誤解：很多人以為憑證機構會幫忙盯著有沒有人冒用自己的網域申請憑證。不會。憑證機構的義務只到「把自己簽發的憑證提交到公開紀錄」為止，別人家的機構替你的網域簽了什麼，沒有人會主動通知你。這個監控責任完全落在網域擁有者身上。
另外，`crt.sh` 這類查詢站是「你去問它才會回答」，它不會主動推播。要真的當監控用，得自己排一個定期查詢，或者用有推播功能的服務。
一句話收尾：自動續約是必要的，但它不是裝完就沒事。真正要建立的是「自動續約 ＋ 外部監控 ＋ 有人會收到警報」這三件一組。
憑證到底是誰的事？這是台灣中小企業最常卡住的地方
前面講的都是技術。這一節講的是實務上真正會出事的原因，而它跟技術沒什麼關係。
台灣中小企業的網站，常常是這樣的組合：網域是幾年前某個員工用自己的信箱申請的，主機在 A 公司，網站是 B 公司做的，維護合約到期之後就沒有續。
憑證到期的時候，會發生什麼？
主機商覺得憑證是網站的事，網站公司覺得自己早就結案了，而當初申請網域的那個員工已經離職，連通知信都寄到一個沒人在看的信箱。三方都覺得不是自己的事，然後網站就這樣掛了兩天。
這不是假設。這是網站委外之後最典型的斷點，而且它跟公司規模沒有關係——反而是規模小、沒有專職 IT 的公司最容易遇到，因為沒有人的職責範圍明確包含這一項。
要解掉它，其實只需要在專案還沒結束之前，把四個問題寫下來，寫在紙上或信件裡都可以：
- 憑證由誰申請、裝在哪裡？（主機商附的？自己跑 Certbot？還是另外買的？）
- 續約是自動還是手動？如果是自動，跑在哪一台機器上、用哪個帳號？
- 續約失敗的時候，警報會發到誰的信箱或手機？（這一題最常被跳過）
- 網域的管理權限在誰手上？（很多憑證驗證要改 DNS，沒有網域權限就卡住——網站搬家時會遇到同一個問題）
這四題沒有標準答案，重點是要有答案，而且答案要落在一個具體的人或單位身上，不能是「應該是廠商吧」。
💡 小提醒
如果你現在就想確認自己公司的狀況，最快的方法是直接問：「我們網站的 SSL 憑證下一次到期是什麼時候？」。如果沒有人立刻答得出來，那就代表這件事目前沒有人在管。
我們在接手客戶的系統時，很常遇到的情況是：需求本身其實很清楚，但沒有人講清楚交界處是誰的責任。憑證就是很典型的一個——它夾在網域、主機、網站三者中間，每一方都碰得到，但沒有一方預設會負責。把交界處講清楚，通常比把技術做得更漂亮還重要。
一句話收尾：憑證會出事，八成不是技術問題，是沒有人被指定負責。
網站交付前，關於憑證該要求對方交什麼
如果你正要驗收一個網站，或是準備發包，這一節可以直接當檢查清單用。
要求對方提供：
- 一份第三方 SSL 檢測報告，而不是口頭說「已經裝好了」。報告要能看到完整的憑證鏈、有效期限，以及支援的加密協定。這一項就能擋掉前面講的中繼憑證問題。
- 憑證的到期日與續約方式書面寫明。 是自動還是手動、跑在哪裡、多久跑一次。
- 續約失敗的告警收件人。 明確寫出一個信箱或通訊軟體群組，並且確認那個收件人真的收得到。
- 涵蓋範圍清單。 這張憑證保護哪些網址，之後要新增子網域的話要做什麼。
自己要留下的：
- 網域管理平台的帳號權限（至少要有一個公司自己掌握的管理員帳號，不要全部在廠商手上）。
- 主機控制台的存取方式。
⚠️ 注意
「網站交付」跟「網站可以長期正常運作」是兩件事。交付看的是當下打得開，長期運作看的是那些會到期、會過時、會需要有人續的東西有沒有人接手。憑證只是其中最容易被看見的一個，SSL 之外還有網域續費、主機續約、外掛更新，邏輯完全一樣。要一次把這些一起盤點的話，可以照企業網站健康度檢查那一套流程走一遍。
講到這裡，其實整篇的重點可以收成一句話：憑證這件事，難的從來不是裝，是裝完之後的那幾年。效期一路縮短，只是把這個本來就存在的問題提早暴露出來而已。
如果你正在規劃新網站或系統，或是手上的網站交接得不太乾淨，需要有人把這些交界處一項一項釐清楚，瞻新資訊的團隊可以協助評估。
FAQ
SSL 跟 HTTPS 是同一件事嗎？
不是同一件事，但綁在一起。HTTPS 是網頁傳輸用的協定，SSL／TLS 憑證則是讓這個協定跑得起來的那張身分證明。沒有有效的憑證，網站就沒辦法用 HTTPS 提供服務。可以這樣理解：HTTPS 是「加密的通道」，憑證是「證明通道另一端真的是你」的文件，兩者缺一不可。
免費的 SSL 憑證可以用在公司網站嗎？
可以，而且非常普遍。免費憑證（例如 Let’s Encrypt）提供的加密強度跟付費憑證是一樣的，差別在驗證等級與效期，不在安全性。適合純展示型官網、部落格與內部工具站。如果你的網站有金流交易，或是需要讓訪客能查到公司的登記身分，才需要考慮驗證等級較高的付費憑證。
憑證過期的話，網站會直接打不開嗎？
網站主機其實還在運作，但瀏覽器會擋一個滿版的安全警告頁，訪客要連點兩層才進得去，實務上大多數人會直接離開。更需要注意的是程式端的串接：API、金流回呼、第三方服務的連線沒有「繼續前往」這個選項，憑證無效就會直接失敗，而且通常不會有人立刻發現。
為什麼電腦看起來正常，手機卻顯示不安全？
最常見的原因是安裝時漏掉了中繼憑證，導致憑證鏈不完整。桌機瀏覽器有自動補抓的機制、又會快取先前用過的中繼憑證，所以會默默把錯誤蓋掉；手機瀏覽器與大多數程式用戶端沒有這些機制，就直接失敗。確認方法是跑一次第三方 SSL 檢測，看鏈子有沒有缺件，不要用自己的電腦當判斷依據。
子網域需要另外買憑證嗎？
看你買的是哪一種。一般憑證只保護指定的那一個網址，子網域不會自動涵蓋；萬用字元憑證（`*.example.com`）可以涵蓋同一層的所有子網域，新增也不用重簽，但只保一層——`test.shop.example.com` 這種多一層的就不在範圍內。要跨不同的根網域則要用多網域（SAN）憑證。
SSL 憑證是誰負責續約？
沒有預設答案，這正是它容易出事的原因。憑證夾在網域、主機、網站三方中間，每一方都碰得到，但沒有一方預設會負責。實務上建議在專案結束前就白紙黑字寫清楚四件事：誰申請、續約是自動還是手動、跑在哪台機器上、失敗時警報發給誰。如果現在問公司裡沒有人答得出下次到期日，那就代表目前沒有人在管。
怎麼知道公司名下到底有幾張 SSL 憑證？
用憑證透明度（CT）紀錄查。每一張公開信任的憑證在簽發後幾秒內都會被寫進公開紀錄，可以到 `crt.sh` 這類免費查詢站，用 `%.yourdomain.com` 的格式搜尋自己的網域，就會列出所有被簽發過的憑證與子網域。這個方法特別適合拿來盤點那些已經沒人記得、但還在跑的測試站或舊活動頁。要注意的是這類查詢站不會主動推播，要當監控用的話得自己排定期查詢。
參考資料
- CA/Browser Forum —《Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods》（2025年4月11日）https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ （英文，國際標準組織）
- DigiCert —《TLS Certificate Lifetimes Will Officially Reduce to 47 Days》 https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days （英文，美國）
- Let’s Encrypt —《Decreasing Certificate Lifetimes to 45 Days》（2025年12月2日）https://letsencrypt.org/2025/12/02/from-90-to-45 （英文，國際）
- Let’s Encrypt —《6-day and IP Address Certificates are Generally Available》（2026年1月15日）https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability （英文，國際）
- Let’s Encrypt —《Announcing Six Day and IP Address Certificate Options in 2025》（2025年1月16日）https://letsencrypt.org/2025/01/16/6-day-and-ip-certs （英文，國際）
- SSL.com —《Install Intermediate Certificates To Avoid SSL/TLS Not Trusted》 https://www.ssl.com/how-to/install-intermediate-certificates-avoid-ssl-tls-not-trusted/ （英文，美國）
- Sectigo —《CA/B Forum Cuts SSL/TLS Certificate Lifespan to 47 Days》 https://www.sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days （英文，英國／美國）
- Sectigo —《Certificate Expiration Risk: 200 Day Validity Starts March 15》 https://www.sectigo.com/blog/200-day-ssl-certificate-expiration-risk （英文，英國／美國）
- Certificate Transparency 專案官方說明 https://certificate.transparency.dev/ （英文，國際）
- crt.sh — Certificate Transparency 公開查詢服務（由 Sectigo 營運） https://crt.sh/ （英文，國際）
ℹ️ 關於本文
本文引用的憑證效期時程與各憑證機構政策，以查閱當日（2026年9月13日）的官方公告版本為準。憑證規則由 CA/Browser Forum 與各瀏覽器廠商持續調整，實際生效日期與細節請以各機構的最新公告為準。文中對憑證管理方式與交付責任的判斷屬一般性實務經驗說明，實際做法會因網站架構、主機環境與合約範圍而有明顯差異，不構成對任何特定情況的保證或專業建議。
關於作者｜張安邦執行長
台灣大學醫學工程研究所背景，十年以上軟體開發經歷，領軍瞻新資訊有限公司（2010年成立），完成專案200＋、涵蓋40～50＋個產業。專長：網頁設計、APP開發、UI／UX設計、LINE Bot自動化、系統開發、資訊安全。
