觀點 · 資訊分享
憑證機構 eMudhra 8 張中繼憑證私鑰外洩：金鑰小到能直接算出，Mozilla 決定緊急撤除根憑證信任
eMudhra 有 8 張中繼憑證的私鑰因產生程序出錯，小到可以直接算出來。Mozilla 與 Chrome 在 10 月 17 日當天就封鎖，Mozilla 決定緊急移除 emSign ECC Root CA - G3 的信任，Firefox 158.0.1 把封鎖清單直接內建。
- 發布
- 2026-10-20
- 篇幅
- 約 4 分鐘 · 1,932 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：憑證機構 eMudhra 有 8 張中繼憑證的私鑰弱到可以直接算出來，瀏覽器當天就緊急封鎖，Mozilla 更決定移除它一張根憑證的信任，約 3 萬張網站憑證要換發。
先用白話講：憑證機構和中繼憑證是什麼？
你在網址列看到的小鎖頭，代表這個網站出示了一張「身分證」（HTTPS 憑證），證明它真的是它自稱的那個網站。這張身分證不是網站自己印的，而是由憑證機構（CA）蓋章發出。
憑證機構的印章分成兩層：最重要的「總章」（根憑證）鎖在保險庫裡，平常用的是授權出去的「分章」（中繼憑證）。只要拿到分章，就能替任何網站蓋出看起來完全合法的身分證。
這次 eMudhra 的 8 顆分章，鑰匙做得太簡單，簡單到別人可以直接算出來。
發生什麼事
依 Mozilla 的公告與 Bugzilla 事件紀錄（時間皆為 UTC）：
- 10 月 17 日 20:06：Mozilla 收到 Chrome 根憑證計畫轉來的報告，eMudhra 8 張中繼憑證的私鑰已被掌握，並附上證明
- 原因：這 8 把 P-384 金鑰都是小於 256 的整數，等於只剩最後一個位元組，Mozilla 也自行還原了金鑰
- 範圍：其中 6 張是 TLS 中繼憑證，受 Chrome、Mozilla、Microsoft、Apple 信任；2 張是 Microsoft 信任的程式碼簽章中繼憑證
- 當天處置：22:46 Chrome 的 CRLSet 撤銷 6 把 TLS 金鑰；22:59 Mozilla 完成 OneCRL 封鎖
- 10 月 18 日：eMudhra 以「CA 遭入侵」為由撤銷 8 張憑證；Sectigo 也撤銷了它交叉簽署的相關憑證
- 10 月 20 日：Firefox 158.0.1 釋出，把封鎖清單直接內建
金鑰為什麼這麼弱？
eMudhra 的初步說法是：產生金鑰的儀式腳本有缺陷，額外產生了一組很弱的金鑰，又因為兩組金鑰的標籤很像，被誤拿去使用，過程中還有多處人為錯誤。受影響的金鑰來自 2025 年 4 月 30 日建立的同一批 24 張中繼憑證中的 B、C 系列。
Mozilla 註明這些說法是初步的，B、C 系列的 RSA 金鑰與 A 系列為何沒受影響，都還在調查。
更多細節
| 處置 | 內容 |
|---|---|
| 根憑證 | Mozilla 緊急移除 emSign ECC Root CA - G3 的信任，G1 不移除；Chrome 表示會走類似路線 |
| 停止簽發 | eMudhra 停止從 G3 底下的所有中繼憑證簽發 |
| 客戶遷移 | 約 3 萬張憑證要換發，約 97% 透過 ACME 簽發，計畫移到 G1（RSA）根憑證底下 |
| Firefox | 158.0.1 內建封鎖清單，即使政策停用遠端設定也有效（CVE-2026-113470）；Android 版另以 158.0.2 修正封鎖清單問題 |
我讀到的官方資料沒有提到是否已經出現實際被偽造的憑證。
我的看法
這件事最可怕的不是駭客多厲害，而是一個腳本錯誤，就讓整個信任體系的一環失效。幸好瀏覽器的反應非常快，從收到報告到封鎖不到 3 小時（依官方時間軸自行計算）。
對一般使用者，保持瀏覽器自動更新就好。對開發者，我覺得有一點常被忽略：很多程式和 Docker 映像檔自帶一份憑證清單，不會跟著瀏覽器更新。建議趁這次檢查伺服器的 ca-certificates 套件、Node.js 或 Python 的憑證套件，並重建映像檔。另外，約 97% 的受影響憑證是用 ACME 自動簽發的，這也再次說明憑證自動化的價值：真的出事時，換發可以很快。
名詞小辭典
- 憑證機構（CA）：負責簽發 HTTPS 憑證、替網站身分背書的機構。
- 中繼憑證（Intermediate Certificate）：由根憑證授權、實際用來簽發網站憑證的憑證。
- OneCRL / CRLSet：Firefox 與 Chrome 用來遠端封鎖問題憑證的清單，不用等瀏覽器改版就能生效。
- ACME：自動申請與更新憑證的通訊協定，Let’s Encrypt 就是用它。