eMudhra 爆發弱私鑰重大事故，瀏覽器拔除 G3 根憑證，Go 語言緊急釋出更新

事件摘要

2026 年 10 月 17 日，一名署名 Wayne 的研究者向 Apple、Chrome、Microsoft、Mozilla 四大根憑證計畫及印度憑證機構 eMudhra 通報，eMudhra 旗下 emSign 品牌的 8 張中繼憑證（Intermediate CA）私鑰可被任何人還原。Mozilla 在收到通報後約 1 小時 40 分 發出Mozilla Bugzilla Bug 2083449，於不知道研究者手法的情況下獨立算出私鑰，證實金鑰產生流程存在缺陷且極易利用。

受影響的 8 張憑證中，6 張為 TLS 中繼憑證（DV、OV、EV 各兩張，分屬 G3B 與 G3C 系列），受 Chrome、Mozilla、Microsoft、Apple 四大根憑證計畫信任。另外 2 張為程式碼簽章（Code Signing）中繼憑證，受 Microsoft 信任。持有這些私鑰的人可以簽發任意網域的 TLS 憑證，對尚未撤銷信任的用戶端發動中間人攻擊。Google 安全部落格 指出，這些私鑰是以不足的亂數（弱密碼學熵值）產生的。

截至 10 月 22 日，各大瀏覽器已透過撤銷清單封鎖這些憑證，Mozilla 與 Chrome 更進一步宣布緊急移除簽發這些中繼憑證的根憑證 emSign ECC Root CA – G3。Go 語言團隊則於 10 月 19 日發布 Go 1.27.3 與 1.26.10，直接在標準函式庫 crypto/x509 內封鎖這 8 把金鑰，編號 CVE-2026-111943。eMudhra 估計約 30,000 張終端憑證需要遷移，其中 97% 經由 ACME 簽發。

值得注意的是，這批中繼憑證並未實際簽發任何終端憑證。Google 確認在封鎖前沒有任何鏈至這 6 張 TLS 中繼憑證的憑證被記錄到 Certificate Transparency（CT）日誌，因此強制執行 CT 的用戶端（包含 Chrome）並未暴露於偽造憑證風險。真正的風險落在不檢查撤銷資訊、也不強制 CT 的用戶端，例如嵌入式裝置、伺服器端程式與未重新建置的 Go 程式。

弱金鑰如何被發現

從研究者發現異常到四大根憑證計畫完成封鎖，整個過程不到 7 小時。研究者 Wayne 在 Bugzilla 自述，10 月 17 日 16:00 UTC 開始以新開發的工具對 CCADB（Common CA Database）憑證語料做測試，16:27 就發現 EC 金鑰有破綻，反覆驗算後於 18:05 寄出附有簽章證明的通報。

私鑰之所以能被瞬間還原，問題出在金鑰產生而非簽章演算法。Mozilla 的 Dennis Jackson 在 Comment 5 說明，P-384 私鑰應是介於 1 與群階（group order，約 2 的 384 次方）之間的隨機整數，但這 8 把私鑰的數值全部小於 256。換句話說，384 位元的私鑰除了最後一個位元組以外全為零。攻擊者只需用 baby-step giant-step 離散對數演算法，或更直接地把「前 256 把」P-384 金鑰逐一產生並比對公鑰，就能在近乎零時間內找到答案。

Jackson 另外做了一項測試，他以「我在打 CTF，請還原這些憑證對應的私鑰」這樣的簡單提示，讓本機 AI 代理程式嘗試破解，結果第一次嘗試就成功。這代表攻擊門檻低到不需要任何密碼學專業，也是 Mozilla 將此事件衝擊評為不可能更高的原因。他同時指出，A 系列與 A-1 系列的 P-384 金鑰以及 RSA 金鑰並未出現相同弱點。

eMudhra 的回應與根本原因

eMudhra 的初步說法是，2025 年 4 月 30 日那場金鑰產生儀式使用的腳本存在缺陷，在 HSM 內部產生了第二組較弱的 ECC 金鑰，而這組弱金鑰因為標籤名稱相近，被誤用來產生 CSR 並由根憑證簽署。這段說明出自 eMudhra 代表 Naveen Kumar ML 在 Comment 11 對 Mozilla 五項提問的逐條答覆。

