--- title: "eMudhra 中间 CA 弱密钥事件：Firefox 为什么紧急更新？" source: https://www.iowill.com/blog/2026/10/emudhra-intermediate-ca-weak-keys/ date: 2026-10-22 updated: 2026-10-22 tags: [Firefox, HTTPS, TLS, 数字证书, 网络安全] categories: [系统与运维] --- # eMudhra 中间 CA 弱密钥事件：Firefox 为什么紧急更新？ 2026年10月，eMudhra 的八个中间 CA 被发现使用了极弱的私钥。问题严重到浏览器厂商需要迅速封禁相关证书，再通过软件更新和信任库调整扩大保护范围。 Mozilla 在10月20日发布的 [MFSA 2026-111](https://www.mozilla.org/en-US/security/advisories/mfsa2026-111/) 中收录了相关问题 **CVE-2026-113470**，评级为 high，Firefox 158.0.1 包含对应保护更新。 这不是“Firefox 的加密算法被攻破”。出问题的是一组承担签发职责的 CA 密钥，以及客户端需要及时撤回对它们的信任。 本文依据截至 **2026年10月22日** 查到的公开资料整理，属于事件分析；没有对本站证书、用户服务器或受影响密钥进行攻击复现。调查仍在继续，后续结论应以公告更新为准。 ## 中间 CA、根证书与网站证书的区别 访问 HTTPS 网站时，浏览器除了协商加密连接，还需要判断：眼前这个服务器是否有资格代表这个域名？ 常见的证书链可以简化成： ```text 客户端信任的根 CA ↓ 签发 中间 CA ↓ 签发 网站的 TLS 证书 ``` 网站证书用于证明网站身份，中间 CA 则有继续签发证书的权限。因此，中间 CA 私钥失去安全性，影响不只是某一台网站服务器。 本次需要分开的三个概念是： | 概念 | 含义 | | --- | --- | | 中间 CA 私钥可被恢复 | 攻击者可能获得签发能力，这是此次事件的核心 | | 中间 CA 证书被吊销或封禁 | 客户端应拒绝继续接受相关签发链 | | 根证书被移出信任库 | 进一步撤回信任，可能影响该根下其他正常证书链 | **移除根证书不能直接证明根私钥也被窃取。** eMudhra 表示根私钥未受影响；这属于其公开声明中的范围说明，不等于整个调查已结束。[eMudhra 事件声明](https://emudhra.com/en/post/certificate-security-incident) ![根CA、中间CA与网站证书的层级及本次弱密钥所在位置](https://img.iowill.com/file/%E7%B3%BB%E7%BB%9F%E4%B8%8E%E8%BF%90%E7%BB%B4/eMudhra%E4%B8%AD%E9%97%B4CA%E5%BC%B1%E5%AF%86%E9%92%A5%E4%BA%8B%E4%BB%B6/body1.png) 图为概念示意，根证书移除不代表根私钥泄露。 ## 私钥为什么会弱到可以恢复？ [CERT-In 的公告](https://www.cert-in.org.in/s2cMainServlet?CACODE=CICA-2026-3649&pageid=PUBADV01)指出，受影响的 P-384 私钥数值小于256，可从对应公钥迅速恢复。它同时明确：问题出在密钥生成，不能据此认为 P-384 算法本身存在漏洞。 可以把它理解成：锁具本来允许选择极大的密码空间，但实际部署时，密码只在一小撮候选值里挑选。锁具的标称规格还在，真正支撑安全性的随机性却丢了。 这也解释了为什么“私钥没有从服务器文件里被下载”不能排除失陷。如果密钥生成得足够糟，攻击者只看公开材料，也可能恢复出秘密。 这里用“弱密钥导致私钥可恢复”，比笼统写成“黑客入侵后盗走私钥”更接近已经公开的技术事实。 至于具体流程，eMudhra 在10月21日的更新中称，密钥生成仪式中的 wrap/unwrap 环节产生了另一组弱密钥，并被错误用于后续流程；该公司同时说明，确切根因仍待确认。因此，这一解释应标为**厂商调查中的说明**，不能写成已经完成的独立审计结论。[eMudhra 最新更新](https://emudhra.com/en/post/certificate-security-incident) ## 哪些风险成立，哪些说法越过了证据？ Mozilla 的 [Bugzilla 2083449](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449)记录了八个受影响的中间 CA，其中六个用于 TLS，另两个用于代码签名。不能把八个全部称为网站证书签发 CA。 对 TLS 来说，主要风险是攻击者利用可恢复的签发密钥，为不属于自己的域名制作伪造证书。如果客户端仍然信任该链，且攻击者能截获或引导网络连接，就可能冒充网站。私钥可恢复并不自动赋予攻击者拦截所有网络流量的能力。[Mozilla 安全博客](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/) 同样，不能由此得出“以前所有 HTTPS 流量都能解密”。CA 签发密钥和连接协商出的流量密钥承担不同职责；TLS 1.3 中使用临时密钥交换的握手，还提供相应的前向保密性质。拿到 CA 签发密钥，不等于拿到历史连接的会话秘密。[TLS 1.3 标准 RFC 8446](https://www.rfc-editor.org/rfc/rfc8446.html) 另外两条范围信息也要保留出处： - eMudhra 表示，这些中间 CA 没有签发终端实体证书，绝大部分没有投入生产。这是厂商披露的情况，不能单凭这一点证明不存在任何未发现的恶意行为。[厂商声明](https://emudhra.com/en/post/certificate-security-incident) - Google 表示，在其封禁前，没有记录到链至相关六个 TLS 中间 CA 的证书进入证书透明度日志，因此对强制执行 CT 的客户端有额外保护。这一判断有明确的客户端条件，不能外推到所有旧系统和应用。[Google 安全博客](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/) 所以，风险很严重，但“全球网站证书全部失效”“所有加密通信已被监听”都不是这些资料能够支持的结论。 ## Mozilla 为什么先封禁，再发 Firefox 更新？ 这次处置不是从10月20日发布新版本才开始的。 按照 [Mozilla 公布的时间线](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)，它在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](https://www.mozilla.org/en-US/security/advisories/mfsa2026-111/) 对应版本与公告如下。这里列的是此次公告的修复版本，不代表永远应停留在这些版本；后续使用受支持渠道的更新版本即可。 | 分支 | 此次修复版本 | 公告 | | --- | --- | --- | | Firefox | 158.0.1 | [MFSA 2026-111](https://www.mozilla.org/en-US/security/advisories/mfsa2026-111/) | | Firefox ESR 153 | 153.5.1 | [MFSA 2026-112](https://www.mozilla.org/en-US/security/advisories/mfsa2026-112/) | | Firefox ESR 115 | 115.43.1 | [MFSA 2026-113](https://www.mozilla.org/en-US/security/advisories/mfsa2026-113/) | 发布前复核还发现一个后续修复：Mozilla 在 [Bugzilla 2083449 的评论29](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c29)中说明，部分 Android 配置在启动时没有应用更新后的封禁列表，修复已随 **Firefox Android 158.0.2** 推送；[官方发布说明](https://www.firefox.com/en-US/firefox/android/158.0.2/releasenotes/)也确认了这项启动加载修复。因此 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 公告](https://www.cert-in.org.in/s2cMainServlet?CACODE=CICA-2026-3649&pageid=PUBADV01) Google 则先通过 CRLSet 按受影响公钥的 SPKI 哈希封禁，并宣布移除 Chrome Root Store 中的相关根。其公开计划是让根移除于 **2026年10月27日美国太平洋夏令时上午**覆盖依赖该根库的设备。截至本文资料截止日，这仍是预告，不能写成已全量完成。[Google 公告](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/) 这也带来可用性问题：弱中间 CA 被封禁，与整条根信任被撤回，覆盖范围可能不同。网站原先的链即使没有经过那六个 TLS 中间 CA，也可能因为终点根证书被移除而失败。 ![远程封禁、软件更新与信任库调整三条应急路径及截至10月22日的进展](https://img.iowill.com/file/%E7%B3%BB%E7%BB%9F%E4%B8%8E%E8%BF%90%E7%BB%B4/eMudhra%E4%B8%AD%E9%97%B4CA%E5%BC%B1%E5%AF%86%E9%92%A5%E4%BA%8B%E4%BB%B6/body2.png) 三条路径覆盖不同客户端，Android后续修复与Chrome计划时间应分别核对。 ## 普通用户和站长分别做什么？ ### 普通用户：更新实际使用的客户端 按浏览器及系统提供的正常渠道更新，并完成必要的重启。企业管理的 Firefox 还应检查策略和远程配置分发是否正常；“安装了 Firefox”不等于“远程封禁列表一定已送达”。此次版本更新正是为了补足这些场景。 遇到证书警告时，不应通过永久跳过校验来恢复访问。否则客户端即使具备新的信任决策，也无法发挥作用。 ### 站长：核对完整证书链，而不只看证书是否到期 先查证书供应商与浏览器厂商公告，再检查站点实际提供的链和目标客户端构建出的链。若链至被移除的根，应按供应商方案迁移到仍受目标客户端信任的其他层级，并验证部署结果。Google 已明确要求相关站长及时替换证书链。[站长处置要求](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/) Linux / macOS shell 下的只读诊断示例如下，将 `example.com` 换成自己的域名： ```bash openssl s_client \ -connect example.com:443 \ -servername example.com \ -showcerts \ -verify_hostname example.com \ -verify_return_error