資訊核查日期：2026 年 10 月 22 日，北京時間 適用對象：個人使用者、網站業者、開發人員及系統管理員
本次事件是 eMudhra/emSign 的一群中間 CA 私鑰因嚴重缺陷而可被恢復，影響透過公共憑證體系驗證網站、API 和軟體身分的用戶端。公共信任範圍跨越主流作業系統；真正失陷的金鑰範圍與客戶端的潛在影響範圍並不相同。 15
正文使用方括號編號對應來源，所有外部引用連結集中列在附錄。所列版本是截至核查日期已確認包含本事件修復的版本基線，部署時優先選擇同一受支援分支中更新的穩定版本。
TL;DR
結論：已確認失陷的是 8 個中間 CA 私鑰；現有通報不支援「根私鑰或整個 HTTPS 密碼體係被普遍破解」。需要更新的信任生態接近全局，是否仍有風險取決於特定應用。15
- **一般用戶：**更新瀏覽器、作業系統及安全元件；Android 同時更新 Google Play 服務。 Firefox Android 使用 158.0.2 或更新版本。 12
- **伺服器：**更新發行版的
ca-certificates/NSS，並檢查套用自帶的憑證庫；不能只更新宿主機。 7810 - 開發環境： 按需更新 Node 24 至 24.22.1 或更新版； Python 環境至少更新 pip 26.2.2 、 certifi 2026.10.19 、 uv 0.13.4 。 Go 程式需取得修復版二進位或重建； Java 按發行商公告更新。 12 – 15
- **部署生效：**重啟相關服務，重建並重新部署容器；使用 Cloudflare Tunnel 時更新 cloudflared 至 2026.10.2 或更新版。 7
- **網站憑證：**鏈中含被撤銷或封鎖的中間 CA、或被取消信任的根時，更換受影響憑證鏈；換證不能取代客戶端信任庫更新。 158
- **驗收：**逐個應用驗證其真實 TLS 路徑；憑證拒絕與逾時、DNS 失敗必須區分。保持憑證驗證開啟，不用
-k或跳過驗證來消除報錯。 7
1 事件事實與成因
已經確認的事實
Mozilla 與 Google 已確認 eMudhra 的 8 個中間 CA 私鑰有問題。研究者提交了私鑰控制證明，Mozilla 隨後獨立恢復私鑰，證實問題可以復現。其中 6 個中間 CA 用於 TLS，另 2 個用於程式碼簽章。 25
問題集中在金鑰產生結果：這些中間 CA 使用 P-384 橢圓曲線，私鑰卻全部是小於 256 的整數。這與正常從巨大範圍中安全隨機產生私鑰的要求相差極遠，因此恢復這些私鑰不能作為正常強度 P-384 已被攻破的證據。 2
這裡的「證書被破解」應準確地理解為「對應私鑰可被恢復」。憑證及其中的公鑰本來就可以公開；真正需要保密的是能夠產生有效簽署的私鑰。
仍在調查的生成流程問題
eMudhra 的初步說明將問題追溯到 2025 年 4 月的金鑰產生儀式。其解釋涉及一次密鑰封裝和解封裝步驟：在原本的強密鑰之外出現另一組弱密鑰，弱密鑰隨後被用於證書申請和簽發。公司仍表示準確根因尚未最終確認。 6
因此，能夠確定的是這些金鑰嚴重薄弱、已經失陷；不能把故障進一步寫成某款 HSM 的硬體隨機數源已經被證明有缺陷，也不能將其描述為 RSA、ECC 或 TLS 的普遍密碼學突破。
根證書取消信任的含義
瀏覽器或作業系統可以直接封鎖受影響中間 CA 的憑證或公鑰，也可以移除通往它們的根信任。後一種措施會連帶拒絕同一根下的部分合法證書。
Google 已安排移除 emSign ECC Root CA - G3，以保護不接收 CRLSet 更新的 Chrome 根庫使用者。根庫移除預計在北京時間 10 月 27 日至 28 日相應時段推送；Google 原文時間為 10 月 27 日美國太平洋夏令時間上午。這個計劃與先前已經部署的緊急公鑰封鎖是兩件事。 1
根被取消信任，是處置措施；它本身不能證明根私鑰失陷。
2 為什麼影響範圍接近全局
失陷範圍與信任範圍
| 判斷對象 | 本次事件中的範圍 |
|---|---|
| 已確認有問題的密鑰 | eMudhra 的 8 個中間 CA 私鑰 |
| 可能需要採取措施的平台 | 公共根庫、瀏覽器、作業系統、語言執行時間、軟體包和容器生態 |
| 可能被冒充的 TLS 身份 | 仍接受相關偽造憑證鏈的用戶端所造訪的網站或服務 |
| 是否代表所有設備已被入侵 | 不代表；信任條件、攻擊者網路位置和其他驗證策略共同決定能否利用 |
| 是否代表所有合法證書失效 | 不代表；連帶失效取決於客戶端取消信任了哪些根或憑證鏈 |
Red Hat 明確將利用條件限定為客戶端仍接受相關鏈、攻擊者持有失陷私鑰，並且能夠在網路中攔截連線。風險覆蓋面與已發生的攻擊數量不能混為一談。 10
網站使用其他 CA 也可能被冒充
假設一個網站真實使用 Let’s Encrypt 證書，而訪客的客戶端同時信任多個公共 CA。攻擊者可以嘗試利用失陷的中間 CA，為同一個網域製作另一張憑證。用戶端通常不會預先要求該網域永遠只能使用 Let’s Encrypt；如果偽造鏈仍被接受，網站真實使用哪家 CA 就不足以排除此類攻擊。 8
這個機製說明：更換原本正常的其他 CA 證書，並不會自動修復客戶端對失陷 CA 的信任。真正需要切斷的是客戶端接受偽造身分的路徑。
三種影響需要分別處理
**身份冒充風險：**尚未封鎖相關鏈的用戶端可能接受攻擊者偽造的身份，導致敏感請求被發送給冒牌服務。
**合法服務可用性風險：**移除根信任後，某些原本合法的網站也會出現憑證錯誤，需要移轉到另一條仍被接受的憑證鏈。
**部署遺漏風險：**作業系統已修復，但應用內建憑證庫、虛擬環境、舊容器鏡像或已編譯程式仍保留原來的驗證行為。
這三個範圍並不重疊。 Cloudflare 的處置涉及遠端身份驗證、共享信任庫、基礎鏡像和獨立應用，正體現了後兩類工作的獨立性。 7
3 受影響的 CA 與憑證供應商
提供者與影響類型
| 提供者或體系 | 本次事件中的角色 | 需要區分的邊界 |
|---|---|---|
| eMudhra／emSign | 直接發生中間 CA 私鑰失陷 | 不能把全部 eMudhra 根及全部證書都寫成已被破解 |
| Sectigo 相關交叉簽章鏈 | 為同一批受影響公鑰簽發了交叉證書，形成另一條信任路徑 | 需要封鎖對應交叉憑證或公鑰；未證明 Sectigo 根私鑰失陷 |
| Internet2/InCommon 的相關證書層級 | 部分合法證書依賴擬移除的 emSign ECC 根，涉及遷移 | 屬於根取消信任的連帶影響，不能算那 8 個弱密鑰中間 CA |
| Let’s Encrypt、DigiCert、Google Trust Services、GlobalSign 等 | 未被本次通報列為私鑰失陷方 | 合法憑證不會統一作廢；脆弱用戶端仍可能接受冒充它們所服務網站的假憑證 |
| CDN、雲端平台、證書經銷商 | 可能提供相關證書，或在連接來源站和 API 時使用公共信任庫 | 若要檢查實際憑證鏈與驗證器，不能只看平台或商品名稱 |
私鑰失陷與 Sectigo 交叉簽章情況請參閱 Mozilla 通知；Google 在公開事件追蹤中明確討論了 Internet2/InCommon 合法層級的遷移問題。 25 Cloudflare 發布修復則是服務和用戶端的信任處置，不表示其自身 CA 私鑰失陷。 7
TLS 憑證鏈與交叉簽名
以下關係僅說明這次 TLS 相關路徑，不包含程式碼簽章路徑，也不表示這些路徑在所有平台上目前仍被信任。 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ 受影響的 TLS 中間 CA 公鑰 → 為目標網域偽造的證書AAA Certificate Services→ 受影響的 TLS 中間 CA 公鑰 → 為目標網域偽造的證書
emSign Root TLS CA - G3 是 TLS 中間 CA 的直接簽發者之一，在部分信任庫中也可以直接充當信任錨；emSign ECC Root CA - G3 提供另一層交叉簽名信任。 Sectigo 的 AAA Certificate Services 為同一批中間 CA 公鑰形成另一條路徑。 17
因此，修復時有兩個不同粒度：
- **精確封鎖中間 CA 或其公鑰：**能保留同一根下其他正常層級，適合支援對應機制的驗證器。
- **取消根信任：**可以保護缺少中間 CA 封鎖能力的客戶端，但會產生相容性影響，並且需要覆蓋客戶端實際接受的其他路徑。 5
不應把「刪除所有 Sectigo/eMudhra 根」作為無差別通用步驟，也不應只刪除一個名稱相近的證書就認定所有路徑已經封閉。
4 作業系統與瀏覽器覆蓋狀況
主要平台
| 平台 | 已知處置情況 | 使用時應檢查的範圍 |
|---|---|---|
| Windows 與 Windows Server | Microsoft 已透過自動憑證信任清單更新分發封鎖 | 設備是否收到更新；獨立 CA bundle 不一定使用 Windows 的驗證路徑 |
| macOS、iOS、iPadOS 等 Apple 平台 | 事件協調者確認 Apple 已部署相關封鎖 | 不能保證每個舊版本和第三方應用程式都獲得相同覆蓋 |
| Android | Google 透過 Google Play 服務分發等值封鎖 | 無 Google Play 服務的 ROM 應依廠商公告核查；應用自帶驗證器另查 |
| Ubuntu | 已提供系統憑證包修復，包含多個當前和舊版本分支 | 舊版的 ESM 支援條件、容器內部憑證包及應用程式自備庫 |
| Debian 與 Devuan | Debian 已記錄 ca-certificates 修復 | 必須核對實際使用分支和已安裝包，不能照抄另一分支版本號 |
| RHEL 及衍生產品 | 官方列 RHEL 6、7、8、9、10，並涵蓋可能受影響的相關產品和鏡像 | 截至本次核查，公告尚未列出完整修復勘誤；「未找到更新」不能視為不受影響 |
| Fedora、Arch、Gentoo、Alpine 等 | 事件維護者已匯總相應修復記錄 | 按發行版、版本分支和鏡像獨立確認 |
| FreeBSD | 官方列出全部支援版本並提供系統信任庫修復 | 更新後按公告重啟相關守護程序；獨立應用信任庫另查 |
Windows 、 Apple 及發行版總結見 4 ； Android 見 1 ； Ubuntu 、 Debian 、 RHEL 、 FreeBSD 的發行方記錄分別見 8 – 11 。
停止支援的系統、離線設備、NAS、路由器和其他嵌入式環境，需要確認是否仍信任相關鏈，以及是否具備接收撤銷或軟體更新的管道。平台名稱本身不能取代對實際驗證行為的檢查。
瀏覽器保護與作業系統保護不同
Chrome 使用 CRLSet 分發緊急封鎖；Firefox 使用 OneCRL 等機制。 Firefox 也發布了包含封鎖資訊的版本，為沒有正常接收遠端設定的配置提供補充保護。 13
Firefox Android 的部分配置曾未在啟動時正確應用更新後的列表，Mozilla 已說明該問題由 158.0.2 修復。因此無法把早期 158.0.1 的狀態擴充到所有 Android Firefox 配置都已保護。 2
Apple 和 Windows 的系統驗證已採取措施，也不代表同機所有命令列程式均會走系統驗證。事件維護者特別提示了部分 macOS 內建工具使用獨立證書檔案的狀況；檢查時應記錄實際 TLS 後端和 CA 來源。 4
證書透明度的保護邊界
Google 確認，在其實施封鎖之前，這 6 個 TLS 中間 CA 沒有簽發已進入 CT 日誌的 TLS 憑證。因此，強制執行 CT 的 Chrome 用戶端具有額外保護。這個事實不能排除其他不執行 CT 的用戶端接受過未記錄憑證的可能性。 15
「原來能鏈到受信根」「有潛在利用條件」「已經發生攻擊」是三個不同判斷，不應互相取代。
5 開發環境與運行時修復基線
以下是已確認包含相應修復的基線，而不是要求長期固定這些版本。發行版可能透過回移補丁修復舊版編號，應同時查看其安全公告。
| 組件 | 已確認的版本或更新方式 | 部署注意事項 |
|---|---|---|
| Node.js 24 | 24.22.1 或同分支更新穩定版 | 包含根庫更新及對被封鎖公鑰鏈的拒絕；檢查服務實際使用的 Node 路徑並重新啟動 |
| Python certifi | 2026.10.19 或更新版 | 檢查每個實際運作環境；不能只更新全域 Python 下的一份包 |
| pip | 26.2.2 或更新版 | 單獨更新舊虛擬環境中的 pip，並複查新環境建立後的版本 |
| uv | 0.13.4 或更新版 | 依實際安裝方式更新工具副本 |
| Go | 1.27.3 或 1.26.10，對應分支更新版亦可 | 更新工具鏈後重建並部署相關程序，或取得供應商修復版二進位 |
| Oracle JDK | 對應受支援版本線的關鍵補丁 | 不同 JDK 發行商依各自公告處理；沒有適用於所有 Java 發行版的單一版本號 |
| Cloudflare Tunnel | cloudflared 2026.10.2 或更新版 | 更新正在運行的服務；容器部署需要替換鏡像並重新部署 |
| Cloudflare One／WARP | 平台對應的已修復客戶端版本或更新穩定版 | 客戶端與伺服器側措施分開確認，具體平台版本請見附錄 7 |
Node、Python、Go、Oracle 和 Cloudflare 的原始說明分別見13、12、14、15、7。
Python 的獨立憑證庫問題
Python 官方指出，舊 pip 會組合使用系統信任與內建 certifi。僅修改系統憑證庫，或為 pip 增加一個 CA 文件，並不能可靠排除其內建舊信任。因此，PIP_CERT、REQUESTS_CA_BUNDLE 或 --cert 不能作為舊 pip 的通用修復替代品。 12
更新後，應檢查既有虛擬環境；建立新虛擬環境時，也要確認實際產生的 pip 版本，避免舊的引導元件重新引入舊工具。進行首次升級時，可依 Python 官方公告提供的明確下載來源及 SHA-256 校驗步驟完成引導，再升級其他套件。 12
Go 與其他已編譯程序
Go 的修復改變了 crypto/x509 的驗證邏輯。 14 從部署機制來看，更新開發機上的編譯器不會重寫已經部署的二進位。若要獲得新的程式碼層封鎖，應重建並取代應用，或採用供應商提供的更新版本。舊程式是否也能受益於系統根庫更新，還取決於它實際使用的驗證路徑。
容器與打包應用
容器中的系統憑證包、應用程式依賴和運行時通常由鏡像內容決定。宿主機更新不等於鏡像內容更新；需要更新基礎鏡像和依賴，重新建置、部署並檢查實際執行實例。打包應用程式和自帶運行時的桌面程式也應按供應商發布管道更新。 710
6 修復實施說明
先確定檢查對象
建議為需要保護的服務記錄以下信息，再選擇對應修復路徑。這是部署檢查清單，不要求每個系統都存在全部元件。
| 專案 | 需要記錄的內容 |
|---|---|
| 應用與用途 | 瀏覽器、支付 API 用戶端、郵件傳送服務、下載工具、反向代理程式等 |
| 運行位置 | 宿主機器、容器、虛擬機器、桌面應用或行動設備 |
| 驗證實現 | 作業系統驗證器、OpenSSL、Node、Python 函式庫、Java 或應用程式自訂實現 |
| 信任來源 | 系統 CA 套件、certifi、JDK 信任庫、自備 CA bundle 或企業配置 |
| 修復狀態 | 已安裝版本、補丁來源、是否重新啟動或重新部署 |
| 驗收結果 | 受影響鍊是否被拒絕、正常業務連線是否成功、檢查時間 |
Cloudflare 的開發者指引特別指出，SDK 可能把驗證委託給其他元件；只更新最上層 SDK，不一定改變真正的信任策略。 7
作業系統與瀏覽器
**Windows：**啟用並確認自動憑證信任清單更新。受管理環境按既有策略分發；離線或停用自動更新的設備應使用相應管理流程落實封鎖。需單獨檢查不使用 Windows 系統驗證的程式。 4
**Apple 平台：**完成系統、安全元件和應用程式更新。對 macOS 上的開發工具另查其 TLS 後端、憑證檔案和安裝來源，不能僅憑 Safari 已拒絕測試鏈就判定整機完成修復。 4
**Android：**有 Google Play 服務的裝置應完成相關元件更新；Google 表示重新啟動裝置可以觸發即時更新。沒有該服務的設備，根據廠商或 ROM 公告處理，不將 Google 的覆蓋聲明直接套用到所有 Android 設備。 1
**Ubuntu/Debian：**使用支援的軟體來源更新憑證包，並核對對應發行版公告。例如，在使用 APT 的系統上可以針對性執行：
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificatesUbuntu 22.04、24.04、26.04、26.10 的相關更新屬於標準支援；更早版本應核對 ESM 支援和倉庫狀態。命令成功結束之後仍應比較公告中的修復包版本。 89
**RHEL 及相關產品：**依產品通路檢查憑證包及安全勘誤。版本檢查可用：
rpm -q ca-certificates使用支援的 DNF/YUM 更新機制取得供應商補丁；若通路尚未提供修復，不把「沒有可更新包」當成已安全。當需要暫時取消根信任時，採用廠商明確列出的措施，並評估合法業務憑證的兼容性。 10
**FreeBSD：**依官方安全公告更新對應系統分支，隨後重新啟動使用相關 OpenSSL 信任設定的守護程式或重新啟動系統。 11
應用與鏡像
在完成對應運行時和憑證依賴更新後，檢查服務實際運行的可執行檔路徑，避免終端機已切換新版本，而守護程式仍使用舊安裝目錄。對於多環境 Python、服務容器和自帶運行時的應用，應分別檢查。
對需要重新建置的元件，保存建置版本、依賴版本及部署鏡像標識。驗收物件是實際運作實例，不能只檢查建置機或鏡像倉庫中的新標籤。 71214
網站證書遷移
如果網站憑證鏈包含被撤銷或封鎖的中間 CA，或最終依賴被取消信任的根，應向提供者申請另一條仍被客戶端接受的憑證鏈，安裝完整的伺服器側鏈，並檢查所有入口，包括負載平衡器、反向代理、CDN 與直連源站。 15
是否需要遷移，以實際鍊為依據。僅按證書銷售品牌篩選，可能漏掉轉售或交叉簽名關係；僅等待常規到期續簽，也不一定能趕在根庫更新之前完成遷移。
對於其他 CA 簽發且不依賴受影響根的正常網站證書，不需要因為這次事件一律重籤。同時，網站伺服器本身呼叫外部服務時，仍應執行客戶端側的修復檢查。
7 驗證修復是否真正生效
版本檢查與行為檢查分別進行
版本檢查用於確認修補程式或已修復元件已部署；行為檢查用於確認應用程式實際使用了預期驗證路徑。兩個檢查解決不同問題，都不能被「更新指令執行成功」取代。
事件維護者提供了測試站點和憑證鏈材料，入口集中在附錄 4。應在目標應用程式的實際運作環境中驗證，並保持正常憑證驗證配置。 47
| 檢查結果 | 可以得出的結論 |
|---|---|
| 明確因為受影響鏈不受信任而拒絕 | 說明被測試的驗證路徑拒絕了該鏈 |
| 正常接受受影響鏈 | 表示這條路徑需要繼續修復或檢查配置 |
| DNS 錯誤、連線逾時、代理拒絕或服務不可達 | 不能據此認定證書風險已消除 |
| 瀏覽器拒絕，但應用程式呼叫未檢查 | 只能確認瀏覽器，不能代表後台程式 |
| 一條鏈被拒絕 | 仍需考慮客戶端是否接受另一條交叉簽章路徑 |
測試應同時覆蓋正常業務連接，避免透過移除過多信任造成業務故障後，誤把所有請求失敗視為修復成功。
建議的完成條件
- 受影響組件的更新來源和版本已記錄。
- 對應運行實例已完成重新啟動、重建或重新部署。
- 實際應用拒絕受影響鏈，且正常業務的 TLS 驗證繼續工作。
- 不存在為恢復連線而暫時關閉憑證驗證的設定。
- 如涉及網站憑證遷移，所有對外入口均已切換並驗證。
以上完成條件是針對本次處置的運維驗收建議；它不等同於證明設備沒有其他安全問題。
8 歷史 HTTPS 流量與風險邊界
三類密鑰用途不同
| 金鑰 | 主要用途 |
|---|---|
| CA 私鑰 | 將憑證中的身分與公鑰綁定進行簽名 |
| 網站私鑰 | 在證書認證的 TLS 握手中證明伺服器身份 |
| 會話金鑰 | 保護某條連線中實際傳輸的數據 |
取得 CA 私鑰，並不等於取得網站私鑰或所有會話金鑰。採用臨時金鑰交換、具備前向保密性的正常連接，不會僅因長期簽署金鑰後來失陷而自動暴露歷史會話。 TLS 1.3 的相關安全性屬性請參考 RFC 8446。 16
本次主要風險發生在身分驗證階段：如果用戶端接受了冒牌伺服器的證書，它可能與攻擊者建立本身仍加密的連線。 TLS 1.3 也需要可信任驗證；僅升級協定版本不能取代封鎖失陷 CA。
目前可以與不能作出的判斷
**可以確認：**特定中間 CA 私鑰已經失陷；相關公共信任路徑具有廣泛影響；主流平台和多個軟體生態已經採取處置。 145
**無法由此確認：**所有用戶已經遭遇中間人攻擊、其他 CA 私鑰也失陷、所有歷史 HTTPS 流量都可解密，或更新某個瀏覽器後整台設備所有應用程式都已獲得保護。
對特定服務的最終判斷，應基於其憑證鏈、驗證策略、實際運行元件和更新狀態，而不是僅看網址列是否為 HTTPS。
附錄 A 受影響中間 CA 名稱
以下名稱用於資產核查。名稱本身不能取代憑證指紋或公鑰標識；自動化比對時，應採用事件維護者或供應商提供的精確標識，並覆蓋交叉簽章憑證。 5
| 中 CA | 用途 | 關聯組織 |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | 程式碼簽名 | eMudhra BV |
| EM OV CS CA - G3C | 程式碼簽名 | eMudhra Inc |
TLS 與程式碼簽署的驗證器及撤銷機制並不完全相同。本文重點為 HTTPS/TLS；程式碼簽章環境應採用 Microsoft、JDK 或相關軟體供應商針對此驗證用途的處置，不將瀏覽器測試結果當作程式碼簽章驗收。 515
附錄 B 引用鏈接
以下來源皆於 2026 年 10 月 22 日核查。滾動公告可能繼續更新，正文中的狀態與版本應按本文件日期理解。
事件事實與平台處置
[1] Google Chrome 與 Android 官方公告 說明私鑰缺陷、SPKI 封鎖、Google Play 服務分發、CT 保護與 Chrome 根函式庫移除計畫。 Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 事件記錄 包含原始報告、獨立驗證、產生流程調查、Firefox Android 後續修復和合法證書遷移討論；重點可查評論 5、11、29、30。 eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox 安全公告 說明 OneCRL 緊急分送與後續 Firefox/NSS 處置。 Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] 事件協調者 Dennis Jackson 維護的匯總與偵測入口 提供平台與軟體修復狀態、測試入口、公共憑證鏈資料及 Windows／macOS 等環境的補充說明。测试结果仅代表实际被测验证路径。 eMudhra Intermediate CA Compromise
[5] Mozilla 發給發行版與信任庫維護者的通知 說明 6 個 TLS 與 2 個程式碼簽署中間 CA、Sectigo 交叉簽章、撤銷和根信任處理邊界，並列出精確憑證與公鑰標識。 oss-security eMudhra Intermediates Compromise
[6] eMudhra 官方事件聲明 提供廠商對密鑰產生流程的初步解釋；準確根因仍以完成後的調查結論為準。 eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare 官方事件與修正說明 涵蓋 WARP、Cloudflare Tunnel、來源站驗證、執行時間依賴、鏡像更新及驗證方法。 8 eMudhra certificates are compromised Here is what you need to know
作業系統與發行版
[8] Ubuntu 官方修復公告 列出各版本 ca-certificates 修復套件、支援管道和針對性更新步驟。 eMudhra CA compromise fixes available
[9] Debian 官方問題與修復記錄 應以維護者的修復記錄和對應發行版包為準，不把問題討論中的早期臨時建議當作最終方案。 Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat 官方安全公告 RHSB 2026 012 列出 RHEL 6 至 10、相關產品和容器影響，以及修復發布和臨時處置入口。 Certificate compromise eMudhra
[11] FreeBSD 官方安全公告 提供受影響系統分支、修復版本與服務重啟要求。 FreeBSD SA 26 73 caroot
運行時與協議
[12] Python 官方活動說明 提供 pip、certifi、uv 等修復基線，說明舊 pip 獨立信任庫問題，並給予 SHA-256 校驗的初始升級方式。 Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 官方發表 包含 NSS 根函式庫更新與拒絕包含被封鎖公鑰憑證鏈的變更。 Node.js 24.22.1 security release
[14] Go 官方安全發表 說明 Go 1.27.3/1.26.10 的 crypto/x509 憑證鏈過濾更新。 Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK 官方處置說明 說明 JDK 關鍵補丁與無法立即升級時的相關設定措施。 Distrusting eMudhra Intermediate Certificates in Oracle JDK
[16] TLS 1.3 協定標準 RFC 8446 請參閱附錄 E.1 等關於身分認證、臨時金鑰交換及前向保密性的說明。 The Transport Layer Security Protocol Version 1.3
[17] 事件相關根憑證與簽發關係資料 用於瞭解直接簽發者與交叉簽章關係；其中的根庫納入狀態不能取代客戶端最新撤銷或封鎖狀態。 Root certificate relationships JSON