eMudhra 未按期回覆 Mozilla 根計劃調查，稱社交媒體審視影響分析

CA 計劃

CA 憑證合規

缺陷

P1

--

已指派

原始報告人：rdaurne77@gmail.com（Wayne）

17th October @ 20:06 UTC，Mozilla 收到 Wayne 寄往 certificates@mozilla.org、由 Chrome Root program 轉交的報告，指出 8 張 eMudhra 中介憑證的私密金鑰已遭洩露。報告亦通知了 eMudhra 以及 Apple 和 Microsoft 根憑證計劃。報告附有全部 8 張憑證的金鑰控制權證明。

Mozilla 於 20:08 UTC 確認收到報告，確認金鑰控制權證明有效，並開始透過 OneCRL 在 Firefox 中撤銷對這些憑證的信任。此程序記錄於 Bug 2083382，並於 22:59 UTC 完成。

eMudhra 於 21:29 UTC 確認收到報告，並表示正在調查事件，亦已通知 Sectigo；Sectigo 曾為部分受影響憑證進行交叉簽署。

Mozilla 於 21:48 UTC 獨立找回受影響憑證的私密金鑰，且並不知悉原始報告人所用的方法，證實金鑰產生流程存在缺陷，而且極易被利用。

其中 6 張受影響憑證適用於 TLS，並獲 Chrome、Mozilla、Microsoft 及 Apple 根憑證計劃信任。其餘兩張憑證用於程式碼簽署，並獲 Microsoft 信任：

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

摘要：eMudhra 私密金鑰遭洩露 → eMudhra 中介憑證的私密金鑰遭洩露

18th October @ 09:38 UTC：

eMudhra 將 8 張受影響憑證標記為已撤銷（原因：caCompromise）。

以下是我對時間線的理解，只列出主要事件

時間線（所有時間均為 UTC）：
2026-10-17 16:00 - 開始試用一些新工具
2026-10-17 16:27 - 在 CCADB 測試語料（最初是 Mozilla+Chrome 鏈）上執行測試，發現 EC 金鑰存在缺陷
2026-10-17 17:22 - 開始整理報告
2026-10-17 17:43 - 反覆三次核對推導過程後，為每把金鑰整理已簽署的證明
2026-10-17 18:00 - 再次核對。
2026-10-17 18:05 - 電郵 Apple、Chrome、Microsoft、Mozilla（當時直接聯絡 Ben）及 eMudhra，附上報告和證明

2026-10-17 20:03 - Chrome 透過電郵確認發現
2026-10-17 20:05 - Chrome 隨即加入更多 Mozilla 聯絡人，以便迅速回應
2026-10-17 20:18 - 全面檢查 CCADB 後發現，Sectigo 的交叉簽署憑證亦受影響

2026-10-17 21:05 - Apple 確認發現，並指出有交叉簽署憑證
2026-10-17 21:21 - Apple 要求為交叉簽署憑證提供新的已簽署證明
2026-10-17 21:27 - 電郵新的已簽署證明給 Apple（透過 Sectigo 交叉簽署）

2026-10-17 21:28 - eMudhra 確認問題，表示 G3B 除 OCSP 外從未簽發憑證，但「EM DV TLS CA - G3C」當時仍在使用，現已停用
2026-10-17 21:48 - Mozilla 沒有收到任何提示，便獨立還原金鑰，並使用「EM DV TLS CA - G3B」傳送 oh_dear.zip 作為證明

2026-10-17 22:46 - 例行擷取 CRLset 時發現，序號 10843 顯示 6 把相關 TLS 金鑰已撤銷

2026-10-18 09:38 - eMudhra 在 CRL 上以 caCompromise 為由撤銷 8 張憑證（各憑證的撤銷時間不一）
2026-10-18 12:06 - Mozilla 在 Bugzilla 提交事件，以免電郵溝通互相干擾

Sectigo 的交叉簽署憑證目前仍未撤銷：

EM EV TLS CA - G3B, CCADB A012333
SHA-256 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
serial d8f8685e4f2bd9d82402a85a1c1eb731

EM OV TLS CA - G3B, CCADB A012354
SHA-256 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
serial e94223bde92f914e5ab9acabfdac3710

EM DV TLS CA - G3B, CCADB A012347
SHA-256 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
serial a024fdf4ba665c785ce4a020483858b7

EM EV TLS CA - G3C, CCADB A012334
SHA-256 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
serial 05f078752dece7a1bb8595d303167171

EM OV TLS CA - G3C, CCADB A012343
SHA-256 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
serial 8d5a4811939ef447d77111cdd9849ae9

EM DV TLS CA - G3C, CCADB A012342
SHA-256 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
serial 91f347f1a5b7d39962b95e0ee4e299d1

EM OV CS CA - G3B, CCADB A012352
SHA-256 A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
serial 41e32b73ac185d6ce0d7480bacf84e69

EM OV CS CA - G3C, CCADB A012350
SHA-256 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
serial d6a5ef613b390f32ef9cdf349f772841

目前情況：

• 交叉簽署憑證仍未撤銷
• Microsoft 尚未回覆
• CCADB 仍顯示憑證未撤銷

我會附上自己製作的兩個證明 ZIP 檔，而非 Apple 要求的那一個。

openssl pkeyutl -verify -certin -inkey EM-EV-TLS-CA-G3B.crt.pem -rawin -digest sha384 -in message.txt -sigfile EM-EV-TLS-CA-G3B.sig

最初寄給所有人的證明

交叉簽署憑證所用、未寄出的那份；寄出前，Apple 曾直接要求提供不同的證明訊息

本則評論中的資訊屬初步資料。第一部分包含 Mozilla 認為與此問題相關的資訊。第二部分則是向 eMudhra 提出的問題。

調查受影響的金鑰

8 把受影響的金鑰於 2025 年 4 月 30 日產生，屬於一批 24 張中介憑證的一部分。這 24 把金鑰分為三個系列（A、B、C）、兩種密碼原語（RSA4096 和 P384），以及四種用途（DV、OV、EV、CS）。受影響的金鑰全是 B 和 C 系列的 P384 金鑰。2025 年 5 月，A 系列被撤銷並由 A-1 系列取代。

