eMudhra 中间 CA 弱密钥事件：Firefox 为什么紧急更新？

2026年10月，eMudhra 的八个中间 CA 被发现使用了极弱的私钥。问题严重到浏览器厂商需要迅速封禁相关证书，再通过软件更新和信任库调整扩大保护范围。

Mozilla 在10月20日发布的 MFSA 2026-111 中收录了相关问题 CVE-2026-113470，评级为 high，Firefox 158.0.1 包含对应保护更新。

这不是“Firefox 的加密算法被攻破”。出问题的是一组承担签发职责的 CA 密钥，以及客户端需要及时撤回对它们的信任。

本文依据截至 2026年10月22日 查到的公开资料整理，属于事件分析；没有对本站证书、用户服务器或受影响密钥进行攻击复现。调查仍在继续，后续结论应以公告更新为准。

先分清：中间 CA、根证书和网站证书

访问 HTTPS 网站时，浏览器除了协商加密连接，还需要判断：眼前这个服务器是否有资格代表这个域名？

常见的证书链可以简化成：

客户端信任的根 CA
        ↓ 签发
中间 CA
        ↓ 签发
网站的 TLS 证书

网站证书用于证明网站身份，中间 CA 则有继续签发证书的权限。因此，中间 CA 私钥失去安全性，影响不只是某一台网站服务器。

本次需要分开的三个概念是：

概念	含义
中间 CA 私钥可被恢复	攻击者可能获得签发能力，这是此次事件的核心
中间 CA 证书被吊销或封禁	客户端应拒绝继续接受相关签发链
根证书被移出信任库	进一步撤回信任，可能影响该根下其他正常证书链

移除根证书不能直接证明根私钥也被窃取。 eMudhra 表示根私钥未受影响；这属于其公开声明中的范围说明，不等于整个调查已结束。eMudhra 事件声明

根CA、中间CA与网站证书的层级及本次弱密钥所在位置

图为概念示意，根证书移除不代表根私钥泄露。

私钥为什么会弱到可以恢复？

CERT-In 的公告指出，受影响的 P-384 私钥数值小于256，可从对应公钥迅速恢复。它同时明确：问题出在密钥生成，不能据此认为 P-384 算法本身存在漏洞。

可以把它理解成：锁具本来允许选择极大的密码空间，但实际部署时，密码只在一小撮候选值里挑选。锁具的标称规格还在，真正支撑安全性的随机性却丢了。

这也解释了为什么“私钥没有从服务器文件里被下载”不能排除失陷。如果密钥生成得足够糟，攻击者只看公开材料，也可能恢复出秘密。

这里用“弱密钥导致私钥可恢复”，比笼统写成“黑客入侵后盗走私钥”更接近已经公开的技术事实。

至于具体流程，eMudhra 在10月21日的更新中称，密钥生成仪式中的 wrap/unwrap 环节产生了另一组弱密钥，并被错误用于后续流程；该公司同时说明，确切根因仍待确认。因此，这一解释应标为厂商调查中的说明，不能写成已经完成的独立审计结论。eMudhra 最新更新

哪些风险成立，哪些说法越过了证据？

Mozilla 的 Bugzilla 2083449记录了八个受影响的中间 CA，其中六个用于 TLS，另两个用于代码签名。不能把八个全部称为网站证书签发 CA。

对 TLS 来说，主要风险是攻击者利用可恢复的签发密钥，为不属于自己的域名制作伪造证书。如果客户端仍然信任该链，且攻击者能截获或引导网络连接，就可能冒充网站。私钥可恢复并不自动赋予攻击者拦截所有网络流量的能力。Mozilla 安全博客

同样，不能由此得出“以前所有 HTTPS 流量都能解密”。CA 签发密钥和连接协商出的流量密钥承担不同职责；TLS 1.3 中使用临时密钥交换的握手，还提供相应的前向保密性质。拿到 CA 签发密钥，不等于拿到历史连接的会话秘密。TLS 1.3 标准 RFC 8446

另外两条范围信息也要保留出处：

eMudhra 表示，这些中间 CA 没有签发终端实体证书，绝大部分没有投入生产。这是厂商披露的情况，不能单凭这一点证明不存在任何未发现的恶意行为。厂商声明
Google 表示，在其封禁前，没有记录到链至相关六个 TLS 中间 CA 的证书进入证书透明度日志，因此对强制执行 CT 的客户端有额外保护。这一判断有明确的客户端条件，不能外推到所有旧系统和应用。Google 安全博客

所以，风险很严重，但“全球网站证书全部失效”“所有加密通信已被监听”都不是这些资料能够支持的结论。

Mozilla 为什么先封禁，再发 Firefox 更新？

这次处置不是从10月20日发布新版本才开始的。

按照 Mozilla 公布的时间线，它在10月17日20:06 UTC 收到报告，当天22:59 UTC 已完成面向标准配置 Firefox 用户的 OneCRL 分发。这一步不要求用户更新或重启浏览器。

