苹果封锁八个弱密钥证书

刚看到一条挺离谱的安全新闻：印度证书机构eMudhra签发的八个中间证书，私钥居然是小于256的整数。这意味着攻击者几乎不用算什么，暴力枚举几百次就能恢复私钥，相当于把保险柜密码设成了「123」。数字证书是HTTPS信任链的根基，私钥弱到这个程度，整个验证体系就形同虚设。

更值得琢磨的是影响面。这八个证书里六个是TLS用途，两个是代码签名。代码签名出问题其实更隐蔽——它不直接暴露在浏览器地址栏里，但一旦被伪造，攻击者就能让系统误以为某个恶意软件来自可信发布者。对做跨境工具分发的团队来说，这提醒我们别只盯着HTTPS，软件供应链上的每一环都得查。各家响应速度也很有意思。Google和Mozilla先动手，苹果10月19日才部署封锁，比前两家略晚。好在Mozilla通过OneCRL、Google通过Chrome的证书封锁机制分发，用户不用手动更新就能获得保护。苹果这边依赖系统证书验证的软件也会被拦住，但Mac用户的情况稍微复杂些，具体还得看系统版本和软件调用证书的路径。目前没有证据表明这些证书被实际利用，Google也确认公开证书透明度日志里没发现由这六个中间证书签发的TLS证书。这算是不幸中的万幸，但「没进日志」不等于绝对安全，非公开环境或内部系统仍可能有残留风险。做跨境业务的同学，如果合作方或内部服务用到eMudhra签发的证书，建议主动排查一遍。我的判断是，这类事件暴露的不是某个CA的偶然失误，而是密钥生成环节缺乏强制审计。小于256的私钥在现代密码学里属于灾难级缺陷，居然能通过签发流程，说明部分CA的合规检查流于形式。浏览器厂商的封锁机制是最后一道防线，但真正的解法是CA在密钥生成阶段就引入独立验证。对普通用户来说，保持浏览器和系统更新仍是成本最低的自保手段。