# eMudhra中间CA泄露：浏览器阻止列表和运行时信任差距

Published: 2026-10-21

eMudhra的八个中间签名密钥被泄露，其中六个用于TLS，两个用于代码签名。在Mozilla确认、浏览器阻止和后续更新之后，本事件解释了为什么已部署的应用程序需要检查其自身的信任配置。一份独立的Tor报告显示SSH主机身份警告正在发挥作用。

Canonical: https://thedailydiff.dev/zh-CN/video/2026-10-21-emudhra-trust-gap/

## 本视频涵盖的内容

- 受损密钥属于中间签名者。根证书不受信任可以缓解证书链问题，而无需证明根私钥已被泄露。
- 浏览器的紧急阻止列表和应用程序捆绑的CA存储可以遵循独立的更新路径。检查正在运行的进程及其实际的信任配置。
- Mozilla独立确认了可恢复的私钥。报告没有描述受影响中间证书的CT条目；对其他客户端的实际滥用情况仍然未知。
- 主要版本验证了certifi 2026.10.19和Node 24.22.1，适用于所讨论的分支。自定义CA捆绑包和其他运行时分支需要进行自己的检查。
- Tor研究人员的333个中继账户涉及10月初发生的事件，并于10月20日发布。大约百分之十是中继数量，而不是截获流量的测量。
- 仅凭网络超时无法确定证书验证是否拒绝了受损的证书链。保留验证并区分传输错误和认证失败。

## 章节

- 0:00 为什么固定的浏览器会让应用程序暴露？
- 0:49 中间密钥授权什么？
- 1:22 哪些已证实，哪些仍未知？
- 2:03 为什么浏览器和运行时意见不一？
- 2:58 哪些更新已到达Python和Node？
- 3:33 Tor主机密钥警告捕获了什么？
- 4:10 如何检查已部署的修复程序？
- 4:51 什么获得了“NEEDS REVIEW”的印章？

## 翻译的文字记录

译自英文原版旁白。可用音频和字幕由 YouTube 控制。

### 为什么固定的浏览器会让应用程序暴露？

0:00 eMudhra浏览器修复听起来像是“一切正常”。 八个被泄露的签名密钥仍然使软件面临过时的信任决策。 在此视频中，谁可以签名？ 为什么客户端意见不一？ 哪个更新真正到达了您的应用程序？ 一个微小的依赖项维护着自己的信任列表。 我们将回到决定您的修复是否到位的过程。 今天是10月21日星期三，这里是The Daily Diff。

0:22 eMudhra是一个证书颁发机构。 它签署数字证书，帮助软件验证网站和 服务。被泄露的密钥包括六个用于网络连接的密钥和两个用于 签名软件的密钥。中间证书是受信任的根证书下的委托签名者。 星期五，一位名叫韦恩的记者向根程序发送了证据。 到星期二，公共事件页面正在解释清理工作。 今天，开发人员将发现他们的完美 正常应用程序收集了多少份信任。

### 中间密钥授权什么？

0:49 这是普通的证书链。 一个站点提供一个证书，一个中间证书签署它， 您的客户端沿着证书链找到它已经信任的根证书。 根证书是您的本地起点。 控制中间证书私钥的人可以根据该权限进行签名。 数学上有效的签名可能有一个完全不可信的签名者。 验证者需要一种在泄露后撤销信任的方法。 韦恩签署了消息，“我们这里有问题，韦恩”，

1:12 每个密钥都如此。 Mozilla验证了密钥控制，然后独立恢复了密钥。 紧急响应始于一句话，听起来好像有人注意到 办公室打印机在冒烟。

### 哪些已证实，哪些仍未知？

1:22 公开报告称，这些密钥生成不正确，可以从 去年4月创建的证书中恢复。 对其他软件的实际滥用情况仍然未知。 可恢复的签名权限在没有虚构受害者列表的情况下也足够紧急。 这里有一个重要的限制。 报告没有发现 在此期间这些中间证书的证书 透明度条目。

1:42 它说强制执行透明度的浏览器不可能通过 此途径受到攻击。这种额外的浏览器检查有助于解释为什么仅凭标题 就夸大了情况。 eMudhra告诉Mozilla，大约有3万个证书需要迁移到 另一个证书链。这些是正常运行的服务，其所有者必须在清理期间更换证书。 清理工作。 某个地方，一个日历邀请刚刚变成了一个生产依赖。

### 为什么浏览器和运行时意见不一？

