eMudhra 八張中繼 CA 私鑰可從憑證還原，瀏覽器已封鎖、runtime 要更新信任庫
Cloudflare Blog、emudhra.we-have-a-problem.com · 2026-10-20
eMudhra 的八張中繼憑證（intermediate CA）私鑰是被 CA 自己「錯誤產生」的，任何人都能從公開憑證直接還原私鑰，等於任何人都能替任意網域簽出受信任的憑證。這八張憑證都鏈到 Mozilla、Microsoft、Apple、Chrome 四大根憑證計畫收錄的根。Cloudflare 於 10 月 20 日公布處置，Mozilla 的 Dennis Jackson 同日開了測試與套件版本頁面。
漏洞機制
Dennis Jackson 的說明頁寫得很直接：中繼憑證的私鑰由 CA 錯誤產生，因此可以由憑證本身推回私鑰。他用八張中繼憑證各自的私鑰簽署訊息「We have a problem here - Wayne」作為證明，驗證用 openssl dgst 搭配 SHA-384。
金鑰演算法、長度與具體的產生缺陷，兩份來源都沒有寫，細節在頁面所連的 Mozilla bug 2083449，本文未取得。Cloudflare 的文章也只說這些金鑰「weak」，並表示其安全審查「has not identified active exploitation」。
頁面還提到這些憑證建立於 2025 年 4 月，且當時在 CT log 中沒有對應條目。換句話說，沒有人能靠 Certificate Transparency 發現它們被拿來簽發了什麼。
受影響範圍
被點名的例子是 EM-DV-TLS-CA-G3B，其餘七張列在頁面的 impacted-intermediates.json。頁面的 workaround 段提到兩個根：「Comodo AAA Services root」與「emSign ECC Root CA - G3」。
各端的封鎖時間不同：
- Firefox 與 Chrome：自 2026-10-17 起封鎖，機制為 OneCRL、CRLite、CRLSets。
- Apple 裝置：自 2026-10-19 起封鎖。
- 其他 client：需要軟體更新才會不再信任這些中繼憑證，這是最容易漏掉的一群。
瀏覽器能秒封，是因為它們有推送式的撤銷清單。後端服務、CLI、容器映像多半靠系統 CA bundle 或語言 runtime 內建的信任庫，沒有人推清單給它們，就會繼續信任這八張憑證。Cloudflare 也提醒，瀏覽器測試通過，不代表背景服務已受保護。
Cloudflare 的處置
Cloudflare 在 10 月 19 日約 17:00 UTC 得知，優先修補「用公開憑證驗證遠端端點」的服務，例如代理到源站、應用程式呼叫外部 API。共用信任庫與 base image 先更新，再 reload、restart 或重新部署；有自帶信任庫的應用另外評估。
| 時間（UTC） | 事件 |
|---|---|
| 10/20 02:00 | Cloudflare One Client 與 WARP 更新發布（iOS 待 App 審核） |
| 10/20 09:15 | cloudflared 安全更新發布 |
| 10/20 19:20 | CDN 與伺服器端 Zero Trust 緩解全數部署 |
Cloudflare 列出的修補版本包含 cloudflared 2026.10.2（容器部署需重新部署修正後的映像）、Cloudflare One Client 2026.8.2115.0（Windows、macOS、Linux）。
影響範圍：誰要檢查什麼
- 用 Mutual TLS 的團隊：檢查用來驗證 client 憑證的信任庫或上傳的 CA。
- 用 Full (strict) 或 Strict 模式的源站：檢查自訂源站憑證與伺服器設定，Cloudflare 計畫讓 Automatic SSL/TLS 通知仍用被撤信任憑證的客戶。
- 跑容器或 Sandbox 的人：檢查映像與相依套件裡的信任庫；啟用 HTTPS egress interception 的容器，遠端憑證驗證改由 Cloudflare 管理，已受保護。
- 開發者：確認實際的 TLS 驗證路徑，SDK 可能把驗證交給函式庫、runtime 或 OS；間接相依也要查。不要為了消除錯誤而關閉憑證驗證。
修補版本與緩解
Dennis Jackson 的頁面列出各套件的修補版本，以下摘錄常見者，其餘請看原頁：
| 軟體 | 修補版本 |
|---|---|
| NSS | 3.131.1 |
| Go | 1.27.3、1.26.10 |
| Python certifi | 2026.10.19 |
| Rust rustls-webpki | 0.103.16 |
| Alpine ca-certificates | 20261020-r0 |
| Electron | 44.9.1、43.8.1、42.11.16 |
| Node.js、Bun、Fedora、FreeBSD | 尚未釋出（pending） |
暫時無法升級時，頁面給了專家用的 workaround，做法是把兩個根從信任庫移除。以 Debian 與 Ubuntu 為例，在 /etc/ca-certificates.conf 把兩個根的條目前面加 !，再執行 update-ca-certificates。頁面註明這不建議一般使用者採用。
# Debian/Ubuntu：停用兩個受影響的根
# /etc/ca-certificates.conf 內，對應條目前加 !
update-ca-certificates驗證是否生效，可對 https://dv-g3b-emudhra.we-have-a-problem.com/ 與 https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ 發請求：看到憑證錯誤才是正確結果，表示 client 已不信任這些中繼憑證。順帶一提，macOS 的 /usr/bin/curl 使用的 /etc/ssl/cert.pem 尚未更新，也不檢查撤銷，頁面另有處理方式。
來源未說明的部分：金鑰缺陷的具體成因、eMudhra 的後續處理與是否有人實際濫用，本文不作推測。