替網站簽發憑證的機構，私鑰竟然是數字 4。資安研究者 Scott Helme 在 2026 年 10 月 20 日公布分析，確認 eMudhra 八個中繼憑證機構的私鑰都小得異常，能從公開憑證快速猜出，其中還有 56、115 等數值。 研究者的復原分析
這些私鑰用來簽署其他憑證，落入他人手上就可能被用來冒充網站。Mozilla 與 Chrome 已採取緊急封鎖措施，更新範圍也延伸到作業系統、程式語言與應用程式使用的憑證信任庫。
eMudhra 與憑證機構是什麼
eMudhra 是印度的數位信任服務公司，以 emSign 品牌提供電子憑證服務。憑證機構（Certificate Authority，CA）負責驗證身分，再用數位簽章把網站名稱與公鑰連結起來；瀏覽器連上 HTTPS 網站時，會檢查憑證與信任鏈，確認連線對象的身分。
信任鏈通常從瀏覽器或作業系統預先信任的「根 CA」，延伸到負責簽發的「中繼 CA」，最後到網站憑證。中繼 CA 的私鑰是簽發憑證所需的秘密；這次受影響的是八把中繼 CA 私鑰，包含六個 TLS 憑證簽發單位與兩個程式碼簽章單位。 Mozilla 事件紀錄
HTTPS 同時需要加密與身分驗證。若軟體仍信任已遭破解的中繼 CA，能攔截連線的攻擊者就可能拿假憑證冒充目標網站，讀取或修改經過的資料。這也是 CA 私鑰出問題會牽動多種軟體更新的原因。 Mozilla 安全公告
私鑰為什麼是 4
ECC 私鑰本身是整數，4 也在有效範圍內，因此能算出格式有效的公鑰。這次受影響的金鑰使用 P-384 橢圓曲線。正常情況下，私鑰應從極大的有效範圍隨機選出，讓外界即使知道公鑰，也無法實際搜尋出私鑰。
數值 4 也能算出格式有效的公鑰，因此憑證的曲線、編碼與結構檢查可能都正常；問題在於秘密太容易猜中。Scott Helme 透過公開憑證復原八把私鑰，表示整個過程不到一秒，其中 EM OV TLS CA - G3C 的私鑰就是 4。 P-384 私鑰與復原結果
若從 P-384 的完整有效範圍均勻隨機選取，出現 4 這類極小數值的機率極低，八把私鑰全部小於 256 更顯示產生流程異常。eMudhra 初步表示，金鑰包裝與解包測試中的程式錯誤產生了第二組弱金鑰，又因標籤相似而被誤用；至於哪個錯誤讓數值恰好成為 4，公司尚未公布確切根因。 初步調查說明
這個數字也讓人想起 xkcd 的 〈Random Number〉漫畫 ：程式永遠回傳 4，卻用註解表示它來自擲骰子。漫畫笑點在於固定輸出無法提供隨機性；eMudhra 事件則是實際產生了可被快速搜尋的弱金鑰。
私鑰外洩會造成什麼影響
任何人一旦復原這些中繼 CA 私鑰，就能替自行製作的網站憑證產生可通過密碼學驗證的簽章。攻擊者可在假憑證填入真正網站的網域名稱，再讓憑證綁定自己掌握的網站公鑰。若瀏覽器或應用程式仍信任這條憑證鏈，且未透過撤銷清單或憑證透明度等檢查阻擋，就可能把攻擊者的假網站判定為真正的網站。
當攻擊者也能攔截或重新導向使用者的連線，就可能利用這張假憑證建立冒充原網站的 HTTPS 連線，取得登入資料、讀取或修改傳輸內容。用戶端需要更新信任庫與封鎖資訊，讓這些簽章即使數學上有效，也無法再通過網站身分驗證。 Google 對偽造 HTTPS 憑證的風險說明
受影響的八把金鑰各有 eMudhra 簽發的中繼憑證，也有 Sectigo 以 AAA Certificate Services 根憑證交叉簽署的版本。交叉簽署讓同一把公鑰可透過另一條鏈取得信任，因此修正需要涵蓋這些替代鏈。Chrome 的封鎖以公鑰識別資料為依據，將受影響 TLS 中繼憑證及其跨簽版本一併處理。 Chrome Root Program 說明
eMudhra 表示，七個受影響中繼 CA 未投入正式環境，另一個也未簽發終端憑證。公司仍在調查確切根因。 eMudhra 事件聲明
Mozilla 後續進一步決定緊急移除 emSign ECC Root CA - G3 的信任，Chrome 也宣布採取相同方向。這讓同一根憑證下其他仍在使用的憑證也需要遷移；eMudhra 在事件紀錄中初估約有 3 萬張憑證需要轉移到其他信任鏈。Google 預計於 10 月 27 日美西時間上午，向使用 Chrome Root Store 的穩定版裝置推送根信任移除更新；使用這條鏈的網站需要提前完成替換。 根憑證處置與遷移說明
Chrome 也會要求公開信任的網站憑證符合憑證透明度（Certificate Transparency，CT）規則，讓簽發紀錄可被監督。Chrome 團隊表示，在最初封鎖受影響中繼 CA 時，未在 CT 日誌看到它們簽發的 TLS 憑證。這項機制為瀏覽器提供額外防護；程式與命令列工具則需要依自身的憑證驗證方式處理更新。 Chrome 初期封鎖說明
研究者如何發現弱私鑰
最初通報者是研究者 Wayne。他在測試公開憑證資料時，發現 eMudhra 的橢圓曲線私鑰可以被復原，隨後反覆驗證，並把證據交給瀏覽器團隊與 eMudhra。 Wayne 公布的發現時間軸 記錄了這段過程，以下換算為台灣時間。
| 台灣時間 | 發現與通報過程 |
|---|---|
| 10 月 18 日 00:00 | 開始試用新工具 |
| 00:27 | 檢查 CCADB 的一批測試資料，發現橢圓曲線金鑰問題 |
| 01:43 | 多次驗證後，用每把私鑰製作簽章證明 |
| 02:05 | 將報告與簽章證據寄給 Apple、Chrome、Microsoft、Mozilla 及 eMudhra |
| 04:18 | 擴大檢查完整 CCADB 資料，確認 Sectigo 跨簽憑證也受影響 |
| 05:48 | Mozilla 未取得破解方法提示，也獨立復原私鑰 |
CCADB 是憑證機構資料的公開資料庫，研究者能取得其中的憑證與公鑰。這次弱私鑰的數值都小於 256，讓公開資料足以用來驗證候選值。Wayne 再用八把私鑰分別簽署警告訊息，接收者可用憑證中的公鑰驗證簽章，確認他確實掌握私鑰。 事件協調頁的簽章證據說明
Wayne 是最初發現並通報的人；Scott Helme 則在後續獨立復現，公開各把私鑰的數值與技術解釋，讓「私鑰竟然是 4」成為事件受到關注的焦點。
金鑰產生流程出了什麼問題
依 eMudhra 在 Mozilla 事件紀錄中的初步說明，2025 年 4 月 30 日的金鑰產生程序使用硬體安全模組（HSM）。流程加入了金鑰包裝與解包測試，但程式錯誤又產生第二組較弱的金鑰；因標籤相似，工作人員誤用弱金鑰建立憑證簽署請求，之後也送交 Sectigo 跨簽。 eMudhra 的初步調查回覆
HSM 可以保護儲存在其中的金鑰，但仍需要正確的產生流程、物件識別與驗收。公司表示正在重查整個程序，完整根因仍待調查完成後公布。
| 日期 | 事件 |
|---|---|
| 2025 年 4 月 30 日 | 產生本次受影響的中繼 CA 金鑰 |
| 2026 年 10 月 17 日（UTC） | 研究者 Wayne 通報並提供八把私鑰的控制證明；Chrome、Firefox 當日完成相關封鎖 |
| 10 月 19–20 日 | 事件協調頁記載 Apple、Microsoft 陸續採取封鎖措施 |
| 10 月 20 日 | Mozilla 公開公告，Scott Helme 公布弱金鑰復原分析 |
| 10 月 21 日 | eMudhra 更新公司聲明，調查持續進行 |
瀏覽器與開發環境需要更新什麼
一般使用者應更新瀏覽器與作業系統，並維持安全更新功能啟用。Mozilla 先透過 OneCRL 發送封鎖資訊，也發布 Firefox 更新。部分 Android 設定檔曾未在啟動時套用新封鎖清單，Mozilla 後續表示已在 Firefox 158.0.2 修正並推送給使用者。 Firefox Android 後續修正
開發者與管理者還要盤點程式實際使用的憑證庫。部分 TLS 用戶端不會像瀏覽器一樣自動取得撤銷資訊，容器也可能保留建置當時的 CA bundle。更新主機後，仍需確認應用、虛擬環境及容器內的信任資料是否一起更新。 事件更新與套件追蹤頁
| 環境 | 已公布的處置或版本 | 管理重點 |
|---|---|---|
| Node.js 22 | 22.23.4 更新內建根憑證集合 | 更新執行環境，重新部署服務 |
| Go | 1.27.3、1.26.10 在 crypto/x509 過濾受影響鏈 | 使用修補版重新建置並部署程式 |
| Python certifi | 2026.10.19 更新憑證集合 | 逐一檢查實際使用 certifi 的環境 |
| Linux／容器 | 更新發行版 ca-certificates 或含修正的基底映像 | 重建映像、替換容器，核對容器內套件 |
Node.js 22.23.4 的 官方發行說明 列出更新至 NSS 3.131.1 根憑證集合的修正；Go 的 安全公告 則以 CVE-2026-111943 追蹤此項防護。Python 可核對 certifi 2026.10.19 。其他分支應依各自維護者公告更新。
網站管理者若使用受影響中繼 CA，或整條鏈依賴 emSign ECC Root CA - G3，應聯絡憑證供應商確認重發與替換鏈；一般使用者的工作則是更新驗證端。遇到憑證錯誤時，應查明信任鏈與更新狀態，保留 HTTPS 驗證，避免用略過檢查的設定恢復連線。
常見問答
這次事件涉及中繼 CA 的 ECC 私鑰，網站憑證是否需要替換則取決於實際使用的信任鏈。
這次是 RSA 被破解嗎？
不是。這次八把弱私鑰使用 ECC P-384；eMudhra 表示 RSA 簽發單位經過不同流程，其初步評估未受同一問題影響。問題在金鑰產生與選用流程。
私鑰為 4，代表只有 4 bit 嗎？
不是。「4」是私鑰的整數值，二進位寫成 100。P-384 是使用的曲線，並不能保證每一把產生的私鑰都有足夠隨機性。
所有 eMudhra 網站憑證都需要重發嗎？
需要按實際憑證鏈判斷。使用受影響中繼 CA 或依賴 emSign ECC Root CA - G3 的憑證，都需要向供應商確認替換；公司表示多數 TLS 憑證使用其他信任階層。用戶端則應安裝相關安全更新。
和 PHP 重大漏洞是同一件事嗎？
不是。eMudhra 事件處理憑證與身分驗證的信任； PHP 安全更新 修補的是伺服器執行環境的記憶體漏洞。兩者的更新項目與驗收方式不同。
參考來源
- Google: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates (Chrome 與 Android 防護)
- Mozilla: Protecting Firefox users following the compromise of eMudhra intermediate certificates (Firefox 緊急防護)
- Mozilla Bugzilla: eMudhra: Private key compromise of Intermediate Certificates (中繼憑證私鑰事件)
- Scott Helme: Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds (弱私鑰復原分析)
- eMudhra: eMudhra Statement on Recent Certificate Security Incident (公司事件聲明)
- Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates (瀏覽器處置與跨簽)
- Dennis Jackson: eMudhra Intermediate CA Compromise (更新狀態追蹤)
- xkcd: Random Number (隨機數漫畫)
- Node.js: 2026-10-21, Version 22.23.4 ‘Jod’ (LTS), @aduh95 (Node.js 22 安全更新)
- Go: [security] Go 1.27.3 and Go 1.26.10 are released (Go 憑證鏈防護)
- certifi: 2026.10.19 (Python 憑證集合更新)