CA 私钥可以被猜中之后：从 eMudhra 事件看证书信任链
内容提要
2026年10月，eMudhra的八张中间CA证书（六张TLS、两张代码签名）私钥强度不足，可从公开证书恢复；Mozilla独立确认问题出在密钥生成而非算法。弱私钥源于测试流程误用，导致中间CA私钥泄露，可签发任意域名的假证书，但攻击者需拦截连接才能冒充，且无法解密历史流量。事件后中间CA被吊销，但部分客户端不检查吊销信息，Mozilla因此移除相关根CA信任，代价是正常证书需迁移。CA的责任涵盖密钥生成、签发、吊销与根因追溯。
延伸解读
弱私钥为何能恢复：问题在生成而非算法
文章指出，八把私钥本应从 P-384 曲线的大范围中随机选取，但实际数值全部小于 256。公开证书已含公钥，攻击者只需枚举这个小范围候选私钥，算出公钥比对即可恢复。这说明 P-384 算法本身未被攻破，失效点在于密钥生成环节的随机性几乎为零。读者应区分“算法安全”与“实现安全”：前者可靠不代表后者自动成立。
中间 CA 私钥泄露的风险边界
网站私钥泄露通常只影响该站点，但不受域名范围限制的 TLS 中间 CA 私钥可被用来为任意域名签发假证书。不过，攻击者仍需拦截或控制用户连接才能实际冒充，且 CA 私钥本身不能解密过去记录的 HTTPS 流量。这划出了风险边界：信任链被滥用会扩大伪造能力，但并非无条件、无差别的全面失守。
吊销为何不总能阻断风险
事发后中间 CA 被吊销，浏览器也部署阻断措施，但不同客户端处理吊销信息的方式不一致。有的应用使用旧信任库或自带证书包，未必及时获知中间 CA 已被吊销。Mozilla 因此移除相关根 CA 信任，以保护无法单独阻断中间证书的客户端，代价是该根下正常证书需迁移。这说明吊销机制的有效性依赖客户端是否检查，不能默认全网同步生效。
从事件看 CA 责任的完整链条
文章总结，CA 的责任不止于申请时核验域名，还包括密钥生成、对象选择、证书签发、吊销信息发布，以及发现异常后能否追溯到真正原因。2025 年同一批 TLS 中间 CA 曾出现 CRL 签名验证失败，当时归因于选错密钥，却未追查到密钥生成和中间 CA 签发环节。这提示：异常若只做表面归因，可能错过更上游的系统性缺陷。
Q&A
eMudhra 的中间 CA 私钥是怎么被恢复的？
这八把私钥对应 P-384 椭圆曲线，本应从很大的合法范围内随机选取，但 Mozilla 发现它们的数值全部小于 256。公开证书中已有公钥，只需逐一尝试这个很小范围内的候选私钥，算出对应公钥并比对，就能恢复私钥。问题不在于 P-384 不安全，而在于实际选出的私钥几乎没有不可猜测性。
为什么中间 CA 私钥泄露可能被用来冒充任意网站？
网站私钥泄露通常首先影响该网站；而一个不受域名范围限制的 TLS 中间 CA 私钥泄露，则可能被用来为任意域名签发假证书。不过攻击者还需要拦截或控制用户连接才能实际冒充网站，CA 私钥本身不能直接解密过去记录的 HTTPS 流量。
eMudhra 弱密钥是怎么进入签发流程的？
eMudhra 初步解释：原本在硬件安全模块中生成了正常密钥，后来为测试密钥的封装和解封加入额外步骤；代码又产生第二组弱密钥。两组密钥标签相近，工作人员误用弱密钥生成 CSR，并由根 CA 为其签发中间 CA 证书。程序生成异常密钥与签发流程选错密钥是两道先后失守的环节。
中间 CA 被吊销后，为什么 Mozilla 还要移除根 CA 信任？
因为不同客户端处理吊销信息的方式并不一致，有的应用使用旧信任库或自带证书包，未必能及时获知某张中间 CA 证书已被吊销。Mozilla 因而进一步决定从其信任库移除相关的 emSign ECC Root CA - G3，以保护无法单独阻断中间证书的客户端，但代价是该根之下其他正常签发的证书也需要迁移。
2025 年 eMudhra 的 CRL 签名验证失败与这次事件有关联吗？
2025 年同一批中的六个 TLS 中间 CA 曾出现证书吊销列表（CRL）签名验证失败。eMudhra 当时把问题归为 CRL 生成时选错密钥；这次又解释，最初签 CRL 的是原本预期的正常密钥，而公开的中间 CA 证书却对应另一组弱密钥。那次异常至少说明证书公钥与预期使用的签名密钥不一致，但当时没有把问题追查到密钥生成和中间 CA 签发环节。
从 eMudhra 事件看，CA 的责任包括哪些方面？
CA 的责任不止于申请时核验域名，还包括密钥生成、对象选择、证书签发、吊销信息发布，以及发现异常后能否追溯到真正的原因。证书链把一次签发变成广泛可接受的信任；同样地，签发链上一个环节选错密钥，影响也不会停在那一张证书上。
