印度 CA eMudhra 怎么做到的？私钥就是数字4，八张中间 CA 退出 SSL/TLS

导语：一家签发过 6000 多万张证书的机构，被曝出八张中间 CA 的私钥小到可以直接背出来，其中一把的私钥就是数字 4。五天后，董事会宣布退出全球 SSL/TLS 业务。

证书链上的那个”4″

10 月 17 日 20:06 UTC，Mozilla 收到一名社区成员的报告：eMudhra 八张中间 CA 证书的私钥已泄露，攻击者可以用它们伪造任意网站的 HTTPS 证书。发现者同一天把情况通报给了 Apple、Google、Microsoft、Mozilla 和 eMudhra 自己。

两天后细节被摊开，安全研究员 Scott Helme 顺手做了一次验算：他在自己的笔记本上，从公开证书里把八把私钥全部恢复了出来，耗时不到一秒。其中一把的私钥值是 4——不是”以 4 开头再跟几百位随机数”，就是 4。另外几把是 56、66、115、155、156、230 和 237。这不是被黑的结果，是自己在生产弱密钥。

一秒破一把锁，因为根本不用破

一把 P-384 私钥应该是 384 位随机数，可能性约 10^115 量级，没人会去穷举它。但椭圆曲线公钥有个特性：Q = d·G，只要 d 足够小，从 1 开始一路算点乘，撞上 Q 就说明私钥找到了。八把私钥的值全部小于 256，最坏情况只要算 256 次。量子计算机是完全用不上了。

八张里有六张是网站 TLS 中间 CA，挂在 eSign ECC Root CA – G3 这条根下面。eMudhra 表示，这八张中间 CA 从未签发过任何终端证书，自身系统也没有被入侵——签发流程在源头自己掉链子。

三万张证书的搬家通知

Mozilla 当晚就在 Firefox 里停信了这批证书。Chrome 稍慢，但 Google 给站点的措辞没有商量余地：必须立刻换一张来自其他 PKI 层级的证书，变更预计 10 月 27 日太平洋时间早上推送。

按 Chrome 通过公开 CT 日志统计，截至 10 月 21 日，这颗 ECC 根底下还挂着约 30,800 张未过期证书，其中 99.9% 由 InCommon 签发。InCommon 是 Internet2 为高校体系提供的证书服务，而它刚好在 2026 年 4 月到 7 月之间，把服务迁到了 eMudhra 的 CertiNext 平台——迁移刚落地，脚下的地板就要被抽走。康奈尔大学自己数出 300 多张受影响的证书，密歇根大学建议先转到 Let’s Encrypt。

eMudhra 自己的估算是约 3 万张证书需要迁移，其中 97% 通过 ACME 协议签发。这大概是整场事故里唯一的好消息，批量替换可以自动化。

审计通过了，然后密钥是 4

面对质疑，eMudhra 的公开回应大致是三层：通过独立审计，密钥弱化是一个”小的、难以解释的错误”，社交媒体的热度和 SSL/TLS 业务只占公司全球收入约 1% 的地位并不相称。

技术上没说错，姿态上则是经典的甩锅三连：不是我们的锅、审计没问题、真正该追究的是关注度。作为旁观者我更在意另一件事——这类问题从发现到证实的成本几乎为零。任何拿到证书的人都可以把 ECC 私钥标量从 1 枚举几万次，看是否与公钥匹配，跑完不到一分钟，脚本不到十行。一家签发过几千万张证书的 CA，发布前跑一遍这种自检，成本大概比一次外部审计还低。

运维清单

检查证书是否位于 eSign ECC Root CA – G3 之下：openssl s_client -showcerts -connect 你的域名:443
G1 RSA 根暂未被拉黑，可先用 RSA 证书过渡（康奈尔就是这么做的），长期迁往其他公共 CA
97% 是 ACME 签发的，直接上 ACME 客户端批量续签，别手搓
把根证书清单纳入监控、订阅 CT 日志变化，避免被别人的根变更”惊喜”到
参考 Geoffrey Huntley 的自动化排查思路，用脚本把资产清单里的证书链统一扫一遍