航拍的公路立交桥纵横交错

一把能从证书里"捡回来"的私钥

十月十七日，一位署名 Wayne 的研究者做了一件很简单的事：用八张 eMudhra 中间证书的私钥，各自签了一句同样的话——"我们这儿出问题了"，附上签名公开，当天报给各家根证书计划团队。

能签得出来，就说明私钥不在 CA 手里，而在所有人手里。原因不是被黑，而是生成方式本身有问题：这些中间证书的密钥对被错误地生成，任何人都能从证书本身把它还原出来。这个错误从 2025 年 4 月证书签发时就已经存在。

中间证书被攻破意味着什么：拿到它的人可以给任意网站签一张 "可信" 的证书，做中间人几乎不会被拦。它上挂的根，是 Mozilla、微软、苹果和 Chrome 四大根证书计划都信任的那几个。

浏览器七天修完，另一半世界还在等

响应其实不慢。Firefox 和 Chrome 从十七日起就屏蔽了这批证书，微软平台二十日，苹果产品二十二日。Linux 各大发行版的证书包、Python 的 certifi、Node.js、Go、Rust 的根证书包，陆续发了更新。

慢的是不出现在浏览器里的那一半。项目方列了清单：自己带证书包的 curl、打包成桌面应用的 Electron 程序（比如 Slack、Discord）、还有各种锁死版本的运行时。它们不消费吊销信息，只能靠软件发版解决，而发版要等。

苹果这一条最刺眼

十月二十八日同一批人又发了一篇：macOS 自带的 git、curl、python3 仍然信任这批被攻破的证书。原因很具体——这些命令行工具拿 /etc/ssl/cert.pem 验证书，不做吊销检查。更麻烦的是二十六日发布的 macOS 27.2 没修这个问题，反而把用户手动删掉的根证书恢复了回去。

苹果已经在官方指引里说明：这个文件可能在每次系统更新后被覆盖，开发者要反复检查。也就是说，靠手工打补丁这条路，每次系统升级都要重来一遍。

今天就能做的一次检查

项目方留了检测入口。在服务器或自己的 Mac 上跑一句命令，目标指向 dv-g3b-emudhra.we-have-a-problem.com：报证书错误，说明你不信任这批中间证书，是安全的；能正常返回内容，说明信任库还是旧的，需要更新。

企业侧的动作清单并不复杂：升级服务器上的 ca-certificates，升级自己发版的客户端，对离线和锁版本的机器手工屏蔽，Java 的 cacerts 单独处理——在 Debian、Ubuntu 上，系统信任库更新不会自动刷新它，这是个老问题。

对做企业数字化的启发

证书是那种平时完全看不见、出事时全链路一起出事的东西。它的依赖不写在代码里，也不写在部署文档里，而是藏在每个运行时的默认信任库中。遇到这样的新闻，最好的用法不是转发，而是顺手把自己所有服务端的根证书版本查一遍，写进运维清单。一个团队是否成熟，常常就体现在它对这类 "不会主动报错" 的依赖有没有清单。