用证书透明度日志核对 eMudhra 弱密钥替换进度：签发侧能确认什么，终端侧不能确认什么

先给结论：证书透明度（Certificate Transparency，CT）日志适合核对“签发侧替换进度”——是否还有新证书由 eMudhra 的弱中间证书签发、替换证书是否被 CT 日志记录并带 SCT；它不能单独回答“还有多少终端仍信任这些弱密钥”。Cloudflare 在 2026 年 10 月 30 日的追踪文章中，主要用网络侧握手日志和 challenge 页探针观察利用与终端修补；本次材料没有展开其查询 CT 日志的具体步骤。因此，下面的 CT 核对方法属于基于机制的推断与建议，不是该文的实测流程。

背景事实：文章称 eMudhra 的八个中间私钥弱到可快速恢复，列出的值为 4、56、66、115、155、156、230、237；任何人可从公开证书恢复这些签名密钥，并为任意域名签发证书，只要未修补客户端不强制 CT 就会接受。eMudhra 已宣布退出公共 CA 业务，并称是密钥生成脚本错误，但尚未分享脚本；其证书吊销列表（Certificate Revocation List，CRL）曾先用可能正确生成的密钥签名，随后改为弱密钥签名。以上均来自同一篇 Cloudflare 文章，相关细节仍待独立核实。

先分清三层“替换”#

“替换进度”至少有三层，混在一起会得到错误结论。

• 签发侧：CA 是否停止用弱中间证书签发新证书，是否吊销旧证书。
• 服务端：网站是否把证书链换到新的中间证书或根证书。
• 终端侧：浏览器、操作系统、运行时、容器和自定义 CA bundle 是否移除对弱密钥的信任。

CT 日志主要覆盖第一层和第二层的可见部分：它记录证书签发事件和 SCT，能让人按签发者、时间窗、SAN、有效期等字段核对是否还有弱链证书出现。终端侧是否已修补，CT 日志不记录。材料中“未强制 CT 的客户端会接受伪造证书”这句话，说明 CT 是接受条件之一，不是终端信任库的替代品。

CT 日志能回答什么#

机制上，CT 是公开、可审计的证书日志。证书通常携带 SCT（Signed Certificate Timestamp，签名证书时间戳），客户端可据此判断证书是否被公开记录。开发者用 CT 日志核对 eMudhra 替换进度时，可关注：

• 某时间窗内是否仍有新证书由涉事弱中间证书签发；
• 替换后的证书链是否已不再指向弱中间证书；
• 证书是否带 SCT，SAN（Subject Alternative Name，主题备用名称）是否与业务域名一致，有效期是否异常；
• 是否出现披露后新签发、有效期超过公共 CA 上限的证书。

Cloudflare 文章记录到约 160 次异常握手：证书 SAN 指向其他组织的域名，与握手请求的 SNI（Server Name Indication，服务器名称指示）不匹配，部分域名与消费级 IoT 设备相关；有些伪造证书在密钥泄露后数小时出现，一张日期为 2026 年 10 月 20 日 18:19 UTC，有效期超过两年，长于公共 CA 允许期限。这些特征适合作为 CT 日志的筛查条件。但文章没有给出 CT 查询结果或查询步骤，不能把“可用 CT 筛查”写成“Cloudflare 已用 CT 日志统计出替换率”。

Cloudflare 的探针口径说明了什么#

与 CT 日志互补的是主动探针。Cloudflare 在部分 challenge 页向 ca1.cloudflarecaptcha.com 和 ca2.cloudflarecaptcha.com 发两个探测连接，其中一个安装 eMudhra 签名证书，另一个作对照，记录终端是否接受。文章称过去一周发出 5000 万次探针。这个口径测的是“终端是否仍接受弱链”，不是“CT 日志里还有多少证书”。

结果有几个限定：现代浏览器大多已修补；Android WebView 仍有 30–40% 接受；大型网络中超过一半探针仍接受受损链，周末后趋势平坦。文章明确提醒，challenge 页流量高度偏斜，有未确认机器人，且只有执行 JavaScript 的客户端会发探针。10 月 29 日还出现大量伪装成 Chrome 150–154 on macOS 的机器人流量，使分类变化看起来像修补；Chrome 150–154 on Linux 的接受率继续下降，但作者称这是提示性而非结论性证据。探针期间还多次调整 SCT 与交叉签名，说明接受率不是单一“是否修补”变量。

把证据链分开记录#

下表是方法层面的区分，不是本次材料给出的统一测试结果；数字均来自 Cloudflare 文章的口径。

给开发者的核对清单#

1. 先查终端信任库。浏览器、操作系统、Android WebView、旧设备、容器基础镜像、语言运行时和自定义 CA bundle 要分别确认。材料显示 Android WebView 和旧浏览器滞后，不能只看桌面 Chrome。
2. 用 CT 日志做签发侧审计。按弱中间证书标识和时间窗查询新增证书，记录 SAN、有效期、SCT 和签发者。具体日志列表与查询工具本次材料未提供，需按公开认可的 CT 日志列表自行核实。
3. 用主动探测验证终端行为。在受控环境构造测试端点，分别提供弱链证书和正常链证书，观察客户端拒绝还是接受。示例应使用 example.com 等占位域名，且必须获得授权，不能扫描第三方。
4. 核对吊销与缓存。CT 日志不告诉你证书是否已吊销；要另查 CRL/OCSP（Online Certificate Status Protocol，在线证书状态协议）和客户端吊销检查行为。材料只提到 eMudhra 的 CRL 签名异常，未提供 OCSP 细节。
5. 固定报告口径。写清统计对象、时间窗、单位和比较基期。例如“Cloudflare 网络内一周约 22,000 次弱密钥握手尝试”与“challenge 页一周 5000 万次探针”不是同一分母，不能合并成全球修补率。

建议至少记录：日志来源（待核实）、查询对象、时间窗起止（UTC）、单位、比较基期，以及新增弱链证书数、带 SCT 比例和异常 SAN 数。没有这些字段，不同团队的数字无法比较。

不要从 CT 日志过度推断#

CT 日志没有终端分布，不能直接算出“还有多少用户未修补”。日志里存在的证书也可能已被吊销；未出现在日志里的证书，仍可能被不强制 CT 的客户端接受。材料中的 22,000 次握手尝试、160 次异常握手、5000 万次探针、30–40% Android WebView 接受率，都是特定口径下的观察，不是全球互联网的普查。报告时保留这些限定，比给一个看起来精确的百分比更有用。

对 API.PLUS 的开发者读者，可操作的部分是检查自己服务作为 HTTPS 客户端时的信任库，以及自己服务端证书链是否已换掉弱中间证书；平台侧无法替终端用户更新设备信任库。CT 日志应作为签发侧审计证据，与吊销状态、主动探针和网络日志一起使用，而不是单独充当“替换进度仪表盘”。