一周两起CA侧事件：弱密钥与批量吊销说明了什么
本周SSL证书行业的焦点不在企业侧，而在认证机构侧：两家 CA 先后出事，一起是中间 CA 私钥可被推算，一起是40万余张证书批量吊销。两起事件的性质与上周的攻击事件不同：都不是被攻击，而是信任生产流程自身出了缺陷。把这两起事件放在一起看，比单独看任何一起都更有价值。
一、eMudhra 事件：8张中间CA私钥，可以被算出来
10月17日，一位安全研究者向 Chrome 根计划报告：印度认证机构 eMudhra 的8张中间 CA 证书，私钥可以被恢复。他的证明方式颇具冲击力：用恢复出的8个私钥分别签名了同一句话："We have a problem here - Wayne"。
问题的根因不是算法缺陷，而是密钥生成时随机性不足：这8张 P-384 椭圆曲线私钥的值都小于256，研究者公开的样本之一就是整数4，其余为56、115、237等量级的极小值，从公钥反推私钥只需枚举几百个候选值。Mozilla 于报告当日独立复原了全部密钥，并表示未使用报告者的任何方法。
各方的响应速度值得记录：Chrome 在报告后100分钟内完成 CRLSet 封禁，Mozilla 两小时内推送 OneCRL，Apple 与 Microsoft 随后跟进；由于封禁按公钥哈希进行，与 Sectigo 交叉签名的副本同时被覆盖。更关键的一道防线是证书透明度（CT）：Chrome 确认，在封禁之前没有任何链接到这6个可签发 TLS 证书的中间 CA 的证书被写入 CT 日志，因此强制 CT 的客户端实际上不可能被伪造证书默认信任。10月21日，印度 CERT-In 发布正式公告确认：缺陷源于密钥生成环节的随机性不足，并非 P-384 算法本身的漏洞；截至公告日无证据表明相关密钥已被恶意利用。
eMudhra 的官方声明称，基础设施未被攻破、无数据泄露，弱密钥产生于密钥生成仪式中的 wrap/unwrap 步骤并被误发布到浏览器根库；受影响中间 CA 未签发过终端证书，公司受印度监管的数字签名证书业务因架构隔离不受影响。
二、GoDaddy 事件：40万张证书的批量吊销
同一周，GoDaddy 自查发现404,607张证书携带的证书策略标识符与其公布的配置不符，多数为 Starfield DV 证书。按照基线要求，此类问题须在5天内完成吊销，GoDaddy 未按期完成，因此升级为延期吊销事件，截至10月19日已吊销22万余张。
这是一起合规事故而非攻击，但影响是实打实的：证书被吊销后，站点会持续显示浏览器告警，直到新证书被安装到实际提供服务的服务器上为止，仅仅在账户后台生成一张替换证书没有任何作用。
Mozilla Bugzilla 同期还记录了 GoDaddy 的另一项独立缺陷：吊销列表（CRL）经 CDN 缓存分发，缓存 TTL 长达24小时，导致吊销信息在公共分发点延迟超过一天才可见。根因分析中有一个教训值得所有运维团队记取：GoDaddy 原有的监控只校验源站的 CRL，不校验公共分发点返回的 CRL，因此完全没有发现缓存问题。
三、本周厂商动态速览
DigiCert：G5 根切换确认延期至11月12日18:00至20:00（UTC），覆盖全品牌公网证书；"Apache 下载包移除自签根"已于10月20日生效，此前完成改造的脚本如需回滚请核对配置。
MPIC 多视角核查：DigiCert 自10月19日起将远程网络视角从4个逐步增至最多6个，12月1日起全面强制6视角，执行再次早于基线要求。值得注意的策略差异：DigiCert 公开了 MPIC 代理的 IP 段与专属请求头，为有边界防护的企业留出白名单空间；Let's Encrypt 则坚持不公布固定 IP 列表。对 DNS 查询、访问地域或请求频率设限的企业，应分别核对配置，否则续期会突然失败。
GlobalSign：Atlas 系列服务分批维护，其中 DocuSign TSP 服务迁移后端点 IP 已变更，使用防火墙 IP 白名单的客户必须同步更新规则；后续还有多轮已排期的维护窗口。
▼
把两起事件放在一起看，共同点会浮现出来：都不是攻击，都是信任生产流程中的工程缺陷。一个出在密钥生成仪式的随机性质量上，一个出在策略配置与吊销执行的流程管理上，算法本身、架构本身都没有问题。
这说明 CA 的可信，不只建立在算法强度和基础设施之上，同样建立在密钥仪式、配置管理、吊销执行这些容易被忽视的环节上。对企业用户而言，由此带来的启示有三点：
关注 CA 公告与根证书调整的连带影响，因为合法证书也会因根被移除而不受信任；对关键业务启用 CT 日志监控，及时发现异常签发；定期确认证书自动化链路与 CA 变更的兼容性。
天威诚信会持续跟踪这些事件的处理进展，也提醒近期有证书采购与续期安排的企业，与您的客户经理确认相关品牌证书的适配情况。
