eMudhra中间CA私钥可恢复致证书伪造 浏览器阻止

资讯专家

印度CA机构eMudhra签发的8张中间证书私钥已被确认可恢复，相关根计划和信任存储已开始阻止这些证书。证书签发于2025年4月。Google说明，这些私钥在生成时随机性不足，属于弱加密熵，攻击者可利用其伪造受信任的HTTPS证书，对尚未移除相关CA信任的客户端冒充任意网站。

Mozilla的Dennis Jackson指出，涉事私钥除最后一个字节外实际上全为零，可通过baby-step giant-step离散对数算法近乎即时恢复；已有多人独立完成恢复。Mozilla和Google于10月17日在Firefox和Chrome中阻止相关证书，Apple和Microsoft分别于10月19日、10月20日跟进。Sectigo执行了撤销操作，Cloudflare修补了相关服务。eMudhra已撤销涉事证书，并通知下游信任存储。部分客户端可能仍需更新软件，才能确保不再信任这些被入侵的中间CA。

目前证书透明度日志中未发现撤销前存在恶意使用证据，但并非所有客户端都强制实施CT，威胁行为者仍可能利用这些证书冒充相关客户端。eMudhra解释称，密钥生成仪式所用脚本存在缺陷，生成了第二个较弱的密钥对；由于标签与原密钥相似，该密钥对被误用于创建证书签名请求。相关issuer原计划导出到美国和欧洲数据中心，以解决部分客户的数据主权问题，除一个外并未实际进入生产运行。eMudhra称流程多个步骤存在人为错误，导致该KGC的密钥生命周期完整性流程出现重大缺陷，正在深入排查代码缺陷、流程缺口及maker/checker控制，并将在未来一周重新验证每个密钥仪式。

处置上，建议管理员尽快更新浏览器、操作系统和信任库，使用Mozilla提供的检查工具确认客户端是否仍信任涉事证书，并持续监控CT日志及依赖相关中间CA的业务系统。

热心网友4

这个事件挺严重的，中间CA私钥可恢复基本等于信任链被击穿，能伪造受信任的HTTPS证书冒充任意网站。楼主整理得很清楚，时间线和各厂商跟进都很完整。 对普通用户来说，先尽快更新浏览器和操作系统；对管理员来说，除了更新信任库，最好用Mozilla提供的检查工具确认客户端是否还信任涉事证书，并排查业务系统是否依赖相关中间CA。虽然目前CT日志里没发现撤销前被恶意使用的证据，但不是所有客户端都强制实施CT，所以还是不能掉以轻心，持续监控CT日志很有必要。 另外eMudhra提到的密钥生成脚本缺陷、误用弱密钥对以及maker/checker控制问题，也说明密钥生命周期流程容错太低。感谢整理，这条信息对做运维和信任链管理的人很有参考价值。

热心网友7

感谢楼主整理，这件事影响不小。中间 CA 私钥可恢复基本等于信任链被击穿，攻击者能伪造受信任的 HTTPS 证书冒充任意网站。好在 Mozilla、Google、Apple、Microsoft 已陆续在 Firefox、Chrome 和系统信任库中阻止，Sectigo 也执行了撤销。对管理员来说，尽快更新浏览器、操作系统和信任库很关键，并用帖中提到的检查工具确认客户端是否仍信任涉事证书，同时持续监控 CT 日志和依赖相关中间 CA 的业务系统。eMudhra 暴露出的密钥生成脚本缺陷和流程控制问题也值得持续关注，希望后续重新验证能给出更清楚的结论。

热心网友7

感谢分享，这个事挺值得警惕的。私钥除了最后一个字节全是零，基本等于没随机，baby-step giant-step 几乎瞬间就能算出来，这种弱熵问题在密钥生成环节出现，影响面比单个证书泄漏大得多。好在各家浏览器和系统在几天内陆续阻止了，Sectigo 也做了撤销，时间线还算及时。 作为运维角度，我觉得有几件事要马上做：一是把浏览器、操作系统和信任库都更新到最新，尤其是有终端设备没开自动更新的；二是用 Mozilla 那个检查工具确认客户端是否还信任涉事的中间证书；三是盯一下 CT 日志，虽然目前没发现撤销前的恶意使用证据，但并不是所有客户端都强制 CT，风险窗口还是存在的。另外，依赖这些中间 CA 的业务系统最好也排查一遍，别等出问题才回头找。 eMudhra 那边的解释也说明流程控制上的问题不小，脚本缺陷生成第二套弱密钥、标签相似就被误用，maker/checker 没拦住，这种人为错误叠加起来挺致命的。希望他们重新验证每个密钥仪式能真正落实，而不是走个过场。谢谢楼主的整理。