你的浏览器还信着被攻破的 CA 吗
先给答案的入口：打开 emudhra.we-have-a-problem.com，点 Run check。表格里如果出现红色，说明你的浏览器还信任着那八个私钥已经泄露的 eMudhra 中间证书——理论上，你打开的任何网站都可能被换成攻击者签发的高仿站。处理办法只有一个字：更。浏览器和操作系统都升到最新版。
你的浏览器还信着被攻破的 CA 吗
先给答案的入口：打开 emudhra.we-have-a-problem.com，点 Run check。表格里如果出现红色，说明你的浏览器还信任着那八个私钥已经泄露的 eMudhra 中间证书——理论上，你打开的任何网站都可能被换成攻击者签发的高仿站。处理办法只有一个字：更。浏览器和操作系统都升到最新版。
这个检查站的原理简单到有点粗暴：它自己就用「坏掉的 CA」签的 HTTPS 证书。八个中间证书，每个开一个子域名，证书链挂在被攻破的中间证书下面。你的浏览器去连——连接失败、报证书错误，是好消息，说明你的浏览器已经把这些中间证书拉黑；页面顺利打开，红色亮起，说明你的浏览器还认这条链。命令行同理：curl https://dv-g3b-emudhra.we-have-a-problem.com/ 报证书错误=安全，顺利返回内容=你手里这个 curl 还信着坏 CA。在证书的世界里，报错是奖赏。
网站本身也有来历。发现这八个私钥泄露的研究者署名 Wayne，10 月 17 日他用每把私钥签名了同一句话：「We have a problem here - Wayne」，随证据一起交给各大根计划。这句话现在是域名：we-have-a-problem.com。证据包公开在网站上，openssl 两行命令，人人可以亲手验证。这是披露的标准姿势——不只断言「密钥弱了」，把签名放在那儿，断言和执行一起来。
浏览器这边基本已经安全。Chrome 的 CRLSet、Mozilla 的 OneCRL 和 CRLite、苹果与微软的系统级拉黑，吊销信息走各自的推送管道自动下发：Firefox 和 Chrome 10 月 17 日就拦了，苹果 19 日，微软 20 日。加上这些中间证书在证书透明度日志里没有任何记录，强制查 CT 的浏览器用户理论上从头到尾都不可能被攻击。
真正的长尾在浏览器外面。Go 上周的做法是把八个公钥哈希编进标准库，但整个非浏览器世界都要各自走一遍「发版」：检查站维护着一张「谁修好了」的名单——Ubuntu、Debian、Fedora、Arch 的系统信任包，curl 的 CA bundle，Java 全线版本，Node 三个大版本，Python 的 certifi，Rust 的 rustls-webpki，Perl、Deno、Electron，连自带信任库的 Claude Code 也在名单上各领了一个修复版本号。名单上还挂着两个 pending：Bun 和 Erlang 的 certifi。最麻烦的是 macOS：系统层拦住了，但自带的 curl、git、python3 验证证书用的是 /etc/ssl/cert.pem——这个文件不查吊销，也没有随系统更新。网站给了一条手工 awk 命令，让你亲手把坏根从这个文件里摘出去。推送的链条断在哪，信任就停在哪。
还有一个数字值得记住。检查站的服务器会记录每一次「成功握手」——每一个还信任坏 CA 的客户端连上来，统计页就多一行，带上 user-agent 和 JA4 指纹。上线二十分钟，记录约一万九千次。这些连接里有多少是没人维护的 CI 脚本、旧容器、过期运行时，无从知晓；这正是这类事故最沉默的部分——被攻破的不是某台服务器，是一段悬在半空、没人推送得到、也没人查看的信任。
参考：emudhra.we-have-a-problem.com（检测入口、证据包、修复名单、实时统计）；Mozilla bug 2083449；上午的 Go 修复帖。