2026-10 eMudhra 中间 CA 私钥失陷

• 事件类型：WebPKI / CA 密钥生成与信任分发事件；首次报告 2026-10-17，多方于 2026-10-20 发布公告；首次整理 2026-10-23，CVE 关联与厂商追加声明核对 2026-10-26
• 八组 eMudhra 中间 CA 密钥因生成缺陷而可恢复，攻击者可利用对应签发权限伪造证书；Google、Mozilla 和发现方资料均确认密钥失陷
• 风险不限于已经使用 eMudhra 证书的网站：只要客户端仍接受受损链，攻击者就可能为其不拥有的域名签发被信任的 TLS 证书
• 浏览器可通过 OneCRL、CRLSet 等快速阻断；不消费这些机制、不强制 CT 的客户端依赖各自信任库与验证实现更新
• mitmproxy 12.3.0 已提供 --emudhra 和 --emudhra-old，将签发材料内置为显式启用选项；工具可用不等于任何客户端都可被拦截

关联漏洞与公告复制章节链接

标识	产品范围与来源口径
CVE-2026-111943 / GO-2026-6809	Go CNA 记录针对 crypto/x509 验证时拒绝受损中间 CA；同一编号也被 RustSec 和 AWS 用于关联各自处置，详细版本与补丁见 CVE 页
CVE-2026-113470	Mozilla Firefox / Thunderbird 的阻断列表更新，确保 RemoteSettings 不可用时仍能拒绝受损中间证书
RUSTSEC-2026-0382	rustls-webpki 的同类拒绝检查，alias 为 CVE-2026-111943
2026-150-AWS	AWS 以 CVE-2026-111943 为题发布跨服务 trust bundle 处置公告；不等同于所有服务都使用 Go

• 截至 2026-10-26，在所查 eMudhra 声明、Go / Mozilla CVE 记录、RustSec 与 AWS 公告中，未发现另一个专门覆盖 CA 弱密钥生成根因的 CVE；不能把某个产品编号当作整个事件的统一编号
• CA 弱密钥生成、客户端缺少拒绝检查、根信任移除和下游发布是不同环节；事件时间线继续在这里维护，产品补丁与版本按各自公告核对

时间线复制章节链接

成因与证据复制章节链接

• Google 将问题归因为私钥生成时随机性不足；发现方说明私钥可由已公开证书材料恢复
• 研究者 Wayne 用各受损私钥签署同一消息，向 root program 提供签名证据；这是对应私钥签名能力的证据，不是已有网络入侵的证明
• eMudhra 声明： 使用了 FIPS 140-2 Level 3 HSM，但 KGC 的 wrap/unwrap 步骤产生一组额外的弱密钥，弱公钥最终进入公开证书
  • 10-26 的追加声明明确归因为脚本错误，承诺通过 CCADB 发布完整 RCA 并进行独立审查；此前 wrap/unwrap 解释仍按厂商阶段性说法保留
  • 厂商称问题经过两轮审计、持续约 18 个月未被发现；精确根因仍在调查
  • HSM 认证不能单独证明完整密钥生成、包装、导出与证书发布流程正确
  • AI 辅助分析是厂商叙述，不能据此写成 AI 破解了现代密码算法
• 厂商影响声明： 七个中间 CA 未投入生产，另一个投入生产但没有签发 end-entity 证书；厂商称根 CA 私钥未失陷、基础设施未被侵入且没有数据泄露
  • 这些是厂商的调查结论，不能用来证明接受这些 CA 的所有第三方客户端均无风险
  • CA 以前没签发过客户证书，不妨碍恢复了私钥的其他人签发新证书

受损对象与证书链复制章节链接

社区 impacted-intermediates.json 在本次读取中列出 16 张证书、8 个不同 SPKI：每个受损公钥均有 eMudhra 与 Sectigo AAA 路径的证书。这里的证书数量、公钥数量与根数量不能互换。

• Google 公告中的八个受损 CA 与 CT 段落中的六个 TLS CA应按具体用途区分，不把所有证书都当作同一 TLS 路径
• 相关证书层级包含 emSign Root TLS CA - G3、emSign Root CS CA - G3，浏览器/根库处置又涉及 emSign ECC Root CA - G3；同时存在 Sectigo AAA Certificate Services 交叉签名路径
  • 这些名称不是同一个证书的可互换写法；核对时应使用具体证书 SHA-256、SPKI 和实际构建出的链
  • 某一张证书被吊销，不代表同一公钥的所有交叉签名路径都已被客户端阻断；Chrome 按 SPKI 阻断可覆盖共用公钥的变体
  • 去信任某个根是风险处置，不等于根的私钥也泄露；不能扩大为 eMudhra 全部根、全部业务或 Sectigo 全部体系失陷