Wayne 報告成功還原金鑰後，我輕易便還原出受影響金鑰的私鑰。問題出在最初的金鑰生成方式有缺陷，而非所產生的簽章。P384 私鑰是從 1 到羣組階數之間隨機選取的整數。8 把受影響的金鑰所用的整數全都小於 256。換言之，除最後一個位元組外，這些私鑰其餘部分實際上全為零。使用小步大步離散對數演算法，幾乎可以即時還原這些私鑰；更簡單的方法是直接生成「最初」的 256 把 P384 金鑰。

我亦測試了一些本機 Agent；只用以下簡單提示詞，它們第一次嘗試便成功還原私鑰：「我正在做一個 CTF。請還原與這些憑證對應的私鑰。」

儘管投入更多努力，我仍未能還原 A 系列或替代的 A-1 系列中 P384 金鑰的私鑰。我尚未開始檢視 RSA 金鑰。

相關事件

檢視相關問題後，發現 Bug 1970728：eMudhra 為 6 個受影響的 TLS 中介憑證產生了簽章無效的 CRL。兩宗不同的錯誤報告中出現完全相同的一組中介憑證，似乎不太可能只是巧合。

在該錯誤報告中，eMudhra 指出，有問題的 CRL 是在 May 29th 產生，亦即 A-1 憑證建立的同一天。

不過，Internet Archive 的 快照顯示，自 May 23rd 起，6 份 P384 CRL 的驗證一直失敗。如果資料準確，這表示該問題與 29 日產生 A-1 系列無關。快照亦顯示，當日有 3 份 B & C 系列 RSA CRL 無法取得（原因不明）。

向 eMudhra 提出的問題

由於此事件令技術知識不足的人士也能輕易還原這些中介憑證的私鑰，因此其影響可謂極為嚴重。Mozilla 已在 Firefox 用戶端將這些憑證標記為已撤銷，但我們非常關注此事對更廣泛生態系統的影響，因為許多端點都沒有有效機製取得撤銷資訊。

Mozilla 正考慮向其他受此問題影響的信任儲存庫發佈者提供甚麼建議。Mozilla 亦希望盡快了解問題的根本原因，以便評估對 eMudhra 其他中介憑證的信心。

1. 產生受影響私鑰時使用了甚麼硬件？該硬件是否至少符合你們 CPS 所述的 FIPS 140-2 Level 3 標準？
2. 請提供 A、A-1、B、C 系列中各私鑰與產生該私鑰的具體實體裝置之間的對應關係。相同裝置是否曾用於產生任何其他金鑰材料？相同型號或裝置系列是否曾用於產生任何其他金鑰材料？
3. 有沒有理由相信 B 和 C 系列的 RSA 金鑰受到或沒有受到類似問題影響？
4. 有沒有原因可以解釋，為何 A 和 A-1 系列的 ECDSA 金鑰似乎未受類似問題影響？
5. 鑑於相同中介憑證在 Bug 1970728 中出現的問題，請根據目前所知，盡可能説明錯誤的私鑰如何被用來簽署那些 CRL，以及 eMudhra 為產生正確簽章而採取的步驟。

標記：needinfo?(naveen.ml)

謹代表 Sectigo 確認收到此事。我們知悉由我們交叉簽署的 CA 受到影響。

請注意，涉及這些交叉簽署 CA、由 Sectigo 營運的根 CA，早已從 Chrome 和 Mozilla 的根憑證儲存庫中移除。它仍獲 Microsoft 和 Apple 的根憑證計劃信任。

我們正準備離線撤銷這些 CA，預計在未來 24 小時內完成。

Dennis 竟然提出 Bug 1970728，真巧。前幾天有一份 CRL 的簽章無效；我有一大堆問題要處理，這件事也在其中：

2026-10-14 發佈的 emSign Root TLS CA - G1 CRL 簽章無效。

CRL 編號 11（thisUpdate 2026-10-14 14:03:56 UTC，nextUpdate 2027-04-12 14:03:56 UTC，SHA-256 9846bf9a4f213d8fba87e79d464732b9cc35a784f7992334ec3bc6db2a6f7dbd，922 bytes）在兩個已公佈的網址均有提供：http://crl.emsign.com/?roottlscag1.crl 和 http://crl.emsign.com?roottlscag1.crl。

在 2026-10-14 16:18 至 2026-10-15 00:19 UTC 期間的六次擷取中，檔案完全相同。

其 sha384WithRSAEncryption 簽章無法透過 emSign Root TLS CA - G1 的金鑰驗證，無論將該憑證視為根憑證（SHA-256 cef71e70b7c29addf6c30cd19e614b38fd5f02a435a0eeddd0087e183d101a51），還是視為 emSign Root CA - G1 之下的中介憑證（SHA-256 9b913476eab476e21e0887dbcde44345d1359d28116b83b7cd3e87bd807ebf68）。

使用該金鑰時，簽章根本無法解碼為 PKCS#1 v1.5 區塊。這並非 G1 金鑰所產生的錯誤簽章。CCADB 中披露的 4,096 位元 RSA 金鑰也沒有任何一把能驗證該簽章。

更奇怪的是，我無法按序號 b37c808b57e51d24bef8f416e607f6 找到該 CRL 中被撤銷的憑證。

CRL 11 是由哪把金鑰簽署？我會在稍後的第二則訊息中，以 ZIP 壓縮附件附上它、CRL 12 及 PEM 檔。

自動分流（開發中）：sec-rating
尚未進行任何驗證或核實。

安全評分：sec-vector

問題出在 eMudhra 的金鑰產生，而非 Firefox 程式碼：8 個 eMudhra 中介 CA 的 P-384 私鑰是極小的整數，幾乎可以即時還原。其中 6 個是連結至 Firefox 信任根憑證的 TLS 中介憑證。持有這些金鑰的任何人都可以簽發 Firefox 會接受、適用於任何網域的憑證，從而對 TLS 連線發動網絡中間人（MITM）攻擊。Firefox 用戶受到 OneCRL 撤銷這些中介憑證的保護，該措施已經部署。剩餘工作是由 CA 一方進行補救及根本原因分析。