2:03 浏览器供应商分发紧急阻止列表。 报告记录了Firefox和Chrome在周五的行动， 随后是Apple和Microsoft。 这些客户端可以在识别其根证书的同时拒绝受损的中间证书。 根证书。该规则与您的应用程序捆绑包是分开传输的。 有些客户端会根据受信任的根证书检查证书链，而不会使用紧急 撤销信息。颁发机构可以发布撤销信息， 该客户端可以继续接受证书链。

2:27 当访问者阅读标志时，在门上贴标志效果更好。 Mozilla表示，一些Android配置文件在启动时未能应用更新的阻止列表。 Firefox 158.02中发布了一个修复程序。 所以也要保持浏览器更新。 该公告无法清点您的手机。 当客户端缺乏更严格的阻止时，维护者可以移除信任锚点。 Mozilla的帖子描述了对emSign ECC根证书（第三代）的紧急不信任。 从信任存储中移除根证书会阻止依赖于它的证书链，

2:54 即使根私钥本身从未被泄露。 Python最新的certifi版本是一个下游更新。

### 哪些更新已到达Python和Node？

3:01 其提交还恢复了早期移除后未受影响的emSign根证书。 删除所有带有公司名称的东西，是维护包的糟糕替代方案。 您希望拒绝危险的证书链，而合法的 客户仍然可以正常工作。 发布历史保留了这两个决定。 安全清理工作是紧急的， 精确的，并且会因为午餐时出现的任何服务中断而被指责。 Node版本24.22.1今天发布，包含更新的

3:26 根证书。检查您自己的分支的咨询和实际CA配置。 自定义捆绑包可以更改进程使用的信任存储。 在Tor中，一位研究人员昨天发布了一份关于333个受损出口中继的报告。

### Tor主机密钥警告捕获了什么？

3:36 三个被泄露的出口中继。 截取行为始于本月早些时候。 中继在几天后被标记并关闭，然后报告才出来。 SSH警告研究人员服务器身份已更改。 他向Tor的网络健康团队报告了此事。 他们的运营商通知证实了截取报告。 这个警告正在做 认证应该做的不方便的事情

3:57 去做。大约百分之十的中继计数具有不同的容量， 导致流量份额未被测量。 Tor路由和SSH服务器身份有不同的作用。 通过受信任的通道验证更改的主机密钥， 在接受并登录之前。回到您的应用程序，从正在运行的容器或虚拟环境开始。 登录。回到您的应用程序，从正在运行的容器或虚拟环境开始。

### 如何检查已部署的修复程序？

4:12 找到它实际使用的CA捆绑包，并应用相关的维护更新。 重建并重新启动已部署的进程，以便它可以加载已更改的信任 材料。在客户端的真实环境中，使用维护者的公共测试链。 环境。将证书错误与网络超时分开。 酒店Wi-Fi连接失败是对酒店Wi-Fi的一次极好的测试。 微小的依赖项是单独捆绑的信任存储， 就像certifi一样。您的桌面浏览器永远不会编辑旧容器中的该依赖项。 容器。已部署的进程及其配置决定修复是否

4:42 已到达。这是验证更新的地方。 如果您宁愿阅读而不是听我讲，那么每日摘要每天早上都会免费发送到您的收件箱。 每天早上都会免费发送到thedailydiff.dev，链接在下方。

### 什么获得了“NEEDS REVIEW”的印章？

4:51 所以今天的结论是NEEDS REVIEW。 我希望在任何人关闭此事件之前检查已部署客户端的信任。 订阅，点击铃铛，并在评论中告诉我您是否会给它盖上 不同的章。这就是今天的摘要。 我是Axrisi的Niko。 负责任地合并。

## 来源

- [eMudhra Intermediate CA Compromise](https://emudhra.we-have-a-problem.com/) — Dennis Jackson
- [Private key compromise of eMudhra Intermediate Certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) — Mozilla Bugzilla
- [certifi 2026.10.19 release](https://github.com/certifi/python-certifi/releases/tag/2026.10.19) — certifi
- [Restore unaffected emSign roots](https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914) — certifi
- [Node 24.22.1 security release](https://github.com/nodejs/node/releases/tag/v24.22.1) — Node.js
- [Update root certificates to NSS 3.131.1](https://github.com/nodejs/node/pull/66877) — Node.js
- [How I got over 300 Tor exit nodes removed](https://kaba.cx/posts/20261020_Tor/) — KABA
- [Security incident affecting some relay operators](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/) — Tor Project network health