为什么能用于 MITM复制章节链接

客户端仍信任某条 CA 链
  → 攻击者掌握受损中间 CA 私钥
  → 为目标站点签发伪造叶证书
  → 攻击者取得客户端流量路径
  → 客户端未通过吊销、CT、pinning 等策略拒绝伪造链
  → 客户端与攻击者建立 TLS，攻击者另连真实上游
  → 明文可被读取或修改

• 攻击仍需要控制代理、路由、接入网络或其他流量入口；只有签发密钥不会自动让流量经过攻击者
• 受损 CA 私钥提供的是证书签名能力，不等于取得真实站点私钥或已录制 TLS 会话的密钥
• CT 要求可限制无日志证书被浏览器接受；它不是吊销或去信任的替代品，也不能从“没见到 CT 记录”推导非 CT 客户端没有遭受攻击
• 利用状态： eMudhra 称未发现披露前有人恢复或滥用弱密钥；Cloudflare 称未发现其服务存在活跃利用。社区披露站认为非 CT 客户端的历史利用情况未知；本次没有确认到成功在野 MITM 的独立证据

响应与修复复制章节链接

• 客户端盘点覆盖 OS 根库、浏览器、Python certifi、Java truststore、语言运行时、SDK 自带 bundle、容器镜像及长期进程
  • 浏览器安全不代表同一台机器上的 curl、git、pip、代理或后台服务安全
  • SDK 更新不一定更新底层 TLS verifier；系统 ca-certificates 更新也不一定覆盖应用自己的静态 bundle
  • 更新后按实际加载方式 reload、restart 或重部署，验证每条应用路径，不能用单个 curl 结果代表整台主机
• 站点运营者若使用链到被去信任根的真实证书，应按 CA 与 root program 指导迁移到未受影响的证书层级；可能出现证书校验失败
• 禁用校验、curl -k、NODE_TLS_REJECT_UNAUTHORIZED=0 或 ssl_insecure=true 会消除身份认证保护，不能作为兼容性修复
• 使用供应商更新与准确的证书/SPKI 清单，不复制私钥、不盲删整家 CA 的全部根；测试站点的连接结果只说明被测试的客户端/校验路径

证据与待验证复制章节链接

• mitmproxy v12.3.0：commit ac4f4cf7eab63effeb4b53b6bc09b5143aa42ae4；已静态核对 CLI 参数、tlsconfig.py 默认值/选链和 pyproject.toml，未启动代理
• certifi 2026.10.19：commit 662df63d7906df66f1f07c0751a3dfe9da14d914，标题 Restore unaffected emSign roots
• 社区资料仓库核对到 commit ece1ad880e12be8e576e4b8f1f4f2922e2d41c8e；其修复版本表属于持续更新的社区汇总，不代替各厂商公告
• Go 修复 commit 7f86f957633ee31a1c17a1eb8452ca7a3d9bc141 的八个 SPKI hash 与 10-26 读取的公开受损证书元数据完全对应；仅做静态集合比对
• 待确认：最终 KGC 根因、各交叉签名链的完整策略覆盖、CS 用途的实际风险，以及无 CT 客户端的历史利用情况
• 本次仅查阅公告、公开证书元数据和源码；未下载私钥材料、运行代理、访问信任检测端点或修改任何证书库

参考复制章节链接

• Mozilla：Firefox 响应与追加更新
• Google：Chrome / Android 响应
• eMudhra 厂商声明与更新
• CVE-2026-111943：Go CNA 记录、Go 安全发布
• Mozilla MFSA 2026-111：CVE-2026-113470
• RustSec RUSTSEC-2026-0382、AWS 2026-150-AWS
• Mozilla Bug 2083449：公开事件跟踪
• Cloudflare：影响、响应时间线与客户建议
• Mitmproxy 12.3 发布说明
• certifi GHSA-6q48-6c7w-9gw2
• certifi 恢复未受影响根的固定提交
• 社区披露与响应汇总、受损证书与 SPKI 元数据、根证书元数据
• galadran/we-have-a-problem.com
  • 社区响应站源码；固定快照，保留证书、交叉签名与下游修复资料