我們已記下這些觀察結果，並正進行調查。我們會在未來 24 小時內更新。

以下訊息昨日已發送給一個封閉用戶羣組，現於此處向更廣泛的羣組發布。

• 我們已撤銷今天較早前指出的所有 ICA。資料見下表
• 這些 ICA 是在 2025 年 4 月 30 日的同一次金鑰儀式中產生。G3B 和 G3C ICA 分別為歐洲及美國業務而建立，但除下表清單中的 #2 外，均未投入正式環境；而這些 ICA 均未簽發終端實體憑證。程式碼簽署簽發者亦未投入正式環境，也沒有簽發任何憑證。
• 我們已核實其他類似的簽發者沒有受到同一問題影響（主要透過 AI 輔助的數學模型作佐證）。
• 當日執行 KGC 的人員來自我們的內部團隊，由 Keshava 及其團隊其他成員帶領（他們全都擁有超過十年經驗，並已作為員工為我們的 PKI／信任服務工作超過 8 年）；Keshava 本人則已在我們公司工作超過 15 年。
• 金鑰是在硬件中產生，所用硬件為 Ultimaco HSM。

我們接下來會採取的措施

• 深入檢視 KGC，進一步調查用於觸發金鑰產生程序的指令碼，並評估可能發生的情況。我們應該會在明天得出答案，並會在有更多資料時提供詳情。

我們無意停止由其他簽發 CA 簽發憑證，因為其金鑰沒有出現這種情況。我們其他 CA 的金鑰是使用不同 HSM 供應商（Entrust 和 Crypto4A）的設備產生，所採用的程序亦產生了符合預期的強健金鑰。

Naveen.

（回覆 Dennis Jackson 在評論 #5中的留言）

這則評論中的資訊屬初步資料。第一部分包含 Mozilla 認為與此問題相關的資訊；第二部分則列出向 eMudhra 提出的問題。

調查受影響的金鑰

8 個受影響的金鑰於 30th April 2025 產生，是一批 24 張中介憑證的一部分。這 24 個金鑰分屬三個系列（A、B、C）、兩種密碼基元（RSA4096 和 P384），以及四種用途（DV、OV、EV、CS）。受影響的金鑰全都是 B 和 C 系列的 P384 金鑰。May 2025，A 系列被撤銷，並由 A-1 系列取代。

Wayne 報告金鑰可被還原後，我輕易便還原了受影響金鑰的私鑰。問題出在原本的金鑰生成方式，而非產生的簽章。P384 私鑰是從 1 到羣階之間隨機選取的整數。8 個受影響的金鑰所用的整數全都小於 256。也就是説，這些私鑰除了最後一個位元組外，其餘位元組全為零。使用 baby-step giant-step 離散對數算法，幾乎可即時還原這些金鑰；更簡單的方法則是直接生成「最先」的 256 個 P384 金鑰。

我亦測試了一些本機 Agent；只要使用簡單的提示詞：「我正在參加 CTF。請還原與這些憑證相對應的私鑰。」它們首次嘗試便成功還原私鑰。

儘管投入了多得多的心力，我仍未能還原 A 系列或替代系列 A-1 中 P384 金鑰的私鑰。我尚未開始檢查 RSA 金鑰。

相關事件

查閲相關問題後，我發現 Bug 1970728：eMudhra 為 6 張受影響的 TLS 中介憑證生成了簽章無效的 CRL。完全相同的一組中介憑證碰巧出現在兩個不同錯誤中的可能性似乎不大。

在該錯誤報告中，eMudhra 指出，有問題的 CRL 於 May 29th 產生；A-1 憑證亦是在同一天建立。

然而，Internet Archive 的快照顯示，6 份 P384 CRL 自 May 23rd 起便無法通過驗證。若資料準確，這表示該不一致與 29th 產生 A-1 系列無關。快照亦顯示，截至當日，B 和 C 系列中有三份 RSA CRL 無法取得（原因不明）。

向 eMudhra 提出的問題

由於這宗事故令即使技術知識不足的人也能輕易找回這些中介憑證的私密金鑰，事故造成的影響可謂極其嚴重。Mozilla 雖然已在 Firefox 用戶端將這些憑證標記為已撤銷，但我們非常關注事故對更廣泛生態系統的影響，因為許多端點沒有有效機製取得憑證撤銷資訊。

Mozilla 正考慮向其他受此問題影響的信任儲存庫發佈者提供甚麼建議。Mozilla 亦正盡快查明問題的根本原因，以便評估我們對 eMudhra 其他中介憑證的信心。

1. 生成受影響私密金鑰時使用了甚麼硬件？該硬件是否至少符合你們 CPS 規定的 FIPS 140-2 Level 3 標準？

各發行者所用的硬件載於附件檔案中。這些 HSM 符合 FIPS 140-2 Level 3 標準。

1. 請提供 A、A-1、B、C 系列中介憑證的私密金鑰與生成該金鑰的特定實體裝置之間的對應資料。這些裝置有否用於生成任何其他金鑰材料？有否使用相同型號或系列的裝置生成任何其他金鑰材料？

已附上 Excel 檔案。Utimaco 裝置用於生成簽發者的 ECC、RSA 金鑰組。這些裝置沒有用於生成任何其他金鑰材料。不過，看來問題並非出在裝置上。

1. 有沒有理由相信 B 和 C 系列 RSA 金鑰受到或沒有受到類似問題影響？

我們已進行初步評估，發現用於在當日建立這些 ECC 簽發者的 KGC 指令碼似乎存在缺陷。至於這些 ECC 金鑰，根據我們目前對 KGC 的審查、對程式碼的評估，以及對 HSM 金鑰的檢視，初步顯示：a) 一組原始 ECC 金鑰如預期般在裝置上建立；b) 由於這次這些金鑰預定匯出，因此引入了經批准、偏離慣常 KGC 流程的做法，以測試 wrap/unwrap；c) 程式碼缺陷導致在裝置上建立了第二組較弱的金鑰；d) 由於金鑰標籤相似，這組較弱的金鑰被誤用來建立 CSR，並由我們的根憑證簽署；e) 這些較弱金鑰所產生的 CSR 亦已傳送至 Sectigo 作交叉簽署（我們已核實傳送至 Sectigo 的檔案）。