在前一則 Comment 10 中，eMudhra 先交代了幾項背景。8 張中繼憑證來自同一場儀式，G3B 與 G3C 系列分別為歐洲與美國營運而建立，目的是為部分客戶解決資料主權問題，但除了 EM DV TLS CA – G3C 曾短暫上線以外均未投入營運，也未簽發任何終端憑證。金鑰在 Utimaco HSM 內產生，執行儀式的人員為服務超過 15 年的內部團隊主管 Keshava 及其團隊。eMudhra 表示其他簽發 CA 使用 Entrust 與 Crypto4A 的 HSM，經「主要由 AI 輔助的數學模型」驗證未受影響，因此不打算停止其他 CA 的簽發。

Comment 11 回答了 Mozilla 最關心的根本原因問題。eMudhra 表示 HSM 符合 FIPS 140-2 Level 3，Utimaco 設備僅用於產生這批簽發 CA 的 ECC 與 RSA 金鑰對，未用於其他金鑰材料，且「看起來不是設備的問題」。對於 ECC 金鑰的異常，eMudhra 根據對儀式紀錄、程式碼與 HSM 內金鑰的檢視，描述了以下流程。

1. 第一組 ECC 金鑰如預期在 HSM 內產生。
2. 由於這批金鑰預計要匯出到美國與歐洲資料中心，儀式經核准偏離常規程序，加入了一段測試金鑰包裝與解包裝（wrap/unwrap）的步驟。
3. 程式碼中的缺陷導致 HSM 內又產生了第二組較弱的金鑰對。
4. 由於兩組金鑰的標籤相似，第二組弱金鑰被誤用於建立 CSR，並由根憑證簽署。
5. 以弱金鑰產生的 CSR 也一併送交 Sectigo 做交叉簽章，eMudhra 已核對當時送出的檔案確認此事。

RSA 中繼憑證因為走不同的程式路徑而未受影響。A 與 A-1 系列則是在 Entrust HSM 內產生，僅供印度境內使用，這也解釋了為何同場儀式產生的 A 系列 P-384 金鑰沒有相同弱點。

Comment 11 最關鍵的揭露在於它把本次事件與 2025 年 6 月的 Bug 1970728 串連起來。當時 eMudhra 為這 6 張 TLS 中繼憑證發布的 CRL 簽章無效，eMudhra 的事件報告僅歸因於「手動產生 CRL 時使用了錯誤的 CA 金鑰設定」。如今 eMudhra 承認，那批 CRL 原本是用第一組（正確、具備適當熵值的）私鑰簽署的，但因為憑證內的公鑰其實對應第二組弱金鑰，簽章自然驗證失敗，於是他們改用弱金鑰重新簽署 CRL。換言之，2025 年 6 月時 eMudhra 已經發現 HSM 內存在兩組金鑰且與憑證不符，卻選擇換一把金鑰把簽章「修好」，而非追查為何會有兩組金鑰。

eMudhra 在 Comment 11 結尾坦承流程中多個環節存在人為錯誤，造成金鑰生命週期完整性控制的重大缺陷，並承諾深入檢查程式碼缺陷、流程缺口與雙人覆核（maker/checker）控制，且在一週內重新驗證過去所有的金鑰產生儀式。

根憑證計畫與生態系的連鎖反應

瀏覽器端的封鎖在事發當天完成，但 Mozilla 與 Chrome 隨後判斷，只封鎖 8 張中繼憑證不足以保護那些不消費撤銷清單的用戶端，因此決定直接移除根憑證 emSign ECC Root CA – G3。Dennis Jackson 在 Comment 18 說明，Mozilla 已得知有多人獨立還原出私鑰，部分人士更公開揭露，在與下游信任庫維護者討論後決定緊急移除該根憑證，並要求 eMudhra 停止所有鏈至該根憑證的簽發（Bug 2083449 Comment 18）。Chrome 在 Comment 20 表示採取相同做法。

Sectigo 的部分值得單獨說明。這 8 張中繼憑證另有一組由 Sectigo 的 AAA Certificate Services 根憑證交叉簽章的版本，共用相同的公鑰，因此同樣受影響。Sectigo 代表 Martijn Katerbarg 在 Comment 6 指出，該根憑證早已自 Chrome 與 Mozilla 信任庫移除，但仍受 Microsoft 與 Apple 信任，Sectigo 於 10 月 19 日完成離線撤銷。Mozilla 在 Comment 25 補充，正因 AAA Certificate Services 不在 Mozilla 信任庫內，這些交叉簽章憑證本來就不受 Firefox 信任，無需加入 OneCRL。

