浏览器那边，10 月中旬就把这张证书拉黑了。可你真正该担心的不是浏览器——是那些不查吊销名单、自带信任库的客户端。

事情本身不复杂：一家叫 eMudhra 的 CA，2025 年 4 月做密钥生成仪式时随机性不足，导致它的中间 CA 私钥可以从公开证书里算出来。涉及 8 个中间 CA，6 个签 TLS 证书、2 个签代码，加上 Sectigo 的交叉签名，一共 16 张证书。

各家浏览器的反应挺快：Chrome / Firefox 10/17 当天就拉黑，Apple 10/19，微软 10/20；Chrome 对 emSign ECC Root CA - G3 的移除在 10/27 全量生效；eMudhra 自己在 10/22 宣布退出 TLS 证书业务。听到这儿，好像「等浏览器更新就行」。

问题是，靠浏览器更新兜底的前提，是那个客户端会去查吊销状态、并且用的是浏览器那套信任库。而现实里有这么一批东西不满足这个前提：

  • 容器镜像里 baked 进去的根证书；
  • 构建流水线（CI 里跑的 curl、wget、pip、npm，它信的是镜像里的信任库）；
  • 用 Go 写的程序（自带一份根证书，不读系统库）；
  • 嵌入式设备和 IoT——装完基本不更新。

这些地方，浏览器把 CA 拉黑，对它们一点影响都没有。它们照样信任那张已经能被伪造的证书。

修复版本：Go 用 1.27.3 / 1.26.10（CVE-2026-111943，需要注意这个修的是 Go 自己内置的信任库，得重新编译，光升运行环境没用）；NSS 升到 3.131.1；Firefox 158.0.1。至于容器和构建机，得自己把那张根证书从信任库里剔掉——别指望基础镜像自动跟进。

一条自查：openssl s_client -connect 域名:443 -showcerts </dev/null 2>/dev/null | grep -iE 'emSign|eMudhra'，命中就是这张证书链。

这事跟之前那次 GoAhead 的「装了吊销名单却从不检查」 是同一类毛病：吊销这套机制，从 CA 拉黑、到客户端真的去查，中间隔着好几段，任何一段没接上，链条就是断的。浏览器堵上了，不代表你所有会发起 TLS 的东西都堵上了。

原始来源：The Hacker News《Eight eMudhra Intermediate CA Keys Compromised》：https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html