10 月 17 日 20:06（UTC），Mozilla 收到一份由 Chrome 根憑證計畫轉來的報告：印度憑證機構 eMudhra 的 8 張中間憑證私鑰已經洩露，報告附上了全部 8 把私鑰的控制證明。21:48，Mozilla 在不知道報告人方法的情況下自己也還原出了這些私鑰——按 Mozilla 在事件單（Bugzilla 2083449）裡的說明，這 8 把 P-384 私鑰的數值全都小於 256，幾乎全是零，瞬間就能算出來。8 張裡 6 張是 TLS 中間憑證，受 Chrome、Mozilla、微軟、蘋果四大根憑證計畫信任；另外 2 張用於程式碼簽名，受微軟信任。這些金鑰來自 2025 年 4 月 30 日的一次金鑰生成儀式。
時間軸
- 10 月 17 日：Firefox 在 22:59（UTC）透過 OneCRL 完成攔截。
- 10 月 18 日：09:38（UTC）eMudhra 吊銷了這 8 張憑證（原因 caCompromise）。eMudhra 說這些中間憑證沒有簽發過終端憑證；但私鑰既然誰都能算出來，任何人都可以用它們偽造任意網域的憑證。
- 10 月 20 日：Mozilla 宣布緊急撤銷對根憑證 emSign ECC Root CA - G3 的信任，為的是保護那些不檢查吊銷資訊、或者沒辦法單獨封鎖某張中間憑證的用戶端；Chrome 根憑證計畫同日表示走同樣的路。eMudhra 當天停止從這個根下的所有中間憑證簽發，並估計約 3 萬張憑證需要遷移，其中約 97% 是透過 ACME 簽發的。
- 10 月 22 日：eMudhra 宣布，董事會決定主動退出全球 SSL/TLS 憑證業務。
為什麼伺服器要自己動手
瀏覽器有快速吊銷機制，撥一下開關就能攔住。伺服器上的程式不一樣：curl、wget、Python、PHP、Node、Java、Go 發起 HTTPS 請求時，大多依賴系統信任庫或者自帶的憑證包，瀏覽器更新對它們沒有任何作用。Cloudflare 10 月 20 日的說明裡專門提醒：更新 SDK 不一定改變底層的驗證策略，要看它最終用的是哪個信任庫；打完修補程式後看到憑證報錯，千萬不要用關閉憑證驗證的辦法來消除。
VPS 上要做的事
- Ubuntu：10 月 20 日的 USN-8944-1 從 ca-certificates 裡刪除了 emSign ECC Root CA - G3，22.04 的修正套件是
20260816ubuntu0.22.04.1，24.04 是20260816ubuntu0.24.04.1；10 月 21 日的 USN-8947-1 同時更新了 NSS，刪除這個根和「Comodo AAA Services root」。 - Debian：DSA-6572-1 刪除同樣兩個根，Debian 13 是
20250419+deb13u1；Debian 12 是 DLA-4845-1，20250419~deb12u2。 - 升級後執行
ls /etc/ssl/certs | grep -i emsign_ecc_root_ca_-_g3，沒有輸出就說明這個根已經不在系統信任庫裡了。 - 自帶憑證包的程式要單獨升級：Python 的 certifi 從
2026.10.18版起不再包含這個根（我們逐個版本核對過包裡的憑證檔案）。Go 程式在 Linux 上預設用系統信任庫，升級 ca-certificates 就覆蓋了大部分情況；為了兜住少數系統信任庫沒有更新的情形，Go 在 10 月 19 日發布的 1.26.10 / 1.27.3 裡給 crypto/x509 加了黑名單（GO-2026-6809 / CVE-2026-111943），自己編譯的 Go 程式建議用新版本重新編譯。Docker 映像裡也有自己的 ca-certificates，要重建映像、重啟容器，見 VPS 上的 Docker 入門。 - 改完要重啟相關服務，已經在執行的程序不會重新載入信任庫。
這件事和大多數站長自己的憑證沒有直接關係：你用的如果是 Let's Encrypt 或其他 CA，憑證不需要更換，設定方法見 Let's Encrypt SSL 憑證設定教學。但它再次說明，防範偽造憑證要靠多層手段，.gh、.sl、.as 註冊局被劫持那篇講過的 CT 監控和 CAA 記錄在這裡同樣適用。