2026年10月，認證機構 eMudhra 的中繼 CA 私密金鑰被發現極度脆弱，甚至可從公開資訊復原。攻擊者只要使用復原出的私密金鑰，就能偽造他人網域的憑證，因此這是一起動搖網際網路信任基礎的事件。
不過，要正確理解這起事件並不容易。若不了解 HTTPS 通訊的運作方式、PKI 的架構，以及憑證存放區保存在哪裡，就很容易把問題低估成「不就是讓釣魚網站更容易做而已嗎？把作業系統的根憑證刪掉不就好了？」之類的程度。
本文將先說明憑證的機制，再整理應用程式開發者應該檢查哪些地方，以及應該先處理什麼。
1. HTTPS 不只是「加密」而已
HTTPS 所使用的 TLS，除了能防止通訊被竊聽或竄改，也會對連線對象進行驗證。原因在於，通訊加密雖然能防竊聽，卻無法阻止中間人攻擊。必須確認「被加密後送出去的對象，真的是目標伺服器嗎？」。
用來做這個確認的，就是把網域名稱和公開金鑰連結起來的伺服器憑證。一般公開網站會驗證下列這樣的憑證鏈（certificate chain）：
| 憑證 | 角色 |
|---|---|
| 根 CA 憑證 | 作業系統或瀏覽器等預先信任的起點 |
| 中繼 CA 憑證 | 由上層 CA 在一定條件下委任簽發憑證的權限 |
| 伺服器憑證 | 將連線對象的網域名稱與該伺服器使用的公開金鑰連結起來 |
當瀏覽器存取網站時，Web 伺服器會送出憑證鏈的公開金鑰，以及基於伺服器憑證的通訊內容簽章。用戶端會從伺服器憑證一路追溯簽章到中繼 CA，再到受信任的根 CA。作業系統與瀏覽器都有管理憑證存放區的功能，當連到「已設定為信任」的憑證時，就會信任該連線伺服器。（不過實際上情況還要再複雜一些，後面會說明）
2. eMudhra 發生了什麼事
這個問題是在 2026 年 10 月 17 日 UTC，也就是日本時間 18 日被通報的。
內容指出，印度認證機構 eMudhra 所簽發的中繼 CA 憑證私密金鑰，可被第三方輕易復原。
對象共有 8 組中繼 CA 金鑰，其中 6 組用於 TLS，2 組用於程式碼簽章。
這些金鑰使用的是 P-384 這條橢圓曲線，但其私密金鑰對應的整數全部都小於 256。原本應該從 384 位元這個非常巨大的範圍中選出不可預測的值，實際上卻只有 8 位元的強度。只要比對公開金鑰，就能讓任何人輕易找出私密金鑰。
也就是說，並不是加密演算法本身被破解，而是因為使用了非常草率的私密金鑰生成方式，才導致這次的問題。
若拿這次的 TLS 金鑰來用，攻擊者就能替自己的公開金鑰，做出綁定他人網域名稱的憑證。對於信任該 CA、且在其他驗證中也不會拒絕的用戶端而言，這會看起來就像是正規憑證。
3. 真正的威脅不是釣魚攻擊
那麼，這個問題可能帶來什麼樣的攻擊呢？
能夠建立伺服器憑證時，最先想到的通常是釣魚網站攻擊。
一般的釣魚攻擊中，攻擊者會取得一個容易混淆的網域，然後建立假網站。
只要他管理那個網域，就能透過 Let’s Encrypt 等認證機構，依正常流程取得憑證。這種情況根本不需要用到這次受影響的中繼 CA 私密金鑰。
也就是說，這次真正變得危險的，不是「假網站也能掛上 HTTPS」這件事。而是攻擊者能在未經管理者許可的情況下，替真正的網域名稱建立憑證。
例如，使用者從書籤開啟正確的業務網站。攻擊者若把那段通訊導向自己的伺服器，並出示一張帶有真實網域名稱的偽造憑證，只要用戶端信任它，使用者即使輸入的是正確網址，也會與攻擊者建立 TLS 連線。畫面看起來完全一樣，瀏覽器也不會警告。如此一來，攻擊者就能在使用者毫無察覺的情況下竊聽通訊，或利用取得的工作階段不法存取業務應用程式。
不過，要讓這類攻擊成立，需要兩個條件：
- 透過竄改 DNS 回應或操縱路由等方式，將受害者的連線導向攻擊者。
- 偽造憑證能被受害者的 TLS 用戶端接受。
例如，攻擊者營運免費 Wi-Fi，並對 DNS 伺服器動手腳，或是在網路上設置特殊設備等，都能誘導或介入通訊路徑。
TLS 原本就是為了在通訊路徑被攻擊者操控時，仍能維持安全性而設計的機制。透過網路管理來降低介入機會，再由 TLS 在被介入時驗證連線對象，這是雙層防禦中的後一層；而這次在未修補的用戶端上，這一層可能被突破。
欄次：程式碼簽章也有另一種風險
本文主要討論的是 HTTPS 通訊的威脅，不過這次的對象也包含程式碼簽章用的中繼 CA。像 Windows 的 Authenticode 等機制，會透過簽章確認散布檔案的完整性與發行者。如果驗證環境信任了有問題的 CA，攻擊者就有可能用冒充發行者的憑證替惡意程式簽章。這屬於讓使用者或系統接受已散布檔案的攻擊，因此不一定需要介入網路路徑。
只是，程式碼簽章並不像 HTTPS 那樣高度標準化，不同作業系統或執行環境的驗證方式也不同。例如 .NET 套件管理用的 NuGet，在 Linux 上有時會使用 SDK 內附的程式碼簽章 CA 憑證束。不過，由於除了開發者簽章之外，也可能驗證儲存庫簽章，且使用者端也能設定要信任哪些簽章者，因此僅靠這次的中繼 CA 能成立的攻擊情境較為有限。
4. 只透過瀏覽器對策並不夠的原因
在這次弱點被發現之後，主要瀏覽器已迅速採取對策。
主要瀏覽器利用發送特定認證機構憑證拒絕清單的機制，封鎖了這次出問題的中繼 CA。只要有接收到這些更新的瀏覽器，即使不特別更新，也不會受到這次弱點影響。
然而，在瀏覽器之外的途徑，並沒有類似拒絕清單的機制。
作業系統的憑證管理工具可以查看目前裝置上被信任的憑證清單。
把這次出問題的根 CA 設為不信任，算是一種對策，但有些執行環境除了作業系統管理之外，還會另外保有自己的憑證存放區，因此光這樣還不夠。必須在所有進行 HTTPS 通訊的路徑上，都拒絕該中繼 CA 憑證。
另外，這次有問題的中繼 CA 憑證，除了 eMudhra 之外也有 Sectigo 的交叉簽章。因此還需要取消對 Sectigo 根 CA 的信任，但這也可能導致部分使用 Sectigo 發行伺服器憑證的網站無法連線。
5. 開發者應該檢查的範圍
那麼，應用程式開發者面對這次弱點，應該檢查什麼、怎麼處理呢？
大致可分成兩類：自己管理的成品與伺服器，以及自己的開發環境。
首先，若能依下列單位記錄「驗證器、參照存放區、更新方式、負責人」，就比較容易追蹤是否有遺漏。
| 檢查對象 | 需要確認的內容 |
|---|---|
| 正式伺服器、後端 | 連外 API 的函式庫、CA 存放區、自訂設定 |
| 容器、CI/CD | 基礎映像檔、Runner、建置工具、會隨成品一起散布的執行階段 |
| 要散布的桌面應用程式 | 內建函式庫、更新途徑、提供給使用者的修正版 |
| 雲端代理程式 | 供應商的對策、使用者指定的映像檔、套用到執行中環境的方式 |
| 本機開發環境 | 作業系統、多種語言環境、CLI、桌面應用程式、開發用容器 |
| 自家公開服務 | 所提示的憑證鏈，以及因取消根憑證信任而造成的連線障礙 |
在本機環境中，除了作業系統以外，還需要檢查像 Java 的 cacerts、Python 的 certifi 這類另外保存的 CA 資訊。若有多個 Python 虛擬環境，也可能各自存在套件。Node.js 也一樣，內建 CA 與系統 CA 的使用方式會依設定而定，所以不能只看語言名稱，而是要確認實際的使用路徑。
CLI 也相同。curl 會依建置時使用的 TLS 實作等因素，可能使用作業系統的存放區，也可能使用憑證檔案。Git 有 http.sslCAInfo，AWS CLI 有 AWS_CA_BUNDLE 等設定。要先確認是否已有修正版釋出，更新本機二進位檔，若使用自訂 CA 憑證束，也要一併更新。
像 Electron 這類網頁系的跨平台應用程式，會內建 Chromium 與 Node.js，因此 Chromium 端的通訊與使用 Node.js 的 https 等通訊會並存。就算更新 Chrome，或更新安裝在電腦上的 Node.js，也不代表散布中的應用程式內建的 Electron 會被替換，因此還是需要安裝修正版應用程式。
不過，Electron 本體雖然已有修正版釋出，並不代表每個桌面應用程式都已發行修正版。手動打補丁相當困難，所以一旦釋出就應盡快升級版本。
如果是用 Docker 容器進行開發，就需要確認容器內部內建的 CA。若 Dockerfile 是自己管理的，就必須在其中處理；如果使用公開映像檔，也要更新到已修正的版本。
只更新自己的電腦並不代表就結束了。若有營運 Web 應用程式，也必須檢查並更新部署目標伺服器，以及成品（應用程式套件或容器）內附的憑證存放區。甚至像 CI/CD 環境或雲端代理程式環境等產品供應鏈上的環境，也都需要檢查。
最後，最好執行必要的重新啟動與重新載入，確認實際應用程式使用的驗證路徑確實拒絕了目標 CA。這次有提供檢查用網站，但不能只確認瀏覽器打不開該網站而已，還應該確認各執行環境的路徑（如 curl、fetch、WebClient 等）也會拒絕該憑證。
6. 根據網路介入的可能性來決定優先順序
看到這裡，應該可以理解這次需要檢查的範圍有多大。若要在所有路徑上做到完整對策，會需要相當多的工時。在實際應對時，必須分出優先順序來處理。
要成功利用這次弱點，必須同時具備網路路徑導引，以及對出問題的中繼 CA 的信任。因此，最應優先處理的是會在不特定網路上運作的環境。相反地，如果是運行在可信任網路或 VPC 上的機器，則可以相對降低緊急程度。
不過，即使網路相對安全，仍然可能被 DNS 汙染等其他弱點組合利用，所以在關鍵任務領域，仍不能把處理往後延。
| 情境 | 優先順序的想法 |
|---|---|
| 在不特定網路上運作的桌面／行動應用程式或 IoT 裝置 | 開發方無法管理路徑，因此應優先提供修正版 |
| 會帶出公司外的開發端點 | 應優先限制連線環境，並更新 CLI 與應用程式 |
| 受管理的伺服器、CI/CD、雲端代理程式 | 應綜合判斷路徑管理狀態，以及對機密資訊、執行權限與散布的影響 |
7. 無法完全阻斷路徑時的暫時作法
像桌面應用程式這類，若使用者無法修改應用程式內部的驗證器，暫時性的對策就是減少通訊路徑被介入的機會。在使用尚未修補的應用程式進行重要通訊時，應避免使用管理者不明的 Wi-Fi，並盡量選擇受管理的網路，這可以提供一定程度的緩解。也應檢查家用或辦公室路由器，確認 DNS 與 Proxy 設定是否有可疑變更。
使用組織所管理的 VPN 等方式，也能作為一定程度的緩解。不過前提是，該應用程式的通訊確實會走那條隧道，而且 VPN 的連線對象驗證本身也必須是安全的。這並不代表能從 VPN 出口一路保護到後面；也不是只要多加一個 VPN 服務就會變安全。
VPN 用戶端本身也應列入檢查對象。實際上，Cloudflare 已提供對應這次問題的 WARP／Cloudflare One Client 更新。與其只說「有在用 VPN」，更應確認「那個 VPN 也已完成對策」。
當然，這只是等到對應版本釋出前的臨時措施。為了避免連線錯誤而停用憑證驗證，反而會適得其反。等到修正版提供後應立即套用，恢復對連線對象的驗證，這才是根本對策。
結論：建立信任容易，撤銷信任卻難上一百倍
這次出問題的不是 TLS 的加密方式本身，而是認證機構的金鑰太弱，導致驗證連線對象的前提被破壞。對能操控通訊路徑的攻擊者來說，這就成了突破原本無法通過的驗證的方法。
瀏覽器已透過快速發送拒絕資訊完成對策，但執行階段、CLI、容器、桌面應用程式與雲端代理程式，各自都有不同的驗證器與更新途徑。因此，不能只因為更新了作業系統內建的憑證存放區，就認定事情已經完成。必須盤點實際使用中的信任存放區，並優先處理那些無法管理網路的軟體，把修正送到實際運作環境中。
這次事件揭示了認證機構基礎設施的本質弱點：新增一個信任對象很容易，但一旦賦予的信任要撤銷，就需要非常繁複的作業。
參考資料
- Mozilla Bugzilla #2083449 — eMudhra: Intermediate 憑證的私密金鑰遭到入侵
- eMudhra — 關於近期憑證安全事件的聲明
- Mozilla — 在 eMudhra 中繼憑證遭入侵後，保護 Firefox 使用者
- Electron — GHSA-jr5w-w6x2-84p9：針對遭入侵的 eMudhra 中繼憑證之緩解措施
- Dennis Jackson 等人 — eMudhra 中繼 CA 遭入侵
- Google — 保護 Chrome 與 Android 使用者免於受遭入侵的 eMudhra 中繼 CA 憑證影響
- Oracle — 在 Oracle JDK 中取消信任 eMudhra 中繼憑證
- Sectigo — 關於遭入侵的 eMudhra 中繼憑證之公告
- Cloudflare — 8 張 eMudhra 憑證遭入侵。你需要知道的事
- Node.js — 2026 年 10 月 21 日星期三安全性更新
- Go — GO-2026-6809 / CVE-2026-111943
原文出處：https://qiita.com/autotaker1984/items/ef99b5791fe799a4ca66
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
