10 月 26 日我們報導了 eMudhra 8 張中間憑證私鑰可被直接算出的事。之後兩週又有幾件跟站長直接相關的進展：Chrome 10 月 27 日把 emSign ECC Root CA - G3 移出根憑證庫，11 月 4 日又宣布限制另一個根 emSign Root CA - G1；Cloudflare 10 月 30 日公布了它觀測到的利用情況和修補進度；Debian 10 月 31 日從 NSS 裡刪了 3 個 eMudhra 根；Ubuntu 11 月 5 日發現系統憑證的刪除一直沒同步到 Java 金鑰庫。

Cloudflare 看到了什麼

  • 8 把私鑰弱到什麼程度：按 Cloudflare 的比喻，本該是一個 115 位的大數，其中一把實際是 4，其餘是 56、66、115、155、156、230 和 237。任何人都能從公開的憑證裡直接算出它們，然後給任意網域簽發憑證，沒打修補程式、也不強制憑證透明度的用戶端都會接受。
  • Cloudflare 在傳出連線上加了記錄（10 月 21 日部署完），一週裡看到約 22,000 次使用這些弱金鑰的 TLS 握手。三分之二是造訪測試網站，剩下的幾乎都是看起來由原始伺服器自己用弱中間憑證簽的憑證。約 160 次握手裡的憑證寫的是其他機構的網域，其中有的與消費級物聯網裝置有關；有一張偽造憑證的簽發時間是 10 月 20 日 18:19 UTC，離 Mozilla 公開事件單不到一小時。Cloudflare 說目前沒有證據顯示其連線被這些金鑰攔截。
  • 修補進度不樂觀：約 5000 萬次探測顯示，保持更新的新版瀏覽器大多已修好，但機器人流量和舊瀏覽器沒有；Android WebView 這類內嵌瀏覽器仍有 30%–40% 接受這條被攻破的憑證鏈；在大型網路裡，過半探測仍然接受它，而且第一個週末之後幾乎沒再下降。

瀏覽器和系統又做了什麼

  • Chrome：為了照顧不讀 CRLSet 的 Chrome 根憑證庫使用者，Google 把簽發這些問題中間憑證的 emSign ECC Root CA - G3 移出了根憑證庫，預計 10 月 27 日（太平洋時間）上午推到所有裝置。Google 說，憑證鏈到 G3 的網站必須立即申請並換上新憑證。
  • Chrome 11 月 4 日更新：鏈到 emSign Root CA - G1 的 TLS 伺服器憑證，只要最早的簽名憑證時間戳記（SCT）晚於 2026 年 11 月 16 日 23:59:59 UTC，Chrome 153 及以上預設不再信任；在此之前簽發的不受影響。
  • Java：Ubuntu 的 USN-9001-1 說，ca-certificates 和 Java 的整合一直有問題，從系統憑證套組裡刪掉的 CA 並沒有從 JKS 金鑰庫裡刪掉，也就是說跑在 Java 上的程式可能還信任 eMudhra。修復版本：22.04 是 ca-certificates 20260816ubuntu0.22.04.2 加 ca-certificates-java 20190909ubuntu1.4，24.04 是 20260816ubuntu0.24.04.2 加 20240118ubuntu0.24.04.1，26.04 是 20260816ubuntu0.26.04.2 加 20260311ubuntu0.26.04.1。升級後要重啟 Tomcat、Jenkins、Elasticsearch 這類 Java 服務才會生效。
  • NSS：Debian 的 DSA-6599-1 從 nss 裡刪除了「eMudhra emSign Root CA - G3」「eMudhra emSign Root CA - C1」「emSign ECC Root CA - C3」三個根，Debian 13 的修復版本是 2:3.110-1+deb13u5。用 NSS 做憑證驗證的程式（比如 Firefox、Thunderbird）靠的是這個套件。

別忘了自帶憑證套組的程式

很多程式不讀系統憑證，而是自帶一份：WordPress 10 月 28 日的 7.1.4 就更新了自帶的根憑證套組（見這篇），Python 的 certifi、Go 程式在 85 號報導裡講過。Cloudflare 的建議仍然是：升級完就測，報錯了也絕不要用關閉憑證驗證來「解決」。憑證透明度監控為什麼重要，見註冊局被劫持事件的報導；給自己的網站申請和續期憑證，見Let's Encrypt SSL 設定教學。