從國際憑證安全規範、網站憑證更新，到企業如何透過自動化憑證生命週期管理機制強化數位信任基礎建設

歐立威科技共同呼籲：採用 TWCA 憑證的企業與機關，請儘速完成憑證更新！

近日，台灣數位憑證服務傳出憑證序號亂數不足的資安事件。根據數位發展部公告，本次事件涉及 962 個政府機關、9,772 張網站 TLS 憑證，相關單位必須依照主管機關及 TWCA 通知，儘速完成憑證更新與部署。

歐立威科技提醒，這次事件的影響不僅限於政府網站，也值得所有採用 TWCA 憑證服務的企業與機關立即檢視自身環境，包括網站伺服器、API、內部應用系統及行動 APP，確認是否使用受到影響的憑證或憑證鏈，並依照 TWCA 通知完成更新與驗證。而民眾有使用對應企業與機關的 APP，也應立即進行 APP 更新以確保資訊安全。

憑證更新不只是更換一張憑證，更涉及整個企業資訊系統的信任鏈與服務可用性。

為什麼一張憑證的亂數不足，會造成大量網站及 APP 必須更新？企業又該如何避免未來遇到類似事件時，仍然只能依賴人工逐一盤點與部署？

本文將從這次 TWCA 憑證事件出發，解析憑證序號的密碼學安全要求，以及企業如何透過歐立威科技 Vault CLM 解決方案建立自動化憑證生命週期管理機制。

一、事件始末：128-bit 憑證序號，實際只有 24-bit 亂數

2026 年 10 月 30 日，國際資安社群 Mozilla Bugzilla 收到研究人員針對台灣網路認證公司（TWCA）憑證的通報，指出部分 TWCA 所簽發的 CA 憑證，其憑證序號（Certificate Serial Number）未符合 CA/Browser Forum（CAB Forum）所要求的密碼學安全亂數標準。

問題在於，這些憑證的序號雖然設計為 128 bits，但經研究人員分析後發現，序號中只有首尾各 12 bits 為有效隨機數，中間欄位皆為固定值，實際隨機亂數僅有 24 bits。

換句話說：

項目	數值
憑證序號設計長度	128 bits
實際有效亂數	24 bits
國際規範最低要求	64 bits

這代表憑證序號的實際隨機性遠低於國際規範要求。

為什麼這很重要？

在 X.509 憑證架構中，Certificate Serial Number 是由憑證簽發機構（CA）配置的識別資訊，用來識別特定憑證，也會應用於憑證撤銷清單（CRL）及其他憑證管理程序。

如果序號的亂數不足，可能增加序號碰撞及可預測性風險，影響憑證識別與管理機制的安全性。

這次事件並不是 RSA 金鑰長度不足，也不是網站私鑰遭到破解，而是憑證產製流程中的隨機數品質不符合國際規範。

值得注意的是，數位發展部也說明，目前並未發現這次事件已造成具體資安危害，但仍必須依照國際憑證標準完成改善。

這次事件真正值得企業注意的，是憑證序號的表面長度，不等於實際具有的密碼學安全亂數長度。

二、台灣有多少單位受到影響？962 個政府機關、9,772 張網站憑證

TWCA 是台灣重要的數位信任服務提供者，提供 SSL/TLS 網站憑證、身分識別、電子簽署及其他數位憑證服務。

除了民間企業自行採購使用之外，TWCA 也透過數位發展部的採購機制，提供政府機關申請網站 TLS 憑證。

因此，這次事件的影響並不侷限於單一網站或單一企業。

根據數位發展部於 2026 年 11 月 2 日發布的新聞稿，經盤點，本次政府端共涉及：

項目	數量
受影響政府機關	962 個
受影響網站 TLS 憑證	9,772 張
新憑證重新產製完成日期	2026/11/01
政府機關更新期限	2026/11/06

數位發展部於 10 月 30 日接獲通報後，立即要求 TWCA 在兩日內重新產製符合規定的新憑證。

TWCA 已於 11 月 1 日完成政府機關 9,772 張 TLS 憑證的重新產製，並透過電子郵件主動寄送新憑證給原申請機關承辦人。

但重新產製憑證只是第一步。

各機關仍然必須將新憑證部署到原本使用的網站伺服器及相關系統，並完成連線測試。

數位發展部公告指出，截至 11 月 2 日晚間，僅有 926 張憑證完成更新，因此要求各機關務必在 11 月 6 日前完成憑證更新，否則民眾瀏覽相關網站時可能出現瀏覽器安全性警示。

此外，這次事件也不代表只有政府機關受到影響。TWCA 的憑證服務同樣提供給民間企業及金融產業使用，因此企業應主動確認自身憑證是否屬於這次需要更新的範圍。

企業不能只確認網站目前是否正常運作，更應確認所使用的憑證是否已符合最新的憑證安全規範。