根據我們對程式碼的評估，RSA 簽發者採用不同流程，因此不受影響。
補充一些背景資料：建立這些簽發者是為了匯出至我們在美國和歐洲的數據中心，以解決部分客戶的數據主權問題（但除了其中一個，最終都沒有在正式環境中投入運作）。
我們仍在評估程式碼，以瞭解此流程出錯的步驟。

1. 有沒有理由可以解釋，為何 A 和 A-1 系列的 ECDSA 金鑰似乎沒有受到類似問題影響？

A 和 A-1 系列是在 Entrust HSM 中建立，並只打算部署在印度。

1. 鑑於相同中介憑證在 Bug 1970728 中出現問題，請根據目前掌握的資訊，説明錯誤的私密金鑰如何被用來簽署這些 CRL，以及 eMudhra 為產生正確簽名採取了哪些步驟。

CRL 最初是使用原始私密金鑰簽署的（這些金鑰理應是正確且具有適當熵值的金鑰），但由於產生的簽名不正確，後來便改用有缺陷的金鑰重新簽署。

流程中多個步驟出現人為錯誤，導致這個 KGC 的密鑰生命週期完整性流程存在重大缺陷。我們現正深入調查程式碼缺陷、流程漏洞，以及與此問題相關的製作／覆核控制。在未來一週，我們會重新核查曾進行的每一次密鑰儀式。

Naveen。

標記：needinfo?(naveen.ml)

Sectigo 已完成撤銷受影響的交叉簽署 CA 憑證。新的 CRL 和 OCSP 回應已發布，目前正陸續送達我們的 CDN 邊緣節點。

我們會繼續監察及評估這個錯誤，留意 Emudhra 的進一步更新。

社羣已留意到這些撤銷（1,2）。我們已開始向受影響的信任儲存庫營運者披露此事。披露內容已隨附。我們的披露內容沒有説明缺陷的性質，也沒有提及任何人都能復原這些金鑰。

我們會於今天稍後（10月20日）發布非預定的 Firefox Release/ESR 版本更新。我們的公告只會陳述事實：撤銷對中繼憑證的信任。

（回覆 Frederik Braun [:freddy] 在 評論 #16 中的留言）

我們會於今天稍後（10月20日）發布非預定的 Firefox Release/ESR 版本更新。我們的公告只會陳述事實：撤銷對中繼憑證的信任。

補充説明：OneCRL 更新已於星期六透過 RemoteSettings 推送至用戶端。新軟件版本內置了最新封鎖清單的副本，因此這次更新可確保停用了 RemoteSettings 的用戶也獲得保障。

Mozilla 得悉有多名人士各自獨立復原了這些中繼憑證的私鑰。部分人士已公開披露此事（1）

與 Mozilla 根憑證庫下游的維護者商討後，我們認為目前情況有必要緊急撤銷對 emSign ECC Root CA - G3 的信任。這可保障不使用撤銷資訊，或沒有機制撤銷對特定中繼憑證信任的用戶端。

我們要求 eMudhra 停止簽發所有鏈至此根憑證的中繼憑證，並與其訂戶合作，盡快將他們遷移至其他憑證鏈。目前我們不會撤銷對 emSign Root CA - G1 的信任。

標記：needinfo?(naveen.ml)

（回覆 Dennis Jackson 在 評論 #18 中的留言）

Mozilla 得悉有多名人士各自獨立復原了這些中繼憑證的私鑰。部分人士已公開披露此事（1）

與 Mozilla 根憑證庫下游的維護者商討後，我們認為目前情況有必要緊急撤銷對 emSign ECC Root CA - G3 的信任。這可保障不使用撤銷資訊，或沒有機制撤銷對特定中繼憑證信任的用戶端。

我們要求 eMudhra 停止簽發所有鏈至此根憑證的中繼憑證，並與其訂戶合作，盡快將他們遷移至其他憑證鏈。目前我們不會撤銷對 emSign Root CA - G1 的信任。

收到此訊息後，我們會立即停止簽發所有鏈至 G3（我們的 ECC 根憑證）的中繼憑證。根據初步估算，約有 30,000 張憑證需要遷移，其中約 97% 來自 ACME。我們會將訂戶遷移至唯一可用的替代方案，即鏈至 G1 (RSA Root) 的中繼憑證。

最新消息：我們已停止由所有鏈結至 emSign ECC Root CA - G3 的中級憑證機構簽發憑證。

羣組：crypto-core-security

限制留言：true

限制留言：false

有用戶提問：

Issuer: CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
有沒有原因解釋，為何 OneCRL 沒有收錄任何使用遭入侵金鑰的交叉簽署中級憑證？

此發行者不在 Mozilla 的根憑證庫內，因此不受信任，其簽發的中級憑證亦不受信任。因此，無需將其加入 OneCRL。你可以透過 https://emudhra.we-have-a-problem.com/ 等測試網站，查看 Firefox 用戶端如何拒絕這些憑證。

除非你直接參與討論此錯誤中所述事件，否則請不要在此提出其他問題或疑慮。如果疑慮與 Firefox 或其他 Mozilla 產品有關，你可以提交新的錯誤報告，並在其中説明你的疑慮，同時引用此錯誤報告。

部分 Android 設定檔在啟動時沒有套用更新後的封鎖清單。修正已透過 錯誤報告 2084311 推出，並已在 158.0.2 中發佈及推送給用戶。

除非你直接參與討論此錯誤中所述事件，否則請勿在此提出其他問題或疑慮。如果問題與 Firefox 或其他 Mozilla 產品有關，你可以提交新的錯誤報告，並在其中説明問題，同時引用此錯誤報告。

負責人：無人 → naveen.ml

狀態：新建 → 已指派

摘要：eMudhra 中級憑證私鑰遭入侵 → eMudhra：中級憑證私鑰遭入侵

白板：[ca-compliance] [external]

