一分鐘速讀
發生什麼事：外部研究者通報，TWCA 的 CA 憑證序號只有 24 位元亂數。網站憑證也只有 63 位元，都低於國際規範的 64 位元。
為什麼要換：序號亂數能防止攻擊者預先算出 CA 要簽的內容。國際規範要求不合規的中繼憑證 7 天內撤銷，TWCA 在 11 月 6 日凌晨撤銷舊憑證。
跟我有關嗎：用電腦瀏覽器登入網銀不必動作，手機 App 跳出更新提示就更新。這次換的是銀行網站的伺服器憑證，不是網銀轉帳用的憑證。
真正的風險：本土 CA 在 Chrome 裡只剩 TWCA 一家。這次換發的新憑證，在 Chrome 裡只靠一張序號同樣不合規的根憑證。
2026 年 10 月 30 日凌晨 3 時 31 分，兩位外部研究者開了一張通報。地點是 Mozilla 的公開追蹤系統 Bugzilla，編號第 2087236 號。通報對象是臺灣網路認證公司（TWCA），問題出在憑證的序號。
接下來一週，影響一路擴大。數發部 11 月 2 日表示，事件涉及 962 個政府機關、9,772 張網站憑證。金管會 11 月 5 日說明，銀行、證券、保險業向 TWCA 申請的憑證共 4,190 筆。截至當天下午 2 時 30 分，約九成五的金融機構已完成更換。
TWCA 11 月 12 日的完整報告更新了盤點結果：受影響的 CA 憑證共 16 張，其中 12 張在 11 月 6 日凌晨 1 時完成撤銷，2 張先前已撤銷，另有 2 張自簽根憑證須由各根憑證計畫決定如何處理。受影響的用戶憑證共 52,954 張，其中 51,245 張在期限內撤銷、619 張先前已撤銷、1,090 張在撤銷前到期。
一串數字不夠亂，為什麼要動員這麼大？下面先從網站憑證怎麼運作講起，再看 TWCA 的序號出了什麼問題，最後拉到 App 更新與本土 CA 集中的風險。
SSL 憑證是什麼：網站的數位身分證與信任鏈
每次登入網路銀行，網址列都會出現一個小鎖頭。很多人知道它代表「連線有加密」，但鎖頭背後還有一整套發證、驗證的制度。要看懂這次事件，得先把這套制度的角色分清楚。
（一）鎖頭背後，是一張數位身分證
出現鎖頭，代表網站向瀏覽器出示了一張「數位身分證」，正式名稱是 SSL/TLS 憑證。SSL 是舊稱，現在實際使用的協定是 TLS，下文統稱為「網站憑證」。
這張證件要確認的事情很單純：你連上的網站，真的是這家銀行。憑證裡記載著網域名稱、持有者與公鑰，還有發證單位的數位簽章，瀏覽器確認簽章無誤，才會建立加密連線。
（二）三層發證：機關、窗口與身分證
身分證有沒有公信力，要看是誰發的。網站憑證也一樣，發證的單位叫憑證機構（Certificate Authority，CA），而且分成好幾層。
最上層的根憑證像發證機關，是整套信任的起點；中間的中繼憑證像發證窗口，實際替網站簽發憑證；最下層的網站憑證就是發給網站的身分證，每張證上還有一組序號，相當於證號。
至於哪些發證機關可信，各家有各家的名單。Mozilla、Google Chrome、Apple、Microsoft 各有一套根憑證計畫（Root Program）。它們各自維護一份「認得哪些發證機關」的清單，內建在瀏覽器與作業系統裡。
驗證時，瀏覽器拿到網站憑證，先看是哪個窗口簽的，再看窗口由誰授權，一路往上核對。只要最上層的根憑證在清單裡、而且沒有被加上限制，整條鏈就算可信，這條鏈就叫做信任鏈。
（三）誰訂規則、誰執法
發證規則由 CA/Browser Forum 制定，CA 業者與瀏覽器業者都是成員。核心文件叫 Baseline Requirements（BR，基準要求）。
執法的則是各家根憑證計畫。CA 違規時，通報、追蹤與改善報告都在 Mozilla 的 Bugzilla 上公開進行，最重的處分是把這家 CA 從信任清單拿掉。TWCA 11 月 2 日的新聞稿寫成「CAB Forum 針對 TWCA 網站憑證序號的亂數規格提出修正要求」，部分媒體也照登；實際上，這次是外部研究者在 Bugzilla 通報，CA/Browser Forum 只負責制定規則。
（四）TWCA 是誰
TWCA 在 1999 年以「財聯網路認證公司」成立，隔年更名，股東是臺灣證券交易所、臺灣集中保管結算所、財金資訊與網際威信。官網自稱在「金融暨證券憑證應用領域」市占八成以上。
這裡要先分清楚一件事。這次換的是銀行網站的伺服器憑證，也就是網站的身分證；民眾網銀轉帳用的「金融 XML 憑證」是另一套用戶端憑證。
128 位元只有 24 位元在變：序號為什麼一定要亂？
現實中的身分證字號有規則可循，網站憑證的證號卻必須讓人猜不到。這條規定從哪裡來、TWCA 的序號又差在哪裡？
（一）國際規範：至少 64 位元的密碼學亂數
CA/Browser Forum 在 2016 年 7 月通過第 164 號提案（Ballot 164）。從 2016 年 9 月 30 日起，憑證序號至少要含 64 位元的密碼學安全亂數（CSPRNG）。
現行 BR 是 2.3.1 版，2026 年 10 月 4 日生效，序號規定寫在第 7.1.2 節各類憑證的範本裡。序號必須大於 0、小於 2 的 159 次方、不可連號，並含至少 64 位元的密碼學亂數。
（二）2008 年的教訓：猜中序號，就能偽造發證機關
這條規定，源自 2008 年一場很有名的攻擊示範。
2008 年 12 月，Alexander Sotirov、Marc Stevens 等七位研究者發表了一項研究。場合是第 25 屆 Chaos Communication Congress。講題是〈MD5 considered harmful today〉。他們做出一張假的 CA 憑證，當時的主流瀏覽器都會信任它。
關鍵在 RapidSSL 的兩個習慣：序號依序遞增，下單後約 6 秒就自動簽發。研究團隊做出一組碰撞資料要花約三天，所以必須提前三天預估序號；到了預定時間前，再大量購買憑證把序號推到目標值，抓準時間送件。
白話說，數位簽章簽的是憑證的雜湊值，而當年 RapidSSL 用的是已有弱點的 MD5。研究團隊預先算好兩份雜湊值相同的憑證內容，一份是 CA 依申請會簽出的正常網站憑證，另一份是自製的中繼 CA 憑證。CA 簽了前者，同一個簽章搬到後者上仍然有效。
這招的前提，是事先知道 CA 會簽下的完整內容。序號改成亂數之後，攻擊者無法事先算好，這條路就斷了。
（三）TWCA 的序號長什麼樣
研究者在通報中拆解了 TWCA 的 CA 憑證序號。序號長 16 個位元組，也就是 128 位元，依序由固定值、簽發日期、一長串補零、流水號和亂數五段組成。
以通報中的序號 400134b04f0000000000000004aa7b0a 為例。開頭的 40 是固定值，接著的 0134b04f 換成十進位是 20230223，正好是這張中繼憑證的生效日。再往後是 6 個位元組的 0 和流水號 0004，研究者指出，看起來真正在變的只有最後的 aa7b0a，共 24 位元。
24 位元的組合約 1,678 萬種，64 位元約 1,845 京種，兩者相差一兆倍以上。
數發部網站送出的憑證鏈裡，也附著一張 2014 年簽發的 TWCA 交互憑證。它的序號是 40013353E40000000000000CCA5D1B69。中間的 013353E4 換成十進位是 20141028，跟這張憑證的簽發日一致。這張早於 2016 年規範，不算違規，但結構一模一樣。
（四）網站憑證少 1 位元，根憑證也不合規
問題不只出在 CA 憑證。11 月 2 日，另一位研究者開了第 2087918 號通報。他指出 TWCA 網站憑證序號的後段，本該是 64 位元亂數，最高位元卻固定為 0，只剩 63 位元。TWCA 在 11 月 3 日證實。
根憑證也在範圍內。研究者盤點出 24 張同樣結構的 CA 憑證，其中兩張是 2022 年簽發的自簽根憑證。這兩張分別是 TWCA CYBER Root CA 與 TWCA Global Root CA G2，同樣違反 BR 對根憑證序號的規定。
根憑證跟其他憑證有個根本差異：它上面沒有人能撤銷它。中繼憑證與網站憑證不合規，由上一層撤銷就好；根憑證不合規，處置權在各家根憑證計畫，可以整張移除，也可以只停止信任某個日期之後簽發的憑證。CA 能做的，是改用新的根憑證、重新申請收錄。
這件事跟一般使用者的關係，比想像中更直接。換發後的新憑證鏈，可以往上接到兩張根。一張是 2022 年的 TWCA CYBER Root CA，另一張是透過交互憑證接到的 2012 年 TWCA Global Root CA。終點是哪一張，要看你用的軟體。
Chrome 已經替後者加上限制。依 Chrome 根憑證清單的設定，這項限制從 Chrome 153 版生效。2026 年 9 月 14 日（UTC）之後簽發的網站憑證，不能再經由 TWCA Global Root CA 取得信任。換句話說，這次換發的新憑證，在 Chrome 裡只能靠 TWCA CYBER Root CA 驗證。這正是那張序號同樣不合規的根憑證。iPhone 則剛好相反，iOS 26 的信任清單還沒收錄 CYBER Root CA，仍要靠 Global Root CA。
這 24 張 CA 憑證從 2011 年到 2024 年都是同一種結構，顯示 CA 端的序號產生方式，在 2016 年規範上路後一直沒改。據 iThome 報導，TWCA 副總周芳冠說明，2016 年只調整了網站憑證的簽發程式，CA 憑證的產製程式沒有同步更新。他同時表示，網站憑證的序號產製符合規範。但 TWCA 11 月 3 日中午已在 Bugzilla 證實部分網站憑證只有 63 位元亂數，兩種說法並不一致。
（五）沒被駭，為什麼還要換
對風險的判斷，三方說法一致。數發部表示此事「目前並未造成具體資安危害」；通報的研究者寫明，沒有證據顯示有金鑰外洩、憑證遭誤用或遭利用；TWCA 也說，這次調整並非網站遭入侵或私鑰外洩引起。
從技術面看，風險確實偏低。現在的憑證改用 SHA-256 簽章，完整的 SHA-256 目前沒有實用的碰撞攻擊。研究者在通報中也提到，序號短，本身不足以偽造 SHA-256 簽章。加上 CA 憑證由 TWCA 自己產製，外人無從送件申請，攻擊者很難照 2008 年的方式操作。
但 BR 的規定不看風險高低。依 BR 第 4.9.1.1 節，不合規的網站憑證最遲 5 天內要撤銷；依第 4.9.1.2 節，中繼 CA 憑證是 7 天。Mozilla 根憑證政策 3.1 版第 6.1.3 節更寫明，不會對 BR 的撤銷規定給予任何例外。
國際上也有前例。2019 年，多家 CA 使用的憑證系統 EJBCA，在預設設定下只產生最高位元為 0 的序號，64 位元亂數實際只剩 63 位元。Google Trust Services 自 2016 年 9 月起簽發的 100,836 張憑證受影響。其中截至 2019 年 2 月 28 日仍有效、必須撤銷的有 7,171 張；Apple 的事故報告則列出約 87.7 萬張受影響的網站憑證。差 1 位元，一樣要撤銷換發。
TWCA 憑證換發時間軸：從通報到撤銷的七天
TWCA 的換證期限，來自 BR 對中繼 CA 憑證的 7 天撤銷規定。從通報時間起算，期限是 11 月 6 日凌晨 3 時 31 分；TWCA 對外公告，原中繼憑證「需依規定於2026/11/06 00:00前廢止」。數發部的要求則是另一件事：「兩日內產製符合規定的新憑證」。整週的進度如下表。
時間軸裡有兩個細節要留意。第一，依新中繼憑證上的生效時間，它在通報後不到 19 小時就已簽發生效，TWCA 的反應並不慢。第二，舊憑證也不是零時一到就同時失效。CA 憑證在凌晨 1 時登記撤銷，用戶憑證的撤銷持續到 1 時 36 分，撤銷清單（CRL）則到 5 時才對外發布。
網頁不用動，銀行 App 卻要更新：差在有沒有「綁定」
同樣是登入網銀，用電腦瀏覽器什麼都不用做，用手機 App 卻被要求更新。這個差別，要從瀏覽器和 App 驗證憑證的方式說起。
（一）瀏覽器：每次連線都重新核對
金管會資訊服務處副處長王明德 11 月 5 日在例行記者會上表示，用網頁連線基本上不受影響。憑證由銀行端更新，民眾不需要自行操作。
原因就在信任鏈的運作方式。這次換掉的是銀行伺服器上的憑證，瀏覽器本身沒有更新任何東西。新憑證鏈在 Chrome 裡由 TWCA CYBER Root CA 驗證；iPhone 與 Android 系統則透過交互憑證，接到 TWCA Global Root CA。iOS 8 以後的 iPhone、Android 4.4.4 以後的手機，系統信任清單裡都有這張根。
瀏覽器每次連線都重新往上核對。碰到新的身分證和新的發證窗口，只要發證機關還是認得的那一家，就照常放行。瀏覽器也不會記住「上次看到的是哪一張證」。Chrome 曾經支援網站層級的公鑰綁定（HPKP），2019 年初的 Chrome 72 已經移除。
（二）App：有些把證件影本存在自己身上
App 的情況就不同了。金管會表示 App 要更新到新版，多數銀行的公告寫的是「配合 TWCA 憑證更換」。
說得最具體的是中華郵政，公告寫的是「升級行動郵局APP內建之安全憑證」，舊版將無法使用。土地銀行的企業網銀 App 強制更新到 4.3.0 版，台鐵 e 訂通也要求更新到 2.2.5 版。
這類 App 要跟著更新，業界常見的原因之一是憑證綁定（certificate pinning）。OWASP 的行動應用安全測試指南（MASTG）對它的定義，是把伺服器和特定的憑證或公鑰綁在一起。連線時只認這個身分，其他受信任 CA 簽發的憑證也不收。
試想一下，瀏覽器像查驗證件的櫃台，只要發證機關可信就放行；做了綁定的 App 則像一位保全，手上留著一張證件影本，來人的證件和影本對不上，就擋在門外。網站一換證，影本就過期了，只能發新版 App 換一張新影本。
Android 官方文件寫到：做憑證綁定時，一定要加入備援金鑰。否則一旦被迫換新金鑰，或在綁定 CA、中繼憑證的情況下更換 CA，就必須推出 App 更新才能恢復連線。Android 另一份安全文件也明講，不建議 Android App 做憑證綁定。Apple 的開發者文章同樣提醒，伺服器部署的新憑證若改變了公鑰，有綁定的 App 就會拒絕連線。
TWCA 自己其實也提醒過。今年 4 月，TWCA 預告 5 月 4 日起更換憑證鏈時，公告就寫著：「有綁定憑證鏈於 APP 或主機者，可即早佈署新憑證鏈」。
（三）綁在哪一層，決定會不會斷
App 綁的對象不同，這次受到的影響也不同。TWCA 這次做了兩件事：網站憑證沿用客戶原本的金鑰重新簽發，中繼憑證則整個換新。
新的中繼憑證由新增的 TWCA CYBER Root CA G3 簽發，它的金鑰識別碼（SKI）跟 2024 年的舊版不同。SKI 通常由公鑰算出，兩者不同，表示中繼憑證的金鑰也換了。對照下來，各種綁定方式的結果如下：
從這張表可以推出一件事：沒做任何綁定的 App，只要銀行伺服器裝好完整的新憑證鏈，應該跟瀏覽器一樣正常。銀行一律要求更新，可能是保守做法。
綁定本身是一種取捨。它能擋下中間人攻擊，例如手機被裝了惡意根憑證的情況；代價是每次換證，App 都得跟著強制更新。
一家 CA 出錯，全台一起換：本土 CA 集中的代價
這次牽動範圍這麼廣，跟台灣本土 CA 的處境有關。下面從選擇變少、合規紀錄與換證頻率三個角度來看。
（一）從兩家變一家
2025 年 5 月 30 日，Google 宣布從 Chrome 139 起調整信任清單。對象是串接到中華電信 ePKI 或 HiPKI 根憑證的網站憑證。只要憑證透明度紀錄晚於台灣時間 2025 年 8 月 1 日上午 8 時，Chrome 都不再預設信任。Google 的理由，是觀察到一連串合規缺失，改善承諾也沒有兌現。
數發部提前做了準備。2025 年 3 月起，數發部啟動政府網站「雙憑證機制」，採用「臺灣本土憑證機構」所簽發的憑證；數發部今年 11 月 2 日的新聞稿也寫明，TWCA 的網站憑證「經由數發部採購提供各政府機關申請使用」。
結果是，在 Chrome 裡，2025 年 8 月之後新簽發、仍受預設信任的台灣本土 CA，只剩 TWCA 一家。而且 TWCA 的新憑證在 Chrome 裡，實際上只靠 CYBER Root CA 這一張根。Firefox 的情況稍有不同。Mozilla 沒有因合規問題停止信任中華電信，HiPKI 根憑證目前仍在 Firefox 的清單裡。
台灣網站當然還是可以向 DigiCert 等國際 CA 申請憑證。這裡說的集中，指的是政府採購與本土 CA 的選擇只剩一家。這一家出錯，962 個政府機關和銀行、證券、保險業，就得在同一週一起動起來。
（二）一個月內的五張通報
序號問題也不是 TWCA 唯一的通報。從 10 月 10 日到 11 月 2 日，Bugzilla 上與 TWCA 有關的通報共有五張。
10 月 10 日那張，是委派 OCSP 回應憑證的一個欄位設定不符規範。10 月 29 日，TWCA 自行通報 RA 伺服器出現遭未授權存取的跡象，表示至今沒有發現誤發憑證。10 月 30 日與 11 月 2 日，分別是本文談的 CA 憑證 24 位元與網站憑證 63 位元問題。11 月 1 日另有一張 EV 憑證管轄地欄位不符的通報，完整報告盤點出 331 張，其中 320 張已撤銷、11 張在撤銷前到期。
Chrome 當初停止信任中華電信，看的正是一連串合規缺失的累積。
（三）換證會越來越頻繁
這次各單位要在一週內換掉上萬張憑證，往後這種動作只會更常見。
CA/Browser Forum 在 2025 年 4 月通過第 SC-081 號提案，逐步縮短網站憑證的效期上限。2026 年 3 月 15 日起為 200 天，2027 年 3 月 15 日降到 100 天，2029 年 3 月 15 日只剩 47 天。這項提案投票時，TWCA 投下棄權票。
效期上限 47 天，代表一年至少要換 8 次憑證，實務上會提前續發，次數只會更多。靠人工換證、在 App 裡寫死憑證的做法，都撐不住這種頻率。
政策面的討論也已經開始。立委葛如鈞在事件後要求政府推動改革，包括建立跨 CA 備援，避免一家出問題、所有服務一起停擺，並導入短效憑證與自動化更新。數發部已委託獨立第三方專業機構檢測 TWCA，並表示將調查違約情事、依約罰款及求償。金管會主任秘書尚光琪則在記者會上表示，金管會並非臺網公司的主管機關。
結論：信任要每次重新核對
回頭看這起事件，技術問題本身並不複雜。TWCA 的 CA 端序號產生方式，在 2016 年規範上路後一直沒改，網站憑證端則少了 1 位元亂數；被外部研究者揭露後，依國際規範，舊的中繼憑證只剩 7 天可用。真正值得注意的是牽動的範圍。一家本土 CA 的產製缺失，讓 962 個政府機關和銀行、證券、保險業在一週內同步換證，部分 App 還得請使用者手動更新。
對不同角色，馬克的建議是：
一般民眾：App 跳出更新就更新。 電腦瀏覽器不必動作。若有人以「憑證更新」為由要你提供帳密或點連結，要提高警覺。
銀行與 App 開發者：綁定要留備援。 做憑證綁定就要依官方建議加入備援金鑰，伺服器端也要裝好完整憑證鏈，下次換證才不必逼使用者更新。
政府與主管機關：把第二家 CA 準備好。 47 天效期上路後，換證會變成日常作業，自動化與跨 CA 備援要從建議變成標準配備。
短期來看，數發部的第三方檢測與罰款結果，是下一個看點。長期來看，能自動換證、能切換第二家 CA 的機構，才不必每次都熬夜趕工。
網站的信任不靠一次發證，靠的是每一次連線都重新核對。
常見問題 FAQ
TWCA 憑證換發是怎麼回事？
2026 年 10 月 30 日，外部研究者在 Mozilla Bugzilla 提出通報。臺灣網路認證公司（TWCA）的 CA 憑證序號，只有 24 位元亂數。網站憑證也只有 63 位元，都低於國際規範要求的 64 位元。依規定，不合規的憑證必須撤銷，因此 TWCA 在 11 月 6 日凌晨撤銷舊的中繼憑證，政府與金融業在一週內全面換發。
用電腦登入網銀需要做什麼嗎？
不需要。金管會表示，用網頁連線基本上不受影響，憑證由銀行端在伺服器上更新。瀏覽器每次連線都會重新驗證信任鏈，民眾不必自行操作。
為什麼銀行 App 要更新？
業界常見的原因之一是 App 做了憑證綁定（certificate pinning），把特定的憑證或公鑰寫進程式裡。TWCA 這次換掉了中繼憑證和它的金鑰，綁定舊資訊的 App 會拒絕連線，只能發新版更新；中華郵政的公告就寫明是升級「APP內建之安全憑證」。
網銀轉帳用的憑證要重新申請嗎？
這次換發的對象是銀行網站的伺服器憑證，由銀行在伺服器端更換。網銀轉帳用的金融 XML 憑證是發給民眾的用戶端憑證，用來確認交易由本人發動，跟這次換的網站憑證是兩套東西。若有人以「憑證更新」為由要你提供帳密或點連結，要提高警覺。
憑證序號為什麼一定要是亂數？
為了讓攻擊者無法事先算出 CA 會簽下的完整內容。2008 年，研究者抓住 RapidSSL 序號依序遞增、簽發時間可預測的弱點。他們配合 MD5 碰撞，偽造出主流瀏覽器都信任的 CA 憑證。CA/Browser Forum 因此從 2016 年 9 月 30 日起，要求序號至少含 64 位元的密碼學安全亂數。
序號不夠亂，會有資安風險嗎？
風險偏低。數發部表示此事「目前並未造成具體資安危害」，研究者也指出，序號短，本身不足以偽造 SHA-256 簽章。但國際規範不看風險高低，不合規的中繼憑證必須在 7 天內撤銷，Mozilla 也不給例外，所以仍要全面換發。
根憑證、中繼憑證、網站憑證有什麼不同？
根憑證像發證機關，內建在瀏覽器與作業系統的信任清單裡；中繼憑證像發證窗口，實際替網站簽發憑證；網站憑證就是發給網站的身分證。瀏覽器會從網站憑證一路往上核對，只要接到清單裡、沒有被加上限制的根憑證，整條信任鏈就算可信。