eMudhra 八张中间证书私钥可被恢复，Mozilla 宣布移除其根证书信任
eMudhra 八张中间证书的私钥可被还原；Mozilla 已宣布移除其根 emSign ECC Root CA - G3 的信任，自带信任库的应用仍需更新。
eMudhra Limited 是总部位于印度班加罗尔的证书颁发机构（CA）。Mozilla 收到一份报告，称 eMudhra 旗下八张中间证书的私钥已经失陷，持有私钥的人可以为自己并不控制的网站签发 HTTPS 证书。Mozilla 的工程师随后也自行还原出了这些私钥。原因出在生成环节：P-384 私钥本应是随机选取的大整数，这八把的数值却都小于 256。
要点
- eMudhra 的八把私钥几乎可以瞬间还原：Ars 报道的数值是 4、56、66、115、155、156、230 和 237。研究者 Scott Helme 说，他在笔记本上从公开证书里还原出全部私钥，只用了不到一秒。
- 浏览器先封堵，其他信任库要自己跟进：Mozilla 正通过 NSS 3.131.1 移除签发这些中间证书的根 emSign ECC Root CA - G3，Chrome 表示将走类似的路径。
- 约三万张证书需要迁移：eMudhra 称，该根下约有 3 万张证书需要迁移，其中约 97% 经 ACME 签发。订户将被迁到 G1（RSA 根）下的中间证书。
背景
eMudhra 的这八张证书来自 2025 年 4 月 30 日的一次密钥生成仪式。同批 24 张中间证书分 A、B、C 三个系列，覆盖 RSA 与 P-384 两种算法。Mozilla 的调查人员在 Bugzilla 中写道，受影响的是 B、C 两个系列里全部的 P-384 密钥；A 系列已于 2025 年 5 月撤销，由 A-1 系列接替。其中一部分证书经 Sectigo 交叉签名，Sectigo 于 10 月 19 日完成了这些证书的撤销。
Mozilla 的调查人员还在另一个 bug（1970728）中发现，eMudhra 为其中六张 TLS 中间证书生成的 CRL 签名本身就无效。他们读取 Internet Archive 的快照后认为，这些 CRL 自 2025 年 5 月 23 日起就无法通过验证，但也强调这一结论仍是初步的。eMudhra 在 10 月 21 日的声明中称，这些根和签发 CA 连续两年通过独立审计，并自 2025 年中起进入浏览器信任列表。
事实部分
eMudhra 相关的时间线如下（UTC）：
| 时间 | 事件 |
|---|---|
| 10 月 17 日 20:06 | Mozilla 收到报告（由 Chrome 根计划转交），报告附有八张证书的密钥控制证明 |
| 10 月 17 日 22:59 | Firefox 的 OneCRL 撤销列表在标准配置下分发完成 |
| 10 月 18 日 09:38 | eMudhra 将八张证书标记为 caCompromise 撤销 |
| 10 月 19 日 14:55 | Sectigo 完成交叉签名证书的撤销 |
| 10 月 20 日 13:06 | Mozilla 宣布紧急移除 emSign ECC Root CA - G3 的信任 |
| 10 月 20 日 14:16 | eMudhra 表示将立即停止从该根下的所有中间证书签发 |
| 10 月 20 日 19:20 | Cloudflare 完成 CDN 与服务端零信任的缓解措施部署 |
八张证书中，六张是 TLS 证书，受 Chrome、Mozilla、微软和苹果的根计划信任；另外两张是代码签名证书，受微软信任。eMudhra 称，这些中间证书没有签发过终端实体证书，密钥在 Ultimaco 硬件安全模块中生成。它在 2026 年 10 月 19 日的 Bugzilla 回复中给出了初步根因：一次经批准、用于测试密钥包装与解包的 KGC 偏离操作，生成了第二组较弱的密钥；因为密钥标签相近，这组密钥被误用来生成证书签名请求（CSR），由其根签名，CSR 还被送往 Sectigo 做交叉签名。它也承认 KGC 脚本存在缺陷，流程多个环节有人为错误，完整根因仍在复核。测试站称，CT 日志中自 2025 年 4 月以来没有这些中间证书的记录，因此强制执行 CT 的浏览器不可能遭到攻击。但它也承认，许多浏览器之外的客户端并不执行 CT，攻击者是否利用过这些密钥，目前并不清楚。
信任库的处理各不相同：
| 项目 | 处理 |
|---|---|
| Firefox 与 NSS | Firefox 158.0.1、ESR 115.43.1 和 ESR 153.5.1 于 10 月 20 日发布，覆盖因自定义设置而可能没收到 OneCRL 更新的少数用户；NSS 3.131.1 将移除该根 |
| Rust 的 webpki-roots | 1.0.10 版于 10 月 19 日发布，移除 emSign ECC Root CA - G3 |
| Python 的 certifi | 10 月 18 日的提交移除 emSign 根，10 月 20 日的提交恢复未受影响的根；PyPI 上有 2026.10.18 和 2026.10.19 两个版本 |
| Go | 1.27.3 与 1.26.10 于 10 月 19 日发布，含 crypto/x509 安全修复；发布说明没有点名 eMudhra，它与此事的直接关系未经证实 |
各方说法
围绕 eMudhra 的修复，Cloudflare 在 10 月 20 日的博客中写道，它 10 月 19 日约 17:00 UTC 得知此事，随即优先修补关键服务，并称尚未发现有人在其服务上主动利用这一问题。它认为浏览器可以靠 Chrome CRLSet 这类快速撤销机制“拨一个开关”完成修复，应用和服务端却要逐个更新。修补后若出现证书报错，它提醒不要通过关闭验证来解决。
iTnews 的测试落在命令行上：它发现，macOS 自带的 curl 在苹果已经阻断的情况下，仍然接受这条证书链。curl 对照的是自己的 CA 文件（macOS 上是 /etc/ssl/cert.pem），不查吊销信息。iTnews 转述 Mozilla 的 Dennis Jackson 的建议，从该文件中删除 emSign ECC Root CA - G3 和 Sectigo 的 AAA Certificate Services。Mozilla 随后在 bug 中澄清，AAA Certificate Services 不在其根库中，无需加入 OneCRL。
各平台的阻断时间说法并不一致。Dennis Jackson 维护的测试站写道，Firefox 和 Chrome 自 10 月 17 日起阻断，苹果设备自 19 日起，微软平台自 20 日起。Ars 发稿时却看到，Windows 10 上的 Edge 仍在连接 12 个存在风险的主机，微软代表只说，有可以分享的内容时会再联系。苹果的阻断时间目前只见于测试站和 iTnews，未找到苹果的官方公告。
Go 密码学维护者 Filippo Valsorda 对 Ars 说，这会是一场“比 Heartbleed 更大的清理”，长尾包括物联网设备、Docker 容器、无人维护的 Linux 机器，以及自带一份根证书副本的命令行工具。他此前也用 Go 重新实现过 NIST 曲线种子的算法（NIST 曲线种子溯源）。Ars 还指出，利用这些证书需要主动的中间人攻击，控制咖啡馆或学校网络的人比其他攻击者容易得多。
据 The Hindu BusinessLine 报道，10 月 21 日盘中，eMudhra 股价下跌 20%，在印度国家证券交易所（NSE）报 432 卢比；CNBC-TV18 也报出了同一价位。eMudhra 当天发布的声明称，其基础设施未被入侵，也没有数据泄露；全球 TLS 业务约占公司收入的 1%；公司正在直接联系可能受影响的客户签发替换证书，并与各根计划协调，同时继续调查根因。The Register 发稿时，eMudhra 尚未回应其询问。
编辑判断
eMudhra 这件事对写代码的人来说，要先弄清楚自己的程序信任哪些根证书。Python 的 certifi、Rust 的 webpki-roots、容器基础镜像和应用自带的 CA 文件，各自决定信任哪些根，修复要逐处完成。浏览器测试通过，并不能证明后台服务是安全的。
在约三万张需要迁移的证书中，约 97% 经 ACME 签发。我们判断，经 ACME 签发的证书大多能自动续期，这部分迁移应当比手工签发的证书容易。这与 Let’s Encrypt 把证书有效期缩到 64 天 的方向一致：替换越自动，越不必依赖人工。
几件事尚无定论。Mozilla 还没有还原 A 系列和 A-1 系列的 P-384 私钥，也没有检查 RSA 密钥；eMudhra 则称 RSA 签发 CA 走的是另一条路径，未受影响。eMudhra 的完整根因仍在复核，它表示将重新核验其做过的全部密钥仪式。微软平台的阻断进度说法不一。长远看，信任库是每个应用各自维护的一份静态名单。Cloudflare 也主张，信任库需要能快速接收撤销信息和 CT 密钥，而不只是增删根证书。对无人维护的长尾软件，目前还没有现成办法。
怎么试
eMudhra 的测试站 emudhra.we-have-a-problem.com 可以检查浏览器是否仍信任这些中间证书。命令行用户可以运行 curl https://dv-g3b-emudhra.we-have-a-problem.com/，测试站说明，报证书错误就表示该客户端已不再信任这张中间证书。站点还提供了第二个测试域名 dv-g3b-aaa-emudhra.we-have-a-problem.com，用同样的方法检查。编写本文时，我们在一台装有 curl 8.7.1 的 Mac 上运行了这两条命令，两次都返回 HTTP 200，证书验证通过。两张测试证书都由失陷的中间证书 EM DV TLS CA - G3B 签发，说明这台机器上的 curl 仍然接受这条证书链，与 iTnews 的测试结果一致。测试只覆盖它所走的那条验证路径，你的程序应当用自己的 TLS 路径去测。