中間憑證（Intermediate CA）出包的事，這幾年不算少見；但上個月 eMudhra 的事件還在發酵，這個月又多了一筆：原本被官方說「不受影響」的另外 8 張中間憑證，也在 2026 年 11 月 7 日被撤銷了。
這 8 張的私鑰沒有被削弱，為什麼還是被撤？官方的說法是「無法證明處理過程合乎自家規範」。
我們來看看這次多撤銷了哪些、當初為什麼說沒事、現在為什麼改口，以及對你有沒有影響。
前情提要
2026 年 10 月，eMudhra 有 8 張 ECDSA P-384 中間憑證的私鑰被發現小到可以直接猜出來，Google 與 Mozilla 隨即在 Chrome、Firefox 封鎖這幾張憑證，eMudhra 之後也宣布退出公開 SSL/TLS 憑證市場。事件的來龍去脈、白話解釋和一般網站該怎麼看，我在這篇寫過：SSL/TLS(HTTPS)憑證爆資安危機——嚴重評級「重度」之後真的是「印度」?!
這篇只講後續，前面講過的細節不再重複。
這次又撤銷了哪些 CA
eMudhra 在 2026 年 11 月 10 日於 Mozilla 的 Bug 2083449（comment 82）貼出完整事件報告，把兩批合起來看，共 16 張受影響的下級 CA 憑證：
| 批次 | 金鑰類型 | 憑證名稱 | 撤銷日期 | 撤銷原因代碼 |
|---|---|---|---|---|
| 第一批（10 月事件） | ECDSA P-384 | G3B、G3C 各 4 張（DV、EV、OV TLS 與 OV Code Signing） | 2026-10-18 | caCompromise |
| 第二批（這次新增） | RSA-4096 | G2B、G2C 各 4 張（DV、OV、EV TLS 與 OV Code Signing） | 2026-11-07 | cessationOfOperation |
第二批共 8 張，名稱如下：
| 用途 | 憑證名稱 | 簽發者 |
|---|---|---|
| TLS | EM DV TLS CA – G2B、EM DV TLS CA – G2C | emSign Root TLS CA – G1 |
| TLS | EM OV TLS CA – G2B、EM OV TLS CA – G2C | emSign Root TLS CA – G1 |
| TLS | EM EV TLS CA – G2B、EM EV TLS CA – G2C | emSign Root TLS CA – G1 |
| Code Signing | EM OV CS CA – G2B、EM OV CS CA – G2C | emSign Root CS CA – G2 |
資料來源：eMudhra 在 Bug 2083449 comment 82 附錄 C，序號與 SHA-256 指紋請見原文。
這次的撤銷原因代碼是 cessationOfOperation（停止營運），不是 caCompromise（CA 私鑰遭洩漏）。報告也說明，這批 RSA 金鑰的完整性沒有問題，簽章都能通過驗證。
為什麼之前說不受影響
當初的說法
事件剛爆發時，eMudhra 在 Bug 2083449 的 comment 11 表示 RSA 簽發者走的是不同的路徑，依他們對程式碼的評估，不受影響。後來有人在 comment 58 引用這句話，追問這條「不同的路徑」到底是什麼，當時討論串裡還沒有說明。
為什麼改口
2026 年 11 月 2 日，eMudhra 在 comment 73 承認，先前的回答是依內部團隊「當時能蒐集到的資料」所做的分析，並表示已委託 KPMG 做獨立審查，完整報告延到 11 月 9 日。
11 月 10 日的完整報告（comment 82）把來龍去脈講清楚了，白話整理如下：
| 項目 | 重點 |
|---|---|
| 起點 | 2025 年 4 月 30 日同一場儀式產生 16 組 B、C 系列金鑰；為了搬到另一個地區、不同廠牌的硬體安全模組（HSM），多跑了一道自寫 Python 腳本的包裝／解包裝步驟 |
| ECDSA 那 8 把（G3B、G3C） | 腳本讀回私鑰時出錯，私鑰被截得太短，小到能從公開資訊反推 |
| RSA 那 8 把（G2B、G2C） | 金鑰本身沒壞，但重新匯入時，私鑰內容曾經出現在主機的程式記憶體裡，離開了 HSM 的保護範圍 |
| 為什麼還是撤 | eMudhra 自家 CPS 第 6.2.6 節規定私鑰進出硬體模組要受控；事後翻不出紀錄能證明私鑰沒外流，eMudhra 選擇當作不合規處理 |
| 什麼時候發現 | RSA 這批是 2026 年 11 月初，根憑證計畫（root program）追問 6.2.6 節時才重新檢視 |
eMudhra 強調 HSM 本身沒故障，出問題的是主機端腳本和流程管控。這是 eMudhra 單方說法，KPMG 的獨立審查結果還沒公布。
對網站管理者與一般使用者的影響
一般使用者
報告中說這 16 張下級 CA 憑證已全部撤銷，且 ECDSA 那批與 RSA 的 G2B 那批沒有簽發過任何終端憑證，直接受影響的是 G2C 這幾張簽發出去的 TLS 與 Code Signing 憑證。eMudhra 表示 G2C 撤銷後的用戶遷移已經完成。
如果你只是上網瀏覽，保持瀏覽器和作業系統更新即可，沒有需要另外動手的設定。
網站管理者
報告指出，這批 G2C 簽發者從 2026 年 5 月起上線，簽出去的 TLS 與 Code Signing 憑證名單在 comment 83 的附件（affected_certificates_G2C.xlsx）；也可以到憑證透明度（Certificate Transparency）紀錄裡，找簽發者是 G2C、還沒過期的憑證。
簡單的自我檢查：
| 檢查項目 | 做法 |
|---|---|
| 看憑證簽發者 | 瀏覽器查看憑證詳細資料，簽發者若是 EM DV／OV／EV TLS CA – G2B 或 G2C，或 emSign 相關名稱，建議找簽發的廠商確認 |
| 看憑證鏈 | 確認憑證鏈沒有經過已撤銷的中間憑證 |
| 準備替換 | eMudhra 已宣布退出公開 TLS 市場，後續需要新的憑證供應商 |
emSign Root CA – G1 底下的憑證也有期限
| 日期 | 誰 | 內容 |
|---|---|---|
| 2026-11-16 23:59:59 UTC | Chrome | Google 在 Chrome 官方部落格 11 月 4 日的更新寫明：Chrome 153 以上版本，不再預設信任最早憑證時間戳記（SCT）晚於這個時間、串到 G1 的 TLS 憑證；這之前簽發的不受影響 |
| 2026-11-16 | Firefox | eMudhra 事件狀態頁 Update 8 說 Firefox 比照 Chrome |
| 2026-11-30 | Apple | 同樣是 eMudhra 狀態頁的說法：Apple 移除 G1，底下的憑證不管何時簽發都不再被信任 |
Firefox 與 Apple 這兩列，截至撰稿時尚未在 Mozilla、Apple 的官方資料找到說明，有需要的話可以到 Mozilla CA Certificate Program 與 Apple 根憑證計畫 查詢最新公告。
eMudhra 在完整報告中也提到，G1 底下目前主要服務北美的一個大學聯盟，正轉給其他公開信任的憑證商，G1 的所有簽發會在 11 月 16 日前停止。
站長觀點
這次的重點不是哪一把金鑰被破解，而是「說沒事」的依據後來被推翻。從 10 月 19 日的說法到 11 月 10 日的完整報告，中間有三週多，期間討論串裡有不少人反覆追問 RSA 那批的處理路徑。
如果你的網站用的是 eMudhra 或其代理商的憑證，現在就是盤點、換發的時間，不用等到信任被移除那天才動作。
參考資料與延伸閱讀
- 後續報導：eMudhra Revokes 8 More CAs It Previously Declared Unaffected by Key Compromise（The Hacker News）
- 第一手來源：Mozilla Bugzilla Bug 2083449 – eMudhra: Private key compromise of Intermediate Certificates（comment 10、11 為先前說明，comment 73 為改口與延期，comment 82 為完整事件報告）
- eMudhra 官方：eMudhra Statement on Recent Certificate Security Incident
- Google 官方：Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
- 前情：SSL/TLS(HTTPS)憑證爆資安危機——嚴重評級「重度」之後真的是「印度」?!
發佈留言