CA私钥居然是个位数：证书信任危机爆发，站长两步自查

上周网站的 HTTPS 锁标还好好的，这周你可能要重新看一眼它——问题不出在你的证书，而出在"谁的证书可以被信任"这件事本身。

印度证书颁发机构 eMudhra 被曝出一件堪称荒诞的安全事故：它的一批 CA 私钥被人破解了，过程不需要超级计算机，也不需要黑客手段，因为其中一把私钥的数值就是 4，另外还有 56 和 115。按规范，CA 私钥应该是一个极难猜中的大随机数，而这家机构生成密钥时把前面的字节全部填了零，只有最后一个字节非零。八把这样的私钥，破解耗时以毫秒计。

私钥失守意味着什么？任何拿到私钥的人都可以冒充这家 CA 签发证书。浏览器看到证书链顶端是受信任的根，中间环节又"合法"，就会给钓鱼站点亮绿锁。这正是最危险的信任链断裂：攻击者不需要碰你的服务器，只需要伪造一份"看起来可信"的证书。事件曝光后，Chrome、Mozilla 等主流浏览器紧急更新内置信任包，撤销对 eMudhra 相关节点的信任；甲骨文也在 10 月 21 日发布安全警报 CVE-2026-91403，CVSS 评分 9.1，针对 Java 运行时里的 JSSE 安全通信组件，处置方式同样是取消对 eMudhra 相关中间 CA 证书的信任，受影响范围覆盖 Java 8、11、17、21、25、27 等多个分支。

顺带把角色关系说清楚：根 CA 离线保管，日常给网站签发证书的是中间 CA，浏览器和操作系统里预装的是一张信任清单。eMudhra 这次出问题的正是中间环节——私钥一旦泄露，攻击者就能以它的名义无限签发新证书，除非浏览器把这条签发路径整个拉黑，否则没有止住的办法。这也是为什么各家的处置动作都集中在"撤信"上。

对站长来说，这件事落地上就是三个动作。

第一步，查自己网站的证书链。浏览器打开你的网站，点地址栏锁标，查看证书详情，顺着"由谁颁发"一路看到根证书。自建站的证书多数来自 Let's Encrypt 等公共 CA，不在本次事件范围内，但花两分钟确认一下签发者，比事后补救划算。习惯命令行的可以用 openssl 一条命令看完整链：openssl s_client -connect 你的域名:443 -showcerts，输出里 issuer 字段就是签发方。如果输出里出现 eMudhra 或者不认识的中间 CA，先别慌，对照浏览器厂商和 Oracle 公告里的名单确认再动手。

想更省事，可以试试开源命令行工具 sslx（github.com/glincker/sslx，Rust 编写，MIT 许可），它把证书检查封装成一条命令：sslx grade 你的域名 会直接给出 A+ 到 F 的评级，协议版本、证书有效期、证书链完整性逐项打钩，等于把 SSL Labs 的检测搬到了终端里；管着一批站点的，用 sslx expiry 域名1 域名2 一次列出所有证书的到期时间。

第二步，更新浏览器和 Java。浏览器信任包走自动更新，重启浏览器就能拿到最新版；服务器上跑着 Java 应用的（支付回调、老系统、一些管理面板），去 Oracle 官方渠道升级到最新修复版本，这次涉及的 JSSE 组件正是 Java 处理 HTTPS 连接的部分。

第三步，留意"绿锁幻觉"。这次事件之后，遇到要求输入账号密码或付款信息的页面，除了看锁标，再看一眼证书签发者。锁标只说明连接加密，不代表网站本身可信——签发者异常的证书，正是钓鱼站的常见特征。

个人观点：这次事故最大的价值，是把"信任链"这个平时没人看的概念推到了台前。我们默认 CA 会认真对待私钥，而现实是有机构把私钥生成了个位数。信任体系里没有"应该"，只有"验证"。

总结一下：你的网站大概率不受影响，但值得花十分钟做三件事——查证书链、更新浏览器和 Java、以后多看一眼签发者。安全这件事，从来都是把异常挡在上线之前，而不是等它上了新闻再行动。