三、為什麼網站憑證更新，連手機 APP 也必須強制更新？

這次事件有一個值得特別說明的現象：為什麼網站憑證需要更新，卻連手機 APP 也受到影響？

關鍵在於 APP 與後端服務之間的 TLS 憑證驗證機制。

一般手機 APP 在連線到後端 API 或網站服務時，會透過 HTTPS/TLS 建立加密通道。除了作業系統本身的憑證信任庫之外，部分 APP 也會將特定 CA 憑證、中繼憑證或憑證鏈直接封裝在 APP 內。

這種作法可能包含：

Certificate Pinning：憑證或公開金鑰釘選。
Embedded CA Certificate：將指定 CA 憑證內嵌於 APP。
Certificate Chain Validation：自行管理或驗證指定憑證鏈。

當憑證機構更換中繼憑證或調整憑證鏈時，如果 APP 仍然使用舊的憑證鏈或舊的信任設定，就可能無法正確驗證後端服務。

這時候，即使後端網站已經完成憑證更新，APP 仍可能因為無法通過憑證驗證而無法正常連線。

因此，TWCA 在本次憑證鏈更新通知中特別提醒：

如果應用程式或主機有綁定憑證鏈，就必須提早部署新的憑證鏈並安排更新。

實際案例：台鐵 e 訂通 APP

臺鐵公司於 2026 年 11 月 5 日發布公告，說明為配合 TWCA 資安合規政策，原憑證將於當日 23:59 提前到期。

因此，台鐵 e 訂通 APP 必須更新至 V2.2.5，舊版 APP 在原憑證失效後將無法繼續使用。

臺鐵公司已完成新憑證申請及系統更新作業，並提醒旅客儘速升級 APP。

這個案例清楚呈現了憑證管理與應用系統之間的依賴關係：一張憑證或一段憑證鏈的異動，可能進一步影響使用者手上的 APP。

對企業而言，這也代表憑證管理不能只關注伺服器，還必須了解憑證與應用程式、API、行動裝置及其他服務之間的相依關係。

四、除了 24-bit，還有另一個值得注意的問題：63-bit 憑證亂數

在這次事件持續調查的過程中，Mozilla Bugzilla 又出現另一項與 TWCA 憑證序號相關的通報。

2026 年 11 月 4 日前後，研究人員針對約 1,600 張從 2025 年 Certificate Transparency（CT）Log 蒐集的憑證進行分析，發現部分 TWCA 所簽發的終端使用者憑證（Subscriber Certificates），其序號的 CSPRNG 輸出只有 63 bits，而不是國際規範要求的至少 64 bits。

這與前述 CA 憑證的 24-bit 問題，是兩種不同的序號結構與問題。

項目	CA 憑證事件	Subscriber 憑證事件
Bugzilla 編號	2087236	2087918
實際亂數	24 bits	63 bits
規範要求	至少 64 bits	至少 64 bits
問題類型	固定欄位加上少量亂數	64-bit 欄位最高位元固定為 0
影響範圍	部分 CA 憑證	部分終端使用者憑證

Mozilla Bugzilla 後續紀錄顯示，TWCA 已確認第二項事件涉及部分 Subscriber Certificates 的 63-bit CSPRNG 輸出不足問題，實際受影響數量仍在調查中。

這也提醒企業：憑證安全檢查不能只看 CA 憑證，還必須確認實際簽發給網站及服務的終端憑證。

憑證序號、簽章演算法、金鑰長度、有效期限及憑證鏈，都應該納入企業憑證安全檢查項目。

五、企業真正缺少的是完整的憑證生命週期管理

從這次事件可以看出，企業憑證管理並不是單純的申請與安裝。

一張憑證從產生、核發、部署到最後撤銷，涉及多個技術環節。

尤其大型企業通常同時存在：

多個網域與網站服務。
Windows Server、Linux Server。
IIS、Apache、Nginx、Tomcat、JBoss。
Kubernetes、Docker 與微服務。
Load Balancer、Firewall、API Gateway。
Mobile APP 與後端 API。
內部 CA、外部公開 CA 及不同憑證供應商。

當憑證數量達到數百、數千甚至數萬張時，如果仍然依靠 Excel、電子郵件與人工通知來管理，就很容易出現以下問題。

1. 憑證資產無法完整盤點

企業不一定清楚目前有哪些憑證、分別部署在哪些系統，以及由哪個單位負責。

2. 憑證更新無法自動化

即使 CA 已經重新簽發憑證，企業仍需要人工下載、安裝、修改設定檔及重新載入服務。

3. 憑證鏈異動缺乏關聯分析

當 Root CA 或 Intermediate CA 發生變更時，企業可能無法立即掌握哪些網站、APP、伺服器及應用程式受到影響。

4. 更新完成後缺乏驗證