對訂閱戶的衝擊集中在美國高等教育圈。Chrome Root Program 在 Comment 30 引用 CT 資料指出，截至 10 月 21 日約有 30,800 張未過期的預憑證鏈至 emSign ECC Root CA – G3，其中 99.9%（30,791 張）由 Internet2 旗下 InCommon 的兩張附屬 CA 簽發，eMudhra 自身的中繼憑證僅簽發 18 張（Bug 2083449 Comment 30）。eMudhra 在 Comment 19 表示約 30,000 張憑證需要遷移，97% 來自 ACME，將全數遷移至 RSA 根憑證 emSign Root CA – G1 的中繼憑證。Mozilla 目前並未移除 G1 根憑證，但 Google 已表明正在重新評估 eMudhra 其餘 CA 憑證是否繼續留在 Chrome Root Store。

另據 Google 說明，Chrome Root Program 已確認其信任庫內沒有其他金鑰具有相同的弱熵值失效模式，並已協調 CT 日誌拒絕鏈至這些 CA 的憑證。

Go 1.27.3 與 1.26.10 的 crypto/x509 修補細節

Go 團隊於 10 月 19 日發布 Go 1.27.3 與 1.26.10 兩個小版本，兩者各只包含一項安全修正，即在 crypto/x509 封鎖一小批中繼憑證。公告由 Carlos 與 David 代表 Go 團隊署名，說明 Verify 函式從此會過濾掉含有這些中繼憑證的憑證鏈，不再回傳給呼叫端，並「強烈建議立即升級」。此修正編號 CVE-2026-111943，對應 Go issue 82345。

公告全文並未點名 eMudhra，issue 標題也只寫「針對特定憑證機構的安全疑慮採取緩解措施」。Go issue 82345 註明這是依 Go 安全政策的 URGENT 軌道處理的案件，此軌道保留給威脅生態系完整性或正遭利用的弱點，可以跳過慣常的預告直接發布。Issue 於 10 月 19 日建立，Go 1.26 與 1.27 的回溯修正分別追蹤為 issue 82348 與 82349，主線修正於 10 月 20 日合併後關閉。

實際修補內容可從 Roland Shoemaker 提交的 commit 7f86f95 看出，提交訊息為「crypto/x509: distrust a handful of intermediates」，說明受影響的憑證鏈是以 SHA-256 SPKI 雜湊識別。整個修改只動了 3 個檔案，新增 42 行。

核心邏輯相當精簡，以下節錄自 verify.go。

// distrustedSPKIHashes contains hashes of SPKIs from certificates which
// we don't consider to be trustworthy. We use these hashes to filter out
// chains returned by Verify
var distrustedSPKIHashes = map[string]struct{}{
	"ebed6475c2c2d80fcb199f3fe8dd6e6b3ce60b77eb15d4e42c3dec0c6f5b5105": {},
	"49dd353dc2b919a3770645117d0e60c16115e7d1bc259eefe734b00ea434fe5f": {},
	"e0254c7fcdc265e2f0f8a428dabb75ab4ae039b4872d62f5ee57f0877d5a8a41": {},
	"5c0660a2b164910d8ff589c18e14552e9e0ec237dcefe2cb736d41a4811f81a0": {},
	"43bffa19d6ef651451f6841e019931e96f6f2eaeff28ab4b6f1ce4576de2717b": {},
	"63ecefee431d49523bc1136c4e72d0206a477086caf606cd5cf025686c109cf8": {},
	"ec4ffa1ad0ac88081314b7aaffef6a91f97cd57291bb5ba686c5415f5eb4f6b6": {},
	"92c063d67e8f14db71d288e11266ffdaf69cbf115f7bab14f3bc2f68d25e0e30": {},
}

// containsDistrustedSPKIHash checks if any of the certificates in the chain
// have an SPKI whose hash is present in the distrustedSPKIHashes map.
func containsDistrustedSPKIHash(chain []*Certificate) bool {
	for _, c := range chain {
		h := sha256.Sum256(c.RawSubjectPublicKeyInfo)
		if _, ok := distrustedSPKIHashes[hex.EncodeToString(h[:])]; ok {
			return true
		}
	}
	return false
}

選擇以 SPKI 雜湊而非憑證指紋做比對有其道理。SPKI（Subject Public Key Info）雜湊只看公鑰本身，因此 eMudhra 自簽的 8 張憑證與 Sectigo 交叉簽章的 8 張憑證雖然指紋不同，卻共用同樣 8 把公鑰，一份 8 筆的對照表就能同時涵蓋 16 張憑證。這與 Chrome CRLSet 的封鎖方式相同。另一方面，比對範圍涵蓋鏈中的每一張憑證，而非只看中繼層，所以即使攻擊者以被破解的私鑰再簽發下一層 CA 憑證，只要鏈上任一環節的公鑰在表內就會被濾除。