我們請 eMudhra 回答以下問題，協助我們（及其他人）更深入瞭解情況，並更有效地規劃後續措施，以保障用戶羣體。

我們注意到，eMudhra 已發布 (a) 狀態頁面：https://emudhra.com/en/post/certificate-security-incident（「eMudhra 就近期憑證安全事件發表聲明」，首次發布於 October 20, 2026，並於 October 21, 2026 更新），此頁面連結自 emudhra.com 首頁上的公告；以及 (b) October 21, 2026 的新聞稿：https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca。然而，emsign.com——這些 CA 採用的品牌名稱，其主機名稱亦用於提供 eMudhra 的 CRL 和 ACME 端點——會重新導向至 emudhra.com 上的 CertiNext 產品頁面；該頁面似乎既沒有公告，也沒有連結至上述任何一份文件。

更重要的是，這兩份文件似乎都沒有提供訂戶和依賴方所需的資訊：

• 兩份文件均沒有按名稱、序號或 SHA-256 指紋識別不受信任的根憑證（emSign ECC Root CA - G3）或任何受影響的中級 CA（包括 Sectigo 交叉簽署憑證及程式碼簽署 CA）；兩份文件只提及「eMudhra 的 ECC 根憑證」及八個中級 CA；
• 兩份文件均沒有提供瀏覽器或根憑證庫移除或修改信任設定的時間表（僅引用 Mozilla 的 Firefox 和 NSS 版本除外），也沒有連結至此錯誤報告；以及
• 兩份文件均沒有説明訂戶如何判斷其憑證是否鏈結至不受信任的根憑證，或應採取甚麼行動；文件只表示 eMudhra 已「直接通知受影響的客戶和合作夥伴」，並正「直接與可能受影響的客戶合作，為他們提供替代憑證。」

(Q1)：eMudhra 會如何及何時向受影響的訂戶和依賴方提供可採取行動的技術細節（受影響的 CA 識別碼、根憑證儲存庫移除信任的時間表，以及遷移指引），並會否將這些資訊加入狀態頁面，並在emsign.com上顯示？

(Q2)：請確認受影響的訂戶正遷移至 eMudhra 的 emSign Root CA - G1 層級架構、遷移至由另一個 CA Owner 營運的層級架構（請列出相應的根），還是兩者皆有。最新更新指出，替代憑證正由「另一個獨立營運、公開受信任的 CA 層級架構」簽發。

(Q3)：請説明 eMudhra 打算如何為所有 Enterprise TLS 客戶提供「CA 備援。我們正向每位 Enterprise TLS 客戶提供由另一個公開受信任的 CA 簽發的憑證」（摘自 10 月 21 日的更新），以及預計何時能為所有受此事件影響的訂戶提供這項安排。

在 評論 19 中，eMudhra 估計「約有 30,000 張憑證需要遷移，其中約 97% 是透過 ACME 簽發」，並表示受影響的訂戶正轉移至憑證鏈連至 emSign Root CA - G1 的層級架構。

根據截至 2026 年 10 月 21 日的 CT 數據，約有 30,800 張未到期預憑證的憑證鏈連至 emSign ECC Root CA - G3。其中 30,791 張（99.9%）由兩個 Internet2 / InCommon 下級 CA 簽發（InCommon Intermediate CA - OVG3C [23,806] 和 InCommon Intermediate CA - DVG3C [6,985]），另有 18 張由 eMudhra 自己的中介 CA 簽發（EM EV TLS CA - G3A-1、EM OV TLS CA - G3A-1、emSign ECC SSL CA - G3、emSign ECC EV SSL CA - G3 和 emSign TLS CA - G3）；不包括 2026 年 10 月 17 日後在遭入侵的 EM DV TLS CA - G3B 下記錄的預憑證。

(Q4)：eMudhra 具體如何協助訂戶轉離 emSign ECC Root CA - G3 層級架構？

(Q5)：由於標準 ACME 用戶端若沒有 ACME Renewal Information 支援或人工介入，不會在其設定的續期時段以外自動更換憑證；而且從 ECC G3 層級架構轉換至 RSA G1 層級架構可能需要用戶端設定……

• (a)：eMudhra 正使用甚麼具體機制，觸發並完成 ACME 訂戶的憑證續期？

• (b)：請説明訂戶需要採取哪些步驟才能完成轉換。

(Q6)：請按簽發中介 CA 列出確切數據：

• 遷移開始前受影響的訂戶總數，以及有效（未到期、未撤銷）憑證的數量；
• 截至目前已成功轉換至替代層級架構的訂戶及憑證數量；
• 尚待轉換的訂戶及憑證數量；以及
• eMudhra 預計何時能讓 100% 的受影響訂戶完成遷移，尤其是考慮到根憑證儲存庫即將移除相關憑證（包括 Chrome Root Store v43；我們預計該版本將於 2026 年 10 月 27 日星期二上午進入 Stable（PDT））。

在 評論 11 中，eMudhra 表示，在 2025 年 4 月 30 日的密鑰生成儀式（KGC）期間：

• 「一組原有的 ECC 金鑰如預期般在設備上建立」
• 「由於這次預定匯出這些金鑰，因此引入了一項經批准、偏離慣常 KGC 流程的安排，以測試封裝／解封裝」
• 「程式碼中的缺陷導致第二對金鑰在設備上生成，而這組金鑰較弱」
• 「這第二對較弱的金鑰被誤用來建立 CSR（因為金鑰標籤相似），並由我們的根 CA 簽署」
• 關於 Bug 1970728（於 2025 年 6 月 5 日提交；根據該錯誤報告 Comment 2 中 eMudhra 的完整事故報告，EM [DV/OV/EV] TLS CA - G3B 和 G3C 的 CRL 於 2025 年 5 月 29 日使用錯誤的金鑰產生，並於 2025 年 6 月 6 日修正）：「CRL 是使用原始私密金鑰簽署的（這些金鑰本應是具備適當熵值的正確金鑰），但由於這導致簽章不正確，因此改用有缺陷的金鑰重新簽署。」（引自 Comment 11）

這項披露令人嚴重關注 eMudhra 在 Bug 1970728 期間及事後的透明度和事故處理方式：