憑證安裝完成，不代表服務一定正常。還必須確認憑證鏈、有效期限、SAN、簽章演算法及實際 TLS 握手是否正確。

5. 缺乏完整稽核紀錄

憑證由誰申請、誰核准、何時簽發、部署到哪台主機，以及何時完成更新，都應該保留完整紀錄。

這些問題正是企業需要 Certificate Lifecycle Management（CLM，憑證生命週期管理）的原因。

六、歐立威科技 Vault CLM 解決方案是什麼？

歐立威科技 Vault CLM 解決方案，是一套以憑證生命週期管理為核心的企業自動化憑證管理方案，整合 PKI（Public Key Infrastructure）憑證簽發引擎及企業既有的憑證管理環境。

它的目的不只是管理憑證密碼或保存憑證檔案，而是建立從憑證盤點、申請、核發、部署、更新、撤銷到稽核的完整自動化流程。

歐立威科技 Vault CLM 解決方案的核心管理流程包括：

1. Certificate Discovery & Inventory（憑證探索與資產盤點）

自動盤點企業內部及外部服務所使用的憑證，掌握憑證有效期限、簽發者、憑證鏈、部署位置及管理責任。

2. Certificate Request & Approval（憑證申請與核准）

建立憑證申請及核准流程，依照企業安全政策及不同系統的需求管理憑證。

3. Certificate Issuance（憑證簽發）

透過內建 PKI Engine，自動產生及簽發 X.509 憑證，支援企業內部 CA 架構。

4. Certificate Deployment（憑證自動部署）

將新憑證部署至指定伺服器、應用程式及相關服務，降低人工操作錯誤。

5. Certificate Renewal（憑證自動續期）

在憑證到期之前自動啟動續期流程，避免因憑證過期造成服務中斷。

6. Certificate Validation & Audit（憑證驗證與稽核）

確認憑證部署結果、憑證鏈與有效期限，並保留完整的操作及稽核紀錄。

這樣的設計，讓企業不再只是被動等待憑證到期通知，而是能夠主動管理所有憑證資產。

七、Vault CLM 內建 PKI Engine：憑證序號使用多少亂數？為什麼能避免這類問題？

這次 TWCA 事件最值得技術人員注意的，就是憑證序號（Serial Number）的亂數產生方式。

歐立威科技 Vault CLM 解決方案內建 PKI Engine，本身就是一套 X.509 憑證簽發引擎，可以作為企業內部 PKI 的 CA，負責憑證簽發、續期及撤銷。

與本次事件最相關的設計，是 PKI Engine 對憑證序號採用嚴格隨機的產生方式。

其憑證簽發機制使用密碼學安全的隨機產生方式產製憑證序號，而不是依照日期、固定欄位及遞增計數器組合產生憑證序號。

這個設計非常重要。

因為憑證序號即使在外觀上具有足夠的長度，如果其中大部分欄位都是固定值，實際的有效亂數仍然可能不足。

本次 TWCA 事件就是一個具體案例：128-bit 的序號，實際只有 24-bit 的隨機性。

相較之下，歐立威科技 Vault CLM 解決方案內建 PKI Engine 採用嚴格隨機序號的設計，可以避免使用固定欄位搭配少量亂數的序號產生模式。

那麼，PKI Engine 究竟使用多少 bits 的亂數？

這裡必須精確說明：PKI Engine 的技術文件明確描述其序號採用嚴格隨機產生方式，但並未將固定的 CSPRNG 輸出位元數列為產品規格。

因此，不應直接將 128-bit 或 159-bit 宣稱為固定的亂數輸出長度。

不過，從技術設計來看，PKI Engine 具有幾個值得注意的特點：

使用隨機方式產生憑證序號。
由憑證簽發引擎自行產生序號。
透過 PKI Engine 管理 CA 與憑證簽發。
支援憑證生命週期管理及撤銷。
可透過短效憑證降低長期憑證外洩的風險與撤銷管理負擔。

另外，CA/Browser Forum 對公開信任 TLS 憑證的規範，要求憑證序號必須大於零、非連續，且小於 2¹⁵⁹，並包含至少 64 bits 的 CSPRNG 輸出。

這是公開信任憑證的重要規範。

需要特別區分的是，企業自行管理的私有 PKI 並不會因為使用 Vault CLM 就自動成為公開信任 CA，也不會自動取得公開信任憑證的合規資格。

但企業可以將相同的密碼學安全原則納入內部 PKI 的設計與管理要求。

歐立威科技 Vault CLM 解決方案的價值，在於從憑證產生階段就採用嚴格隨機序號設計，再透過完整的憑證生命週期管理，讓企業從簽發到部署、更新及撤銷，都能維持一致且可追蹤的管理機制。

八、如果企業採用歐立威科技 Vault CLM 解決方案，遇到這次事件可以如何處理？