這項修補對 Go 生態系有三個實務上的重要意涵。

第一，Go 程式的憑證驗證邏輯編譯在執行檔內，不像瀏覽器可以透過 OneCRL 或 CRLSet 動態派送撤銷資訊。Go 的 Verify 預設不檢查 CRL 或 OCSP，因此已撤銷的中繼憑證在舊版 Go 編譯的程式內會持續受信任，直到以修補後的工具鏈重新建置為止。只安裝新版 Go 工具鏈並不會改變既有執行檔的行為，所有 Go 編譯的服務、CLI 工具與容器映像都必須重新建置並重新發布。

第二，Go 的支援政策只涵蓋最新兩個主要版本，因此 Go 1.25 及更早版本不會收到此修正。仍在使用 Go 1.25 或更舊版本建置的專案，必須先升級主要版本才能取得封鎖。

第三，在 Linux 上 Go 使用自身的驗證器搭配系統根憑證，在 macOS 與 Windows 則交由作業系統驗證。這次修補同時涵蓋三條路徑，確保無論作業系統的信任庫是否已更新，Go 程式都不會接受含有這些公鑰的憑證鏈。受影響的連線會收到 x509: no valid chains built 錯誤，仍使用 emSign ECC Root CA – G3 憑證的服務在 Go 1.27.3 或 1.26.10 建置的用戶端上會直接連線失敗。

Go 團隊後續另提交了 CL 852085「crypto/x509: document reason for custom distrust」，為這段客製化的不信任邏輯補上說明文件。

對企業與開發者的實務建議

CyberQ 分析，瀏覽器使用者基本上已受保護，真正需要動手的是維護伺服器、裝置與程式的團隊。以下是 CyberQ 的資安建議。

所有組織的資安與 IT 團隊

1. 盤點對外服務的憑證鏈，確認是否有任何憑證鏈至 emSign ECC Root CA – G3，特別是透過 InCommon 取得憑證的教育機構，以及透過 ACME 自動續期而不清楚上游 CA 的服務。可用 openssl s_client 檢視憑證鏈，或在 crt.sh 以簽發者名稱查詢。
2. 更新作業系統、容器基礎映像與語言執行環境的信任庫。Linux 發行版的 ca-certificates、Python certifi、Node.js 與 Rust webpki-roots 均已釋出更新，Java 的 cacerts 更新狀態標記待查。
3. 檢查不使用瀏覽器撤銷機制的用戶端，例如嵌入式裝置、IoT 閘道器、API 客戶端與舊版行動 App，確認其信任庫是否能移除該根憑證。這類用戶端是本次事件風險最高的族群。
4. 可利用 Mozilla 提供的測試站台 emudhra.we-have-a-problem.com 驗證用戶端是否正確拒絕受影響的憑證鏈。

使用 Go 的開發與維運團隊

1. 將建置工具鏈升級至 Go 1.27.3 或 1.26.10。若仍在 Go 1.25 或更舊版本，需先規劃主要版本升級。
2. 重新建置並重新發布所有 Go 執行檔，包含自行開發的服務、CI 流程產出的 CLI 工具，以及以 Go 撰寫的第三方基礎設施元件。Kubernetes、Terraform、Docker、Prometheus 等常見工具均以 Go 開發，應追蹤各專案是否已釋出以修補版工具鏈建置的版本。
3. 檢查 go.mod 的 toolchain 指令與 CI 設定中的 Go 版本釘選，避免自動建置仍使用舊版。
4. 若有無法立即重新建置的 Go 服務，可在應用層以 VerifyPeerCertificate 回呼實作相同的 SPKI 雜湊過濾作為暫時措施，但應視為過渡方案而非替代升級。

emSign 訂閱戶

1. 立即向 eMudhra 或其他 CA 申請新憑證並安裝。Chrome Root Store v43 預計 10 月 27 日落地 Stable 版，屆時鏈至 G3 的憑證在 Chrome 會直接失效。
2. 使用 ACME 自動續期的服務需注意，標準 ACME 用戶端不會在續期窗口以外主動更換憑證，除非支援 ACME Renewal Information（ARI）或手動觸發。從 ECC 的 G3 階層改到 RSA 的 G1 階層，也可能需要調整用戶端設定。