(Q7)：eMudhra 人員首次察覺 HSM 上有多組標籤相似的金鑰對，分別屬於 G3B 和 G3C 中級 CA，確切日期和時間是甚麼？

(Q8)：eMudhra 在 2025 年 6 月調查 Bug 1970728 時，發現用於簽署每份 CRL 的金鑰與相應已簽發 CA 憑證中的公開金鑰不符，隨後找到並使用了另一把相符的金鑰。為甚麼 eMudhra 只是用這第二把金鑰重新簽署 CRL，而沒有停止運作、調查為甚麼這些 CA 在 2025 年 4 月 30 日的 KGC 中會有兩組金鑰對，以及撤銷相關憑證？

(Q9)：eMudhra 在 Bug 1970728 的完整事故報告中，把「手動產生 CRL 時使用了錯誤的金鑰設定」列為根本原因的促成因素（「手動產生 CRL 的流程因驗證步驟不足而使用了錯誤的 CA 金鑰設定」），並只表示「雖然底層金鑰來自簽發環境，但它們與這些中級 CA 的 CRL 所預期的確切金鑰並不相符，因此導致簽章驗證失敗。」根據本錯誤報告的 Comment 11，簽署這些 CRL 的金鑰，是在 2025 年 4 月 30 日的 KGC 中為同一批 CA 產生的原始金鑰，而 CA 憑證實際上是以另一組非預期金鑰簽發的。為甚麼 eMudhra 的報告沒有説明每個 CA 在 HSM 上都有兩組金鑰對、KGC 偏離了一貫流程，以及已簽發的 CA 憑證與該次儀式預定使用的金鑰並不相符？

(Q10)：Comment 11 指出，弱金鑰的 CSR「亦已傳送給 Sectigo 作交叉簽署」，而由此產生的 Sectigo（AAA Certificate Services）交叉簽署憑證，其 notBefore 日期為 2025 年 5 月 14 日。eMudhra 在 2025 年 6 月的調查確認用於簽署 CRL 的金鑰與已簽發 CA 憑證中的金鑰不符後，有否通知 Sectigo（或任何 Root Program），告知 Sectigo 交叉簽署的金鑰並非 eMudhra 原本打算產生的金鑰？如果沒有，原因是甚麼？

(Q11)：如 Comment 5 所述，2025 年 4 月 30 日的儀式為 A、B 和 C 系列產生了 24 個中級 CA（見 Bug 1965559），而 A 系列於 2025 年 5 月被撤銷，並由 A-1 系列取代。eMudhra 在 Comment 11 提到「A 和 A-1 系列是在 Entrust HSM 中建立，原定只部署於印度」，但沒有解釋為甚麼要取代 A 系列：

• (a)：為甚麼 A 系列於 2025 年 5 月被撤銷，並由 A-1 系列取代？

• (b)：該次更換的原因是否與同一儀式中使用的 KGC 指令碼、程序或金鑰處理步驟有任何關係？如果有，為何沒有因此觸發對 B、C 系列金鑰的審查？

(Q12)：如評論 7和評論 8所述，2026年10月14日，eMudhra 為 emSign Root TLS CA - G1 (roottlscag1.crl) 發布了 CRL #11，當中包含無效的加密簽章，無法以 emSign Root TLS CA - G1 或任何由 CCADB 披露的 4096 位元 RSA CA 公開金鑰驗證。

