四把弱密钥就能打穿未修补连接：eMudhra 证书替换进度怎么按证据分层核对
Cloudflare 正文列出八把 eMudhra 弱密钥；证书替换进度应按签发与吊销、服务端策略、客户端探测、利用迹象四层证据核对。材料能确认 Cloudflare 自身修补和受控探测中的样本结果，不能确认全网终端已完成替换；无拦截证据也不等于未发生定向拦截。
答案先说清楚：不能用一个 CA 公告、一个 CDN 的“已修补”或一张探测曲线回答 eMudhra 证书替换进度。应按四类证据分层：签发与吊销、服务端与边缘策略、客户端信任、利用与拦截迹象。每层只能证明一部分事实。另需校正标题口径：Cloudflare 摘要用“四把”概括风险，但同一篇正文列出的是八把弱密钥（4、56、66、115、155、156、230、237）；本文按正文八把核对，不把摘要当完整清单。
以下事实来自 Cloudflare 于 2026 年 10 月 30 日发布的复盘文章，所述状态应理解为“截至该文写作时”，不是 2026 年 11 月 1 日的全网实时状态。eMudhra 的证书替换进度、各信任库是否已移除相关证书，材料没有逐项给出，待核实。来源：Cloudflare 的 eMudhra 事件复盘。
事件边界：为什么不是普通私钥泄露#
Cloudflare 称，受影响的是 eMudhra 的中间 CA 私钥，而且这些私钥可由任何人从公开证书中近乎即时恢复。若客户端仍信任这些中间证书，又不强制证书透明度（Certificate Transparency，CT），攻击者就可能为任意域名伪造证书。这与过去一些 CA 被入侵事件不同：后者通常只有有限攻击者能签发证书，而这次恢复签名密钥的门槛极低。
eMudhra 已宣布退出公共 CA 业务，并称密钥生成脚本有误，但尚未分享该脚本；它曾用可能是正确生成的密钥签署证书吊销列表（Certificate Revocation List，CRL），随后又改为用弱密钥签署。审计方和交叉签名方在其中扮演什么角色，材料称仍需澄清。脚本为何出错、CRL 为何更正，本文材料没有解释，不能补推。
四层证据：每层只能回答一部分问题#
| 证据层 | 核对问题 | 材料中的信号 | 能确认 | 不能确认 |
|---|---|---|---|---|
| 签发与吊销 | 哪些证书由弱中间证书签出？是否进入 CRL 或 CT 日志？ | CRL 签名被更正；泄露后出现伪造证书，部分 SAN 指向其他组织域名 | 某些证书链和伪造证书存在 | 终端是否已拒绝、证书替换是否完成 |
| 服务端与边缘 | 自己的出站 TLS 是否拒绝弱链？ | Cloudflare 10 月 19 日起修补高影响系统，Pingora 数小时内拒绝；四小时完成代码分析；日志 10 月 21 日铺开 | Cloudflare 侧的策略与时间线 | 其他 CDN、客户源站和客户端的行为 |
| 客户端信任 | 实际终端是否还接受弱链？ | 挑战页用 ca1 弱证书、ca2 控制证书探测；一周约 5000 万次探测；现代浏览器大多修补，Android WebView 仍有 30–40% 接受；大型网络超过半数探测仍接受 | 受控样本中的接受比例与趋势 | 全网真实用户、不执行 JavaScript 的客户端；样本受机器人流量偏斜 |
| 利用与拦截 | 是否有人尝试？是否成功拦截？ | 约 2.2 万次弱密钥握手；三分之二是测试站；约 160 个证书的 SAN 指向其他组织域名；一张伪造证书时间为 10 月 20 日 18:19 UTC | 尝试和伪造证书存在 | 成功拦截、定向攻击；无证据不等于未发生 |
探测曲线还有一个读数陷阱：10 月 29 日 18:00 UTC，Cloudflare 检测到大量伪装成 macOS Chrome 150–154 的机器人流量，这看起来像修补进展，实际是流量分类变化；Linux 上同版本 Chrome 的接受率继续下降，来源称这只是提示性证据。控制端点、G3 交叉签名和采样比例也中途调整过，解读趋势必须对齐时间线。
开发者怎么核对：先自有资产，再第三方声明#
- 盘点信任库。列出操作系统、浏览器、运行时、嵌入式 WebView、容器基础镜像各自使用的信任库，记录版本、更新渠道和责任人。版本是否已处理 eMudhra 证书，待核实，不要先写“已修复”。
- 检查出站验证。确认 TLS 客户端启用证书链验证和主机名验证，记录失败原因与证书链字段。不要为兼容关闭验证。弱链拒绝规则要以经核实的证书标识为准，本文不提供指纹。
- 做受控探测。用控制端点对比，记录时间、采样比例、是否执行 JavaScript、机器人信号和 ASN（Autonomous System Number）。把 Android WebView、旧浏览器和 IoT 设备单独分组，不把挑战页结果外推为全网覆盖率。
- 保留利用线索。记录 SNI（Server Name Indication）、证书 issuer、SAN（Subject Alternative Name）、有效期、SCT（Signed Certificate Timestamp）和验证结果。关注“密钥泄露后签发、有效期异常长、SAN 与 SNI 不匹配”等线索；它们是调查信号，不是成功拦截的证明。
- 审第三方声明。要求提供时间戳、覆盖范围、方法和原始计数。CA 退出公共业务不等于客户端信任库完成替换；Cloudflare 材料只覆盖其自身系统和样本探测。
一个最小记录示例可包含这些占位字段：sni、issuer、san、not_after、sct_present、verify_result、asn、bot_signal、timestamp_utc。这是字段设计示例，不是实际测试输出，也未执行任何探测。
结论#
回到标题：未修补连接确实可能因少数弱密钥而被伪造证书击中，但“替换进度”不能由单一数字判定。Cloudflare 材料能支持的是：其高优先级系统已修补；受控探测中现代浏览器大多修补，而 WebView、旧浏览器和机器人流量滞后；已观察到弱密钥握手和伪造证书。材料不能支持的是：全网终端已完成替换、所有客户端都安全，或定向拦截一定没有发生。对开发者而言，可靠做法是分层留证，验证自己的信任链，并把“无证据”准确写成“未观察到”。
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