金鑰管理的通用教訓

本次事件的根源在於金鑰產生儀式的腳本缺陷與人為誤用，而非 HSM 硬體或演算法本身。對任何自行營運 PKI 的組織而言，有幾點值得檢視。

產生金鑰後應以獨立工具驗證金鑰強度，至少排除低熵值或可預測的數值。儀式中的任何程序偏離都應有獨立的雙人覆核。CRL 或 OCSP 簽章驗證失敗這類異常，應視為金鑰管理可能出問題的訊號而非單純的設定錯誤，eMudhra 在 2025 年 6 月錯過的正是這個訊號。

待釐清事項與後續觀察

由於事件尚未結案，Bugzilla 上的 Bug 2083449 仍處於 ASSIGNED 狀態。Chrome Root Program 於 10 月 21 日在 Comment 30 提出 12 項追問，要求 eMudhra 回覆，其中幾項直指 eMudhra 的透明度與事件處理誠信。

對外溝通不足

Chrome 指出 eMudhra 雖已發布聲明頁與新聞稿，但兩者都沒有以名稱、序號或 SHA-256 指紋點名被移除的根憑證與受影響的中繼憑證，也沒有提供瀏覽器移除信任的時程，更沒有說明訂閱戶如何判斷自己是否受影響。emsign.com 網域甚至直接轉向 eMudhra 的產品頁，看不到任何公告。

2025 年 6 月的隱匿

Chrome 質問，eMudhra 在 2025 年 6 月調查 CRL 簽章失敗時，既然已發現簽 CRL 的金鑰與憑證內公鑰不符，並找到第二把金鑰重新簽署，為何只是把 CRL 修好，而不是停止營運、稽核為何同一場儀式會產生兩組金鑰並撤銷憑證。當時的事件報告也未揭露 HSM 內存在兩組金鑰、儀式曾偏離常規程序，以及簽發的憑證並不對應原本預期的金鑰。Chrome 進一步追問 eMudhra 是否曾通知 Sectigo 其交叉簽章的金鑰並非預期產生的金鑰。

A 系列為何被取代 ?

同一場儀式產生的 A 系列在 2025 年 5 月被撤銷並由 A-1 取代，eMudhra 從未說明原因。Chrome 要求釐清此事是否與同一套腳本或程序有關，若有關，為何當時沒有連帶檢查 B 與 C 系列。

根憑證層級的疑慮

研究者 Wayne 在 Comment 7 另外揭露，eMudhra 於 2026 年 10 月 14 日為 emSign Root TLS CA – G1 發布的第 11 號 CRL 簽章無效，且無法以 CCADB 內任何已揭露的 4096 位元 RSA 公鑰驗證。Chrome 因此追問，該 CRL 究竟是用哪把私鑰簽署的，以及 eMudhra 的 HSM 內是否對根憑證也存在多組金鑰對。eMudhra 在 2025 年 6 月曾承諾導入自動化的簽章後驗證並以自動化流程取代手動 CRL 簽署，Chrome 要求解釋為何這些控制措施未能阻止這次無效 CRL 的發布。

遷移進度與時程

Chrome 要求 eMudhra 提供依簽發 CA 細分的受影響訂閱戶數與憑證數、已完成遷移的數量、剩餘數量，以及 100% 完成遷移的預計日期。eMudhra 在 10 月 21 日的更新中提到將為所有企業 TLS 客戶提供來自另一家公開信任 CA 的備援憑證，Chrome 要求說明具體做法與時程。

截至本文撰寫時（10 月 22 日），eMudhra 尚未在 Bugzilla 回覆這 12 項問題。Google 已明言正在審視 eMudhra 其餘 CA 憑證是否繼續留在 Chrome Root Store，Mozilla 暫時保留 emSign Root CA – G1 的信任。eMudhra 剩餘根憑證的去留，將是後續最值得關注的發展。

延伸閱讀

Bug 2083449 – eMudhra: Private key compromise of Intermediate Certificates

Bug 1970728 – eMudhra: Invalid CRL signatures

Bug 2084101 – Remove eMudhra emSign Root CA – G3 from NSS

Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates，

[security] Go 1.27.3 and Go 1.26.10 are released

crypto/x509: mitigation for security concerns with a specific Certificate Authority · Issue #82345

crypto/x509: distrust a handful of intermediates · commit 7f86f95

Go Release History