eMudhra CA证书事件

2026年10月中旬，一场突如其来的证书安全事件在全球网络安全圈引发轩然大波。印度数字证书机构eMudhra的8张中间CA证书被曝出存在致命安全缺陷——其P-384椭圆曲线私钥竟然全部小于256，其中最夸张的一个私钥是数字4。

这是一次低级到令人难以置信的人为失误，直接导致全球主流浏览器集体紧急封锁，约3万张网站证书面临信任危机，最终迫使这家拥有17年历史的上市公司彻底退出全球SSL/TLS证书业务。

1、事件时间线

整个事件的周期很短，从问题披露到厂商响应，再到业务终止，前后仅一周时间：

• 10月17日：独立安全研究员向Mozilla、Google等机构报告，发现eMudhra旗下8张中间CA证书的私钥存在密码学缺陷。同日，eMudhra撤销了全部8张受影响的中间证书；Chrome通过CRLSet封锁了6张TLS中间证书；Firefox通过OneCRL机制完成全网封锁，全程不到3小时。

• 10月19日：苹果在Safari浏览器中添加对应保护措施。

• 10月20日：Mozilla发布官方公告，宣布将从NSS信任库中移除签发这些中间证书的根证书——emSign ECC Root CA – G3；微软也跟进采取封锁措施。

• 10月21日：eMudhra发布官方声明，确认8张中间证书存在问题，但强调基础设施未遭入侵、无数据泄露，且受影响证书大多未投入生产使用。印度电子和信息技术部（MeitY）成立特别调查组介入调查。

• 10月22日：eMudhra发布公告，董事会决定自愿退出全球SSL/TLS证书业务，同时宣布为客户提供Sectigo签发的替代证书作为过渡方案。

2、事件根源：人为操作失误

正常情况下，P-384椭圆曲线的私钥应该是一个384位的随机大整数，密钥空间极其庞大，暴力破解在计算上完全不可行。但eMudhra这8张证书对应的私钥数值全部小于256，分别是：4、56、66、115、155、156、230、237。

换句话说，攻击者只需要尝试最多256次，就能命中正确的私钥，实际在普通电脑上毫秒级就能完成。

根据eMudhra的内部调查，问题源于2025年4月30日的一次密钥生成仪式：

1. 当时使用符合FIPS 140-2 Level 3标准的硬件安全模块（HSM）生成了正确的强密钥
2. 同时有一套用于迁移测试的弱密钥也被生成出来
3. 由于两套密钥标签相似，技术人员在最终部署时错误地选用了测试用的弱密钥
4. 这个错误在之后的18个月里，经过了两轮审计都没有被发现

这是一个典型的”测试配置流入生产环境”事故，也是运维领域最经典的低级错误之一。

3、事件风险初评

掌握了中间CA的私钥，意味着攻击者可以为任意域名签发浏览器信任的伪造HTTPS证书，进而实施中间人攻击，窃取或篡改用户与网站之间的加密通信数据。

不过有几个关键事实降低了实际风险：

• 8张中间证书中，只有1张曾部署于生产环境
• eMudhra称没有证据表明这些中间证书曾签发过终端用户证书
• 目前没有公开证据显示这些弱密钥在被披露前已被恶意利用
• 浏览器厂商响应极快，数小时内就完成了全网封锁

但风险依然存在于那些不检查证书吊销状态的老旧系统、嵌入式设备、IoT设备和部分服务端应用中——它们不会自动接收OneCRL或CRLSet更新，可能仍然信任这些有问题的证书。

4、为啥要连根证书一起移除？

很多人不理解：既然已经撤销了8张中间证书，为什么Google和Mozilla还要把上层的G3根证书也移出信任库？

原因很现实：大量设备和软件根本不检查证书吊销状态。

仅靠吊销机制，只能保护及时更新吊销列表的设备。而全球有数不清的老旧服务器、物联网设备、企业内网系统，它们从不更新CRL，也不支持OCSP查询。对这些设备来说，吊销证书等于没吊销。

直接移除根证书是更彻底的解决方案——从信任根源上切断整个信任链，无论设备检不检查吊销，都不会再信任由这根证书签发的任何证书。

根据eMudhra向Mozilla提供的数据，大约有3万张有效证书链向G3根证书，这些证书都需要在根证书正式移除前完成迁移。

5、eMudhra为何直接选择退出全球TLS证书业务？

事件爆发后仅5天，eMudhra就宣布彻底退出全球TLS证书业务，这个决定让很多人感到意外。背后主要有三重考量：

1. 业务占比极低：全球TLS证书业务仅占eMudhra总收入的1%左右，投入产出比本身就不高。

2. 信任重建成本过高：CA机构的核心资产就是信任。发生如此严重的低级失误后，要重新通过各大浏览器根程序的审计、重建行业信任，需要投入的时间和资金成本极其高昂。

3. 业务重心不同：eMudhra的核心业务是印度本土的数字签名证书（DSC）和电子签章服务，服务于印度政府和企业的数字化流程，这部分业务不受此次事件影响。

换句话说，这是一次理性的止损——与其在一个占比1%的业务里耗费巨大代价修复信任，不如干脆砍掉，聚焦核心市场。

6、给网站管理员的行动建议

如果你的网站使用了eMudhra/emSign签发的TLS证书，需要尽快确认并采取行动：

1. 检查证书链：查看你的证书是否链向emSign ECC Root CA - G3，如果是，必须尽快更换。
2. 申请替代证书：eMudhra已宣布为客户免费提供Sectigo签发的替代证书，可通过CertiNext账户或联系客服申请。
3. 注意时间节点：Chrome将于10月27日正式从根存储中移除G3根证书，在此之前必须完成证书更换。
4. 检查后端服务：不要只检查浏览器端，还要检查API调用、服务间通信、移动应用等场景是否信任该根证书。

7、事件带来的行业启示

这场闹剧般的事故，再次给整个PKI行业敲响了警钟：

信任体系的脆弱性，往往不在高深的密码学算法，而在最基础的工程实践。 再强大的加密算法、再昂贵的硬件安全模块，也抵不过一次人为的配置失误。

同时我们也看到，全球浏览器根程序的应急响应机制已经相对成熟——从收到报告到全网封锁，Mozilla只用了不到3小时，Google也在同一天完成处置。这种快速响应能力，是互联网安全防线的重要组成部分。

最后，这件事也提醒所有企业：测试环境与生产环境的隔离，怎么强调都不过分。 一个看似不起眼的配置错误，放在CA机构这种信任核心节点上，就可能演变成波及全球的安全事件。