10 月 26 日我们报道了 eMudhra 8 张中间证书私钥可被直接算出的事。之后两周又有几件跟站长直接相关的进展：Chrome 10 月 27 日把 emSign ECC Root CA - G3 移出根证书库，11 月 4 日又宣布限制另一个根 emSign Root CA - G1；Cloudflare 10 月 30 日公布了它观测到的利用情况和修补进度；Debian 10 月 31 日从 NSS 里删了 3 个 eMudhra 根；Ubuntu 11 月 5 日发现系统证书的删除一直没同步到 Java 密钥库。

Cloudflare 看到了什么

  • 8 把私钥弱到什么程度：按 Cloudflare 的比喻，本该是一个 115 位的大数，其中一把实际是 4，其余是 56、66、115、155、156、230 和 237。任何人都能从公开的证书里直接算出它们，然后给任意域名签发证书，没打补丁、也不强制证书透明度的客户端都会接受。
  • Cloudflare 在出站连接上加了记录（10 月 21 日部署完），一周里看到约 22,000 次使用这些弱密钥的 TLS 握手。三分之二是访问测试站点，剩下的几乎都是看起来由源站自己用弱中间证书签的证书。约 160 次握手里的证书写的是其他机构的域名，其中有的与消费级物联网设备有关；有一张伪造证书的签发时间是 10 月 20 日 18:19 UTC，离 Mozilla 公开事件单不到一小时。Cloudflare 说目前没有证据显示其连接被这些密钥拦截。
  • 修补进度不乐观：约 5000 万次探测显示，保持更新的新版浏览器大多已修好，但机器人流量和旧浏览器没有；Android WebView 这类内嵌浏览器仍有 30%–40% 接受这条被攻破的证书链；在大型网络里，过半探测仍然接受它，而且第一个周末之后几乎没再下降。

浏览器和系统又做了什么

  • Chrome：为了照顾不读 CRLSet 的 Chrome 根证书库使用者，谷歌把签发这些问题中间证书的 emSign ECC Root CA - G3 移出了根证书库，预计 10 月 27 日（太平洋时间）上午推到所有设备。谷歌说，证书链到 G3 的网站必须立即申请并换上新证书。
  • Chrome 11 月 4 日更新：链到 emSign Root CA - G1 的 TLS 服务器证书，只要最早的签名证书时间戳（SCT）晚于 2026 年 11 月 16 日 23:59:59 UTC，Chrome 153 及以上默认不再信任；在此之前签发的不受影响。
  • Java：Ubuntu 的 USN-9001-1 说，ca-certificates 和 Java 的集成一直有问题，从系统证书包里删掉的 CA 并没有从 JKS 密钥库里删掉，也就是说跑在 Java 上的程序可能还信任 eMudhra。修复版本：22.04 是 ca-certificates 20260816ubuntu0.22.04.2 加 ca-certificates-java 20190909ubuntu1.4，24.04 是 20260816ubuntu0.24.04.2 加 20240118ubuntu0.24.04.1，26.04 是 20260816ubuntu0.26.04.2 加 20260311ubuntu0.26.04.1。升级后要重启 Tomcat、Jenkins、Elasticsearch 这类 Java 服务才会生效。
  • NSS：Debian 的 DSA-6599-1 从 nss 里删除了「eMudhra emSign Root CA - G3」「eMudhra emSign Root CA - C1」「emSign ECC Root CA - C3」三个根，Debian 13 的修复版本是 2:3.110-1+deb13u5。用 NSS 做证书校验的程序（比如 Firefox、Thunderbird）靠的是这个包。

别忘了自带证书包的程序

很多程序不读系统证书，而是自带一份：WordPress 10 月 28 日的 7.1.4 就更新了自带的根证书包（见这篇），Python 的 certifi、Go 程序在 85 号报道里讲过。Cloudflare 的建议仍然是：升级完就测，报错了也绝不要用关闭证书校验来「解决」。证书透明度监控为什么重要，见注册局被劫持事件的报道；给自己的网站申请和续期证书，见Let's Encrypt SSL 配置教程。