eMudhra 中介憑證私鑰外洩：8 張 CA 憑證遭四大瀏覽器封鎖，一次看懂 HTTPS 信任鏈與該做的更新
2026 年 10 月，印度憑證機構 eMudhra 的 8 張中介 CA 憑證被發現私鑰可以被輕易還原，Google、Mozilla、Apple、Microsoft 在四天內相繼封鎖，Java、Go 等程式語言的信任清單也緊急更新。有資安人員形容這次清理工作「比 Heartbleed 還大」。這篇從 HTTPS 的憑證信任鏈講起，說明這件事為什麼嚴重、一般使用者與開發者該怎麼確認自己沒受影響。
先搞懂：HTTPS 的憑證信任鏈
瀏覽器判斷一個網站是不是真的，靠的是一條信任鏈：
- 根憑證（Root CA）：內建在作業系統或瀏覽器裡，是信任的起點
- 中介憑證（Intermediate CA）：由根憑證簽發，實際負責替網站簽發憑證
- 網站憑證：由中介 CA 簽發，證明「這個網域屬於這個網站」
只要拿到任何一張受信任的中介 CA 私鑰，就能替任何網域簽發瀏覽器會接受的憑證。換句話說，攻擊者可以偽造 google.com 或你家銀行的 HTTPS 憑證，搭配中間人攻擊讓使用者完全看不出異狀。
eMudhra 發生了什麼事？
問題出在金鑰產生過程。這 8 張中介憑證在 2025 年 4 月簽發，但它們的私鑰是用熵不足的隨機數產生的。Mozilla 的 Dennis Jackson 指出，這些私鑰「除了最後一個位元組外幾乎全是零」，用 baby-step giant-step 離散對數演算法就能快速算出私鑰，已經有多人各自獨立還原成功。
eMudhra 的說明是：金鑰產生儀式中，一個有問題的腳本另外產生了一組很弱的金鑰，因為標籤和原本的金鑰很像，被誤用來產生憑證簽署請求，而且流程中的多個步驟都出現人為疏失。
時間軸
| 日期 | 事件 |
|---|---|
| 2025 年 4 月 | 8 張中介憑證簽發 |
| 2026/10/17 | Mozilla Firefox、Google Chrome 封鎖 |
| 2026/10/19 | Apple 封鎖 |
| 2026/10/20 | Microsoft 封鎖；eMudhra 撤銷憑證並通知下游信任清單 |
| 2026/10/20～21 | OpenJDK、Go 等語言執行環境相繼更新信任清單 |
影響有多大？
- 瀏覽器使用者：主流瀏覽器已封鎖，保持更新的使用者風險很低
- 真正的風險在「不會自動更新信任清單」的地方：舊版 Java 執行環境、內嵌裝置、自帶 CA 清單的應用程式、長期沒更新的伺服器與容器映像
- 目前沒有濫用跡象：在撤銷前的憑證透明度（CT）紀錄中沒有發現惡意簽發，但不是所有用戶端都強制檢查 CT，無法完全排除
同一時間，Oracle 在 10 月 21 日針對 Java 的 JSSE 元件發布緊急安全警告（CVE-2026-91403，CVSS 9.1）。Oracle 沒有說明原因，但 OpenJDK 的公告與多家媒體將它和這次中介憑證外洩連結在一起。
開發者與維運該做什麼？
- 更新作業系統與瀏覽器，讓系統的 CA 信任清單是最新的
- 更新 Java：Java SE 8、11、17、21、25 等版本都在受影響清單中，請依 Oracle 或你使用的 OpenJDK 發行版公告升級
- 更新 Go 工具鏈：Go 以 CVE-2026-111943 封鎖這些憑證，用到內建憑證池的程式要以新版重新編譯
- 重建容器映像：映像中的
ca-certificates套件可能是舊的 - 檢查自帶 CA 清單的應用程式與套件，確認都已更新
- 用檢測工具確認：Dennis Jackson 公開了檢查用戶端是否仍信任這些中介憑證的工具
這件事給我們的教訓
密碼學演算法本身沒有被破解，出問題的是「產生金鑰」這個流程。金鑰產生儀式、隨機數來源、交叉核對（maker/checker）只要有一環出錯，再強的演算法都沒用。對一般開發者來說，最實際的提醒是：不要自己產生金鑰或亂數，使用作業系統提供的安全亂數來源（例如 /dev/urandom、Python 的 secrets 模組），並定期更新信任清單。