8 张中间 CA 证书私钥”裸奔”一年多：eMudhra 泄露事件全解

10 月 17 日，安全研究员 Wayne 给各大根信任计划团队发了一个压缩包，里面是一段话用 8 个不同私钥分别做的签名——话的内容是：”We have a problem here”（我们遇到麻烦了）。能签名，就证明私钥在手。泄露方是印度 CA 机构 eMudhra 的 8 张中间 CA 证书，它们挂在 Mozilla、微软、苹果、Chrome 四大根计划之下，任何拿到私钥的人都可以签发任意网站的证书，冒充任何 HTTPS 站点。

最离谱的不是被黑，是私钥”算”出来的

随着细节公开，事件的性质比”CA 被入侵”更荒诞：私钥不是被偷的，而是 CA 自己生成错了。eMudhra 的中间证书私钥生成方式存在缺陷，以至于任何人从公开的证书本身就能把私钥恢复出来。换句话说，从 2025 年 4 月这些证书创建那天起，密钥事实上就是公开的——只是没人去算。

这个细节值得所有做安全的人后背发凉。我们习惯假设私钥躺在 HSM（硬件安全模块）里固若金汤，密码学链条的弱点总在协议和实现。结果这次是源头本身：密钥生成的随机性出了问题，整条信任链从第一块砖就是歪的，而一歪就是 18 个月。

为什么浏览器用户基本安全，其他客户端在裸奔

一个关键的安慰来自证书透明度日志（CT）：这 8 张中间 CA 在风险窗口期内没有签发记录进入 CT 日志。而 Firefox、Chrome、Edge、Safari 这些浏览器强制校验 CT——攻击者就算拿到私钥签了假证书，浏览器也会因为证书不在 CT 日志里而拒绝。所以主流浏览器用户在这 18 个月里理论上没被攻击过。

问题在于浏览器只是 HTTPS 客户端的一部分。curl、Java 运行时、移动 App 的 SDK、嵌入式设备、CI 流水线里的构建工具——大量客户端根本不消费吊销信息，也不校验 CT。对这些系统来说，唯一的修复路径是更新信任库：Ubuntu、Debian 已经发布了 patched 版 ca-certificates 包，各语言运行时也在跟进。如果你的服务器镜像半年没重建过，大概率还信任着这 8 张废证书。

被忽略的问号：攻击者来过了吗

事件披露方坦承：不知道是否有攻击者利用了这个缺陷。私钥公开可算意味着”谁都可能已经拿到”，而 CT 日志只能证明浏览器生态没受害，无法证明其他客户端没被中间人过。这 18 个月里，某个 IoT 设备的固件更新、某条跨境 API 调用有没有被冒充劫持过，理论上已经无从查证。

值得玩味的是发现方式：不是 eMudhra 自查发现，而是外部研究员算出私钥后主动通报。HN 讨论区 574 分的热度里，一条评论点出了结构性问题——全球受信任的中间 CA 数以百计，没有独立机制能验证每张证书的私钥生成质量，信任体系默认”CA 不会犯这种低级错误”。eMudhra 不是第一个翻车的 CA（历史上误签、漏报事件一抓一把），但”私钥可以从证书本身推导”这一条，把信任的底线又压低了一层。

Takeaway：普通用户更新浏览器和系统即可；但运维和开发者请务必重建容器基础镜像、升级 ca-certificates 包——你的 curl 可能还在信任那 8 张废证书。更长期的启示：对 IoT 和嵌入式这类”永不更新”的客户端，证书信任链的每一次 CA 事故都是一次生存测试，值得把”信任库可更新性”重新放回采购清单。