這是我們認為本次事件對企業最有價值的啟示。

假設企業內部管理數千張 TLS 憑證，而其中一個 CA 宣布必須在短時間內更換憑證鏈。

如果沒有自動化管理機制，IT 人員可能必須：

透過電子郵件確認哪些憑證受到影響。
人工盤點所有使用該 CA 的系統。
聯繫各系統負責人。
逐台下載及安裝新憑證。
更新應用程式及伺服器設定。
重新啟動相關服務。
逐一測試網站及 API。
整理更新紀錄並回報管理單位。

這是一個非常耗費人力，而且容易遺漏的過程。

透過歐立威科技 Vault CLM 解決方案，可以將這些工作整合成一套可追蹤的憑證管理流程。

例如：

管理項目	Vault CLM 可提供的管理能力
憑證盤點	掌握憑證、簽發者及部署位置
憑證異動	辨識 CA、Intermediate CA 及憑證鏈變更
影響範圍	找出使用特定憑證鏈的系統
憑證更新	自動化申請、簽發及更新流程
系統部署	整合伺服器及應用程式部署
更新驗證	檢查憑證鏈及服務連線
稽核管理	保留更新紀錄及操作軌跡

尤其當企業同時使用 TWCA、ADCS 及內部 PKI 時，歐立威科技 Vault CLM 解決方案可以協助整合不同憑證來源的管理流程。

例如，當 TWCA 宣布憑證鏈更新時，企業可以先透過憑證資產盤點，確認哪些服務使用相關憑證，再依照系統相依關係安排更新及驗證。

這裡也必須區分一件事：

歐立威科技 Vault CLM 解決方案並不會直接改變 TWCA 已經簽發的公開信任憑證序號，也不能自動消除 APP 內嵌憑證所造成的版本更新需求。

如果企業使用的是 TWCA 公開憑證，仍然必須依照 TWCA 的簽發與更新政策辦理；如果 APP 內有憑證釘選或固定憑證鏈，也仍然需要配合應用程式版本更新。

但歐立威科技 Vault CLM 解決方案可以讓企業提早掌握受影響的憑證及系統，並將更新、部署、驗證與稽核流程自動化，大幅降低臨時事件所帶來的營運壓力。

九、從一次憑證事件，重新思考企業的數位信任基礎建設

這次 TWCA 憑證事件提醒我們，憑證並不是安裝完成就可以放著不管的資安元件。

隨著全球憑證管理規範持續演進，企業未來將面臨更多挑戰，包括：

憑證有效期限逐步縮短。
CA 與 Intermediate CA 定期輪替。
TLS 憑證簽章演算法與密碼學規範更新。
後量子密碼學（PQC）遷移。
多雲及混合雲環境憑證管理。
大量微服務及容器化環境的憑證自動化。

尤其未來當憑證有效期限持續縮短，企業如果仍然依靠人工申請、人工部署與人工更新，將很難維持大規模環境的穩定運作。

歐立威科技認為，企業需要的不只是憑證簽發工具，而是一套能夠持續盤點、監控、管理、更新及稽核所有憑證的自動化管理架構。

透過歐立威科技 Vault CLM 解決方案，企業可以逐步建立完整的 Certificate Lifecycle Management 機制，將憑證管理從被動式的到期處理，轉變為主動式、自動化的安全管理。

憑證安全不應該等到到期、撤銷或發生事件時，才開始處理。真正成熟的憑證管理，是讓每一張憑證從簽發的那一刻起，就處於可追蹤、可管理、可驗證的生命週期之中。

歐立威科技 Omniwaresoft

歐立威科技 Vault CLM 解決方案｜企業憑證自動化管理｜Certificate Lifecycle Management

歐立威科技 Vault CLM 解決方案更多資訊請參考：https://www.omniwaresoft.com.tw/vault-clm-solution/

主要資料來源

數位發展部：TWCA 憑證事件及政府端影響範圍
https://moda.gov.tw/press/press-releases/21226
Mozilla Bugzilla #2087236：TWCA 24-bit CA 憑證序號問題
https://bugzilla.mozilla.org/show_bug.cgi?id=2087236
Mozilla Bugzilla #2087918：TWCA 63-bit Subscriber Certificate 問題
https://bugzilla.mozilla.org/show_bug.cgi?id=2087918
TWCA：憑證鏈更新通知
https://twiddemo.twca.com.tw/acme/replace_cert.html
交通部／臺鐵公司：e 訂通 APP 憑證更新公告
https://www.motc.gov.tw/ch/app/news_list/view?id=14&module=news&serno=04ff297e-dbf8-4c8a-9de3-d5dce10c0df0
CA/Browser Forum：Baseline Requirements
https://cabforum.org/working-groups/server/baseline-requirements/requirements/

從 TWCA 24-bit 憑證亂數事件，看企業憑證管理的風險與因應之道