印度CA eMudhra爆出私钥泄露！Chrome、Firefox 紧急封禁，多款软件连夜修复

2026 年 10 月 20 日，Mozilla 和 Google 公开披露印度数字证书颁发机构 eMudhra 的中间 CA 私钥安全事件：该机构旗下八张中间 CA 证书对应的私钥因生成过程存在严重随机性缺陷，已被外部人员恢复。

Mozilla 和 Google Chrome 根证书计划确认，该机构旗下八张中间证书颁发机构（CA）证书对应的私钥已经泄露，涉及 TLS 域名验证、组织验证、扩展验证及代码签名等用途。

中间 CA 处于数字证书信任链的关键位置，能够依据其授权范围签发下级证书。对于 TLS 中间 CA，如果攻击者取得对应私钥，就可能尝试签发冒充合法网站的证书；对于代码签名中间 CA，攻击者可能利用其私钥签发未经授权的代码签名证书，进而为恶意软件签名，增加软件来源验证与信任判断的风险。

根据 Mozilla 公布的调查信息，此次问题出在 eMudhra 的密钥生成环节。这八个中间 CA 的私钥采用 P-384 椭圆曲线，但实际使用的私钥数值却是极小的整数，外部人员几乎可以瞬间恢复。这意味着，即使没有从 CA 内部窃取私钥，攻击者也可能获得相应的证书签发能力。

Chrome、Firefox 随后封禁相关 TLS 中间 CA。Chrome 根证书计划表示，在 Chrome 实施封禁之前，证书透明度（CT）日志中没有记录任何链接至其中六个网站用途中间 CA 的 TLS 证书。因此，在 Chrome 或其他要求证书记入 CT 日志的浏览器中，这些证书均不可能获得默认信任。

Apple、Microsoft 等信任体系也采取了相应措施。与此同时，Go、Firefox、NSS、Python certifi 等软件及证书库陆续发布修复。

此次事件不仅涉及 CA 核心密钥安全，也再次凸显了一个长期存在的行业难题：当 CA 私钥失守，如何让风险信息及时传递至不同浏览器、操作系统、编程语言及应用程序？

哪些证书受到影响？

eMudhra 是一家印度 CA，以 emSign 品牌提供数字证书服务，其根证书已被纳入多个主流信任体系。此次事件涉及的八张中间 CA 证书分别归属于 eMudhra 在荷兰的 eMudhra BV 和美国的 eMudhra Inc。

此次私钥泄露涉及的八张证书为：

TLS 域名验证（DV）证书：EM DV TLS CA - G3B（荷兰 eMudhra BV）和 EM DV TLS CA - G3C（美国 eMudhra Inc）

TLS 组织验证（OV）证书：EM OV TLS CA - G3B 和 EM OV TLS CA - G3C

TLS 扩展验证（EV）证书：EM EV TLS CA - G3B 和 EM EV TLS CA - G3C

代码签名证书：EM OV CS CA - G3B 和 EM OV CS CA - G3C

这六张 TLS 中间 CA 证书由 emSign Root TLS CA - G3 签发，其证书链最终链接至 emSign ECC Root CA - G3。该根证书已纳入 Chrome 和 Apple 的根证书库，在 10 月 20 日之前也位于 Mozilla 的根证书库中。

根据 Mozilla 密码学工程师 Dennis Jackson 公布的证书清单，这八张证书还各有一张使用相同公钥的交叉签名证书，由 Sectigo 在其 AAA Certificate Services 根证书下签发。

由于这些证书涉及不同用途和不同信任链，浏览器及软件维护方需要根据各自的证书验证机制采取相应措施，而不是简单地对所有证书使用相同的封禁方式。

浏览器数小时内启动封禁

多平台同步响应

此次事件的处置速度较快。

10 月 17 日，一名研究人员向相关根证书计划报告了私钥泄露问题，并通过使用这八把私钥对特定消息进行签名，提供了相应的验证材料。

随后，Chrome 和 Firefox 在数小时内完成相关 TLS 中间 CA 的封禁部署。Apple 于 10 月 19 日封禁相关证书，Microsoft 于 10 月 20 日完成封禁，其他信任库运营方也陆续收到通知。

两款浏览器采用的机制有所不同：

Chrome：通过 CRLSet 更新封禁六张 TLS 中间 CA 证书，并依据公钥识别相关密钥，因此也覆盖了使用相同公钥的交叉签名版本。

Firefox：通过 OneCRL 推送封禁信息；对于无法接收远程设置的用户，则在新版本中内置相关封禁列表。

对于采用标准设置、能够正常接收相关更新的用户，浏览器可自动获取封禁信息，通常无须手动更新或重启浏览器。

值得注意的是，Chrome 并未将两张代码签名中间 CA 纳入此次 TLS 封禁范围。这是因为 Chrome 的 TLS 验证器不会通过用途仅限代码签名的中间 CA 构建网站证书信任链，并不意味着代码签名私钥泄露没有风险。

Jackson 在 Mozilla 政策邮件列表中写道，Mozilla 目前认为该问题并未波及其他 CA。Chrome 则表示，已检查其根证书库中的所有其他 CA 证书，“未发现其他存在同类失效问题的情况”。

真正棘手的问题：

浏览器之外的应用程序

浏览器能够快速更新封禁列表，并不代表所有使用数字证书的软件都能同步获得保护。

许多应用程序依赖操作系统根证书库、独立证书包或自身的证书验证逻辑。部分程序不会主动检查证书吊销状态，即使相关中间 CA 证书已经被吊销，仍可能继续信任包含问题密钥的证书链。

这也意味着，此次事件的风险并不限于浏览器，还涉及依赖相关证书链进行身份验证的各类应用程序。

截至 10 月 20 日，多个项目已公布相应修复措施：

其中，Go 的处理方式尤其值得关注：新版标准库直接拒绝包含这八个密钥之一的证书链。要使现有 Go 程序获得标准库新增的封禁逻辑，需要使用修复版本重新编译并部署，或安装软件供应方提供的修复版本。系统根证书库更新能否提供相应保护，则取决于程序实际使用的信任库及证书验证路径。

另一种处置方式是从信任库中移除上游根证书。但这种做法的代价也更大：由于根证书可能同时为大量合法中间 CA 和终端证书提供信任基础，移除根证书可能导致原本正常的证书链失去信任，进而影响合法业务连接。

因此，精确封禁问题密钥与直接移除根证书之间，存在安全覆盖范围和业务连续性的权衡。

Mozilla 移除根证书

eMudhra 信任状态面临进一步调整

此次事件的影响已经超出单张证书的吊销范围。

Mozilla 于 10 月 20 日宣布，通过 NSS 3.131.1 移除签发相关中间 CA 的根证书 emSign ECC Root CA - G3，以保护那些使用 Mozilla 信任列表、但不会接收 OneCRL 更新的其他应用程序。

Google Chrome 根证书计划也宣布，将从 Chrome Root Store 中移除同一根证书。这项调整预计于 10 月 27 日（太平洋时间）推送至依赖 Chrome Root Store 的设备，预发布渠道预计更早获得更新。

Chrome 还表示，将进一步评估 eMudhra 其他根证书在其根证书库中的信任状态。

需要注意的是，移除根证书与封禁中间 CA 是两种不同的处置措施：前者会影响依赖该根证书建立信任链的证书，后者则可以更有针对性地限制特定签发权限。

根证书信任调整能够为不具备快速封禁能力的应用程序提供额外保护，但也可能导致依赖相关根证书的合法网站证书失去信任。对于受影响的证书持有者，及时迁移至其他受信任的 PKI 层级，是降低业务中断风险的重要措施。

目前，相关机构仍在调查私钥生成缺陷的具体成因及其影响范围。eMudhra 表示，此次事件涉及 2025 年 4 月进行的一次密钥生成仪式所产生的特定中间 CA 证书，不涉及其根 CA 私钥或其他中间 CA。后续调查结果仍有待进一步披露。

写在最后

eMudhra 事件揭示了数字证书安全中一个不容忽视的问题：即使采用成熟的密码算法，如果密钥生成环节缺乏足够的随机性，整个信任链仍可能面临严重风险。从密钥生成、CA 运营管理，到证书透明度监测、浏览器封禁和软件生态修复，每个环节都关系到数字信任体系的整体安全。

与此同时，此次事件也展现了 WebPKI 生态的协同响应能力。浏览器与根证书计划快速核查并封禁问题密钥，CT 机制为证书签发情况提供公开、可审计的核查依据，软件及信任库维护方则通过更新验证逻辑或调整信任列表，推动风险处置从浏览器延伸至更广泛的应用生态。

数字信任不仅建立在密码学的可靠性之上，也建立在严格的工程实践、透明的监督机制与高效的生态协作之上。 这正是此次事件留给整个 PKI 行业的重要启示。

关注公众号：拾黑（shiheibook）了解更多

友情链接：

关注数据与安全，洞悉企业级服务市场：https://www.ijiandao.com/
安全、绿色软件下载就上极速下载站：https://www.yaorank.com/