时间，统一采用 UTC	动作
10月17日20:06	Mozilla 收到相关报告
10月17日22:59	Mozilla 完成标准配置客户端的 OneCRL 保护分发
10月20日	发布安全公告与 Firefox / ESR 更新

OneCRL 是 Mozilla 向客户端分发的集中封禁机制。更新软件与更新封禁信息是两条不同的交付路径。

MFSA 2026-111 解释了后续版本更新的作用：将更新后的 OneCRL 列表随版本提供，覆盖 RemoteSettings 被策略关闭，或网络环境导致其不可用的客户端。不能因为远程封禁已经完成，就认为所有定制环境都已获得保护。MFSA 2026-111

对应版本与公告如下。这里列的是此次公告的修复版本，不代表永远应停留在这些版本；后续使用受支持渠道的更新版本即可。

分支	此次修复版本	公告
Firefox	158.0.1	MFSA 2026-111
Firefox ESR 153	153.5.1	MFSA 2026-112
Firefox ESR 115	115.43.1	MFSA 2026-113

发布前复核还发现一个后续修复：Mozilla 在 Bugzilla 2083449 的评论29中说明，部分 Android 配置在启动时没有应用更新后的封禁列表，修复已随 Firefox Android 158.0.2 推送；官方发布说明也确认了这项启动加载修复。因此 Android 用户不要只对照上表停在158.0.1，应更新至包含该后续修复的受支持版本。

MFSA 是公告编号，CVE 是问题标识，Bugzilla 则记录具体工作事项。MFSA 2026-111 中与本事件对应的引用是 Bug 2083382；讨论 CA 事件本身的是 Bug 2083449，不应把这几个编号混用。

为什么更新了浏览器，还要关心系统信任库？

浏览器能够迅速更新自己的封禁信息，但服务器程序、旧设备、容器和嵌入式应用未必接收同一条更新通道。

CERT-In 记录了 NSS 3.131.1 对 emSign ECC Root CA - G3 的移除。它服务于更广的信任库消费者，不能假定应用仅因为“使用 Mozilla 来源的证书列表”，就一定会收到 Firefox 的 OneCRL 更新。CERT-In 公告

Google 则先通过 CRLSet 按受影响公钥的 SPKI 哈希封禁，并宣布移除 Chrome Root Store 中的相关根。其公开计划是让根移除于 2026年10月27日美国太平洋夏令时上午覆盖依赖该根库的设备。截至本文资料截止日，这仍是预告，不能写成已全量完成。Google 公告

这也带来可用性问题：弱中间 CA 被封禁，与整条根信任被撤回，覆盖范围可能不同。网站原先的链即使没有经过那六个 TLS 中间 CA，也可能因为终点根证书被移除而失败。

远程封禁、软件更新与信任库调整三条应急路径及截至10月22日的进展

三条路径覆盖不同客户端，Android后续修复与Chrome计划时间应分别核对。

普通用户和站长分别做什么？

普通用户：更新实际使用的客户端

按浏览器及系统提供的正常渠道更新，并完成必要的重启。企业管理的 Firefox 还应检查策略和远程配置分发是否正常；“安装了 Firefox”不等于“远程封禁列表一定已送达”。此次版本更新正是为了补足这些场景。

遇到证书警告时，不应通过永久跳过校验来恢复访问。否则客户端即使具备新的信任决策，也无法发挥作用。

站长：核对完整证书链，而不只看证书是否到期

先查证书供应商与浏览器厂商公告，再检查站点实际提供的链和目标客户端构建出的链。若链至被移除的根，应按供应商方案迁移到仍受目标客户端信任的其他层级，并验证部署结果。Google 已明确要求相关站长及时替换证书链。站长处置要求

下面是 Linux / macOS shell 下的只读诊断示例，将 example.com 换成自己的域名：

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts \
  -verify_hostname example.com \
  -verify_return_error </dev/null

-servername 设置 SNI，-showcerts 展示服务器发送的证书，后两个验证选项用于检查主机名并在验证出错时中止。参数含义见 OpenSSL 官方文档。

但输出不能独自充当此次事件的“安全证明”：服务器通常不发送根证书；客户端还可能构建替代链。即使 OpenSSL 校验成功，也只说明当前这套验证配置和信任库的结果，不能证明 Firefox、Chrome 和移动端会作出相同判断。

如果网站使用 CDN，还要分别检查“浏览器到 CDN 边缘”和“CDN 到源站”。两个连接可能使用不同证书，检查源站文件不能代替检查访客实际收到的链。

运维人员：找到应用真正读取的信任来源

排查时至少记录以下信息：

检查项	要弄清的问题
浏览器、系统或运行时	由谁维护信任库，是否已安装相关更新？
自带 CA bundle 的应用	是否绕过系统证书库，仍携带旧列表？
容器镜像	宿主机更新后，镜像内的证书包是否仍旧？
长期运行的进程	更新文件后，是否需要重载或重启才会读取？
自定义信任与代理	企业策略是否改变了实际验证路径？