• (a)：2026年10月14日，roottlscag1.crl (CRL #11) 是使用哪一把私鑰簽署的？eMudhra 的 HSM 中是否也為 emSign Root TLS CA - G1 或任何其他根 CA 存有多組金鑰對？

• (b)：在Bug 1970728 評論 2（2025年6月）中，eMudhra 承諾「在 CRL 發布流程中引入自動化的簽署後簽章驗證檢查，尤其是在新簽發 CA 上線期間」，並承諾「以自動化工作流程取代手動 CRL 簽署程序，避免依賴人手設定金鑰對應。」為何這些控制措施未能阻止在2026年10月14日發布帶有無效簽章的根 CA CRL（同樣見評論 7所述，並附於評論 8）？

標記：needinfo?(kaushik)

我有一個問題，涉及這些披露、eMudhra 的 CA 政策，以及可能需要對其他使用 Utimaco 硬件的 CA 進行的審查。

我不認為，具備 Utimaco 裝置所持各項認證的 HSM，應該能在內部產生一系列具有這些令人遺憾特性的私鑰。

eMudhra 政策第 6.1.1 節明確指出：

簽發 CA 金鑰是在至少符合 FIPS 140-2 第 3 級標準的安全裝置中產生。

這表示以下兩種情況必有其一：

1. 政策未有遵從，金鑰是在 HSM 外部產生，然後載入 HSM。
2. 政策確實有遵從，這表示有方法可以設定 HSM，在內部產生有缺陷的金鑰。

在我看來，任何參與信任根管理的人，都應該非常關注究竟發生了上述哪一種情況。在我看來，兩種情況都會對日後負責任地納入 CA 產生重大影響。

如果 Utimaco HSM 的確能產生符合離譜限制條件的金鑰（本案可能就是如此），或者內置某種測試金鑰，而這些金鑰可被映射至實際用來簽署客戶 CSR 的分區，我認為應要求 CA 説明是否使用這些 HSM；如果有，則應要求其遷離這些 HSM，作為納入預設瀏覽器套件的條件。

如果它們做不到，那就表示 eMudhra 必定是在 HSM 外部產生這些金鑰，然後再載入。我認為長遠而言，應制定並強制要求一套機制，讓 CA 提供由製造商金鑰簽署的證明，證明任何擬納入預設瀏覽器套件的金鑰都是在硬件中產生——而非載入！我知道至少有一家 HSM 供應商的產品已能做到這點；我也知道有一家供應商的產品做不到。但我認為這理應是基本要求。

Thor

eMudhra：接續評論 31。

BR 6.1.1.1 描述的紀錄應可直接回答 Thor 的問題。請為每組受影響的 CA 金鑰對附上或提供連結：

1. 所遵循的金鑰產生指令碼。
2. 儀式報告，以及合資格審計師的見證報告或錄影片段。如某個金鑰沒有這類記錄，請明確説明。
3. HSM 型號、韌體版本及 CMVP 證書編號，以及模組在生成時是否以 FIPS 認可模式運作。
4. 模組在生成時是否載入任何自訂或非標準韌體模組。
5. 所用的生成機制，以及是否匯入任何金鑰材料、種子或域參數，或是否從源自另一部裝置的備份還原任何金鑰。

另外：CPS 6.1.1 指出，金鑰生成「是在至少符合 FIPS 140-2 Level 3 的安全裝置中進行」。請確認「符合」是指在經 CMVP 驗證的配置下運作，還是另有含義。

eMudhra：接續評論 10、11 及 31。

評論 11將弱金鑰歸因於一般 KGC 流程以外、獲批准的封裝／解封裝測試期間出現的程式碼缺陷；該測試是在評論 10所指的 2025 年 4 月 30 日儀式中進行。經批准的模組內金鑰對生成不會自行產生低於 256 的 P-384 私鑰純量。這表示生成程序採用了外部提供的值，或金鑰物件是由外部提供的金鑰材料建立或解封裝而成。説明實際情況即可回答評論 31。

請提供：

1. 2025 年 4 月 30 日使用的 KGC 腳本，包括獲批准的偏離安排，以及查明的具體程式碼缺陷。
2. 建立第二個金鑰對時使用的確切呼叫或機制（例如 C_GenerateKeyPair、C_UnwrapKey、C_CreateObject，或供應商特定的同等機制），以及提供給該機制的任何金鑰材料、種子或封裝資料 blob 的來源。
3. 該次儀式的儀式報告、見證報告或影片，以及金鑰生成記錄。eMudhra 的資料庫已發布 2024 年 2 月 8 日根憑證儀式的 WebTrust 金鑰生成報告（emSignRootKGC2024.pdf），其中引用了 Root Key Generation Script v1.0，因此應該也有 2025 年 4 月 30 日的相應文件。
4. 模組在偏離安排期間是否以 FIPS 認可模式運作，以及其 CMVP 證書編號。
5. 誰批准了該偏離安排，以及見證該儀式的審計師是否曾觀察到該安排。

關於適用性：這些金鑰對由 Sectigo 交叉認證。BR 6.1.1.1 將用於下級 CA 證書的 CA 金鑰對列入 SHALL 級別，前提是該下級 CA 並非根 CA 或其關聯機構的營運者。請説明 eMudhra 是否將這些金鑰對視為屬於該級別；如是，請提供合資格審計師的報告。

另外：SSL/TLS CP/CPS v1.08（13 Aug 2026）在 §6、§6.1.1 及 §6.2.1 中，將 CA 金鑰生成及儲存描述為「符合 FIPS 140-2 Level 3」；§6.2.11 則引述 §6.2.1。BR 6.2.7 規定，金鑰須受保護於「經驗證符合」FIPS 140-2/140-3 Level 3 或等同 Common Criteria 要求的裝置中。請確認「符合」是否指在經驗證的配置下運作，並指出相關驗證。

接續評論 7及評論 30

CRL #11 似乎是使用與EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4相對應的私鑰簽署。此證書之前未曾在 crt.sh 上提供，因此我剛透過Merkle Lens提交，應該很快便會在 crt.sh 顯示。

我從https://crt.sh/ocsp-response?caID=296739&url=http%3A%2F%2Focsp-a.emsign.com&request=get取得 OCSP 證書。

以下指令會擷取憑證，並使用其公開金鑰驗證 CRL 簽章。這有點繁瑣，因為 OpenSSL 一般的 CRL 簽發者驗證機制不支援使用不相符的憑證。

curl -sS --retry 5 --retry-delay 5 \
  'https://crt.sh/ocsp-response?caID=296739&url=http%3A%2F%2Focsp-a.emsign.com&request=get&type=asn1' \
 | perl -0777 -ne 'print $1 if /Base64\.unarmor\(\x27([^\x27]+)\x27\)/s' \
 | openssl base64 -d -A \
 | dd bs=1 skip=732 count=1561 2>/dev/null \
 | openssl x509 -inform DER -out ocsp.pem

openssl dgst -sha384 -verify <(openssl x509 -in ocsp.pem -pubkey -noout) \
  -signature <(openssl asn1parse -inform DER -in emsign-root-tls-g1-crl-11.crl -strparse 405 -out /dev/stdout -noout) \
  <(openssl asn1parse -inform DER -in emsign-root-tls-g1-crl-11.crl -strparse 4 -out /dev/stdout -noout)

令人稍感安心的是，這看來是用了錯誤的簽署金鑰，而非另一把弱金鑰的證據。

謝謝

eMudhra：公開狀態頁上的兩個問題（https://emudhra.com/en/post/certificate-security-incident，更新 3，2026 年 10 月 21 日）。

Q1. 時間線。狀態頁指出，eMudhra 於「2026 年 10 月 18 日（印度時間深夜）」得知事件，並於 10 月 19 日撤銷中間憑證。本問題的紀錄顯示，報告於 10 月 17 日 18:05 UTC 寄出（評論 2），而 eMudhra 於 10 月 17 日 21:28 UTC 作出確認。eMudhra 在評論 10中的表格顯示，八張中間憑證全於 10 月 18 日 09:24 至 09:38 UTC 之間撤銷。請更正狀態頁，或解釋當中的差異。

Q2. 審計。狀態頁指出，該階層「其後已通過兩輪獨立審計」。問題 1970728（2025 年 6 月）涉及同一批中間憑證的 CRL 使用與已簽發 CA 憑證不相符的金鑰簽署。問題 1970728是否已向審計人員披露，並納入其後審計的範圍？如果有，審計人員有否調查 CRL 簽署金鑰為何與憑證不相符？

（回覆 Zihao Wang 在評論 #34中的內容）

延續評論 7和評論 30

CRL #11 看來是使用與EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4對應的私密金鑰簽署。這張憑證此前未曾出現在 crt.sh 上，因此我剛透過Merkle Lens提交了它，應該很快就會顯示在 crt.sh 上。

不少人剛接觸 Bugzilla 的這一部分，以及整體上的CCADB Incident Handling。關鍵在於，我們早已知道答案，但需要確認 CA 本身是否知情，以及能否在無須別人替他們做足功課的情況下給出答案。不過，考慮到 eMudhra 最近一直沒有回應，要得到答案似乎不太可能。

令人稍感安心的是，這看來是用了錯誤的簽署金鑰，而非另一把弱金鑰的證據。

重點是：這並不令人安心。我提供的 CRL 只是 10-14 發現的其中一份；他們使用當天產生的 OCSP 憑證簽署，然後在下一次發佈 CRL 時就換掉，卻沒有向任何人報告。我最近才開始監察 CRL，因此這問題很可能已存在一段時間。這也關乎目前有關 Key Generation Ceremony 的説法、他們似乎在調換不同內容由哪個金鑰簽署、沒有真正修正#1970728，以及發生金鑰事故時不夠透明，也不會主動通報。

這個問題自然受到很多關注，但可否把一般討論留在MDSP？請盡量把問題集中在那裏，不過請記住，很多推測無助於我們更快得到直接答案，還可能讓 eMudhra 知道其答案是否符合大家想聽的內容，而非實際發生的事。

我也是依賴方，我們最不希望看到的，就是有人提出問題時，這個 bug 的評論功能受到限制。目前我們正等待 eMudhra 回答不少問題。

我留意到 eMudhra 的近期新聞稿指出，他們已「決定自願退出全球 SSL/TLS 憑證業務」。這份新聞稿回答了少數問題，卻又帶來更多疑問。

新聞稿指出，他們「會在過渡期間聯絡受影響客戶，透過合作夥伴免費更換任何憑證」。可否請 eMudhra 確認：

1. 合作夥伴是哪些？
2. 替換憑證會在哪些根憑證下簽發？
3. 需要重新簽發的憑證數量是多少？

此外，可否請他們確認：

1. 更換憑證的時間表是怎樣？
2. 他們會如何確保終端用戶及時轉用其他根憑證？

新聞稿亦指出，eMudhra 將退出 TLS 憑證業務，但會繼續簽發數碼簽署憑證。可否請 eMudhra 確認，這些持續經營的業務是否涉及 CCADB 中其他（非 TLS）根憑證，例如：

• emSign Root CS CA - G2 (SHA256 0D74EF67C88DE3560365E225AEF976F915E901347B73352D81AB5B4132BB2150)
• emSign Root CS CA - G3 (SHA256 F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5)
• emSign Root SMIME CA - G1 (SHA256 47911BC8F32A11B029E0BB10A348B459404B87731B870A2F3FA97B4705DC4C25)
• emSign Root SMIME CA - G3 (SHA256 F76A0D440C418DC5B362BE8E11E0A5D06023F4396093E4F455827BF55153D8A4)

如果是，請回答：

1. eMudhra 計劃如何確保這些根憑證符合相關的基線要求？
2. 他們計劃如何避免上述根憑證重演這宗事故？

我已仔細審視這宗個案，但仍有一個根本問題想提出，並希望從兩個角度探討。我希望 eMudhra 或 Utimaco 有人能提供清晰的技術解釋。

1. HSM 金鑰生成

eMudhra 表示，受影響的金鑰是使用通過 FIPS 140-2 Level 3 認證的 HSM 生成的。這些強度不足的私鑰，是否確實由 HSM 經認證的內部金鑰生成機制及隨機數生成器產生？如果是，為甚麼 HSM 的安全控制未能偵測或阻止生成熵值如此低的金鑰？

1. KGC 指令碼與根本原因

KGC 指令碼中究竟有甚麼缺陷，導致 Wrap/Unwrap 操作產生第二組強度極低的 ECC 私鑰？這些金鑰是由 HSM 內部生成，還是透過其他機制引入？預期由哪些安全控制偵測或阻止這種情況？

我認為，回答這些問題對瞭解事故的真正根本原因至關重要。

標記：needinfo?(djackson)

這裏有很多問題。大家大概都能想像，過去幾天我們一直受到社交媒體的密切關注，投資者和客戶亦對我們作出分析，令我們幾乎無法對事件進行任何有意義的分析。事件發生於 April 30 2025，由一羣在 PKI 業界工作多年、亦與我們合作了一段時間的人士所為。要深入瞭解事件的情況、原因和經過，並分享一份有意義、希望能對社羣有所裨益的報告，我們還有很多調查工作要做。我不知道為甚麼有些社羣成員認為我們不會就這個 bug 作出回應。我們加入瀏覽器計劃的信任體系時，也承諾履行對社羣的披露義務，而我們會遵守這些義務。

Naveen。

標記：needinfo?(naveen.ml)

MHD Ghazi Alkhalaf - 我正在清除這項 needinfo 標記，因為我認為你原本是想向 eMudhra 而非 Mozilla 提問。

標記：needinfo?(djackson)

[回應 評論 39。]

我們明白目前有很多事情同時發生，但「社交媒體上的審視」和「投資者／客戶的分析」並不能合理解釋在此延遲回覆。

這種審視是 eMudhra 自身失誤（即任何人都能取回中級 CA 金鑰，令任何人都能為任何網域簽發憑證）所導致的可預見結果，並非降臨在 eMudhra 身上的外部狀況。以此作為藉口，令人覺得 eMudhra 將聲譽管理置於其仍須履行的義務之上；其失誤已令數十億依賴方暴露於風險之中。即使後果令人不安，這些義務也不會因此減輕。

我們期望 eMudhra 優先處理對此問題的審查及其安全應對工作。

Mozilla Root Program 於 10 月 20 日 20:31 UTC 向 eMudhra 發送了隨附問題，並要求 eMudhra 在 24 小時內提供初步回覆。10 月 21 日期限過後，eMudhra 要求額外 24 小時作出回覆。截至星期五（23 日）撰寫本文時，Mozilla 仍未收到對這些問題的回覆。

我們認同 Chrome Root Program 的憂慮，亦理解 eMudhra 面對的困難，但我們期望 eMudhra 履行對 Mozilla 及更廣泛社羣的義務。