---
title: "eMudhra 中间 CA 私钥事件影响范围与修复指南"
description: "梳理 eMudhra 中间 CA 私钥事件的信任链影响，说明操作系统、浏览器、运行时与容器的修复及验证方法。"
language: "zh-Hans"
url: "https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# eMudhra 中间 CA 私钥事件影响范围与修复指南

梳理 eMudhra 中间 CA 私钥事件的信任链影响，说明操作系统、浏览器、运行时与容器的修复及验证方法。

**信息核查日期：2026 年 10 月 22 日，北京时间**\
**适用对象：个人用户、网站运营者、开发人员和系统管理员**

本次事件是 eMudhra／emSign 的一批中间 CA 私钥因严重缺陷而可被恢复，影响通过公共证书体系验证网站、API 和软件身份的客户端。公共信任范围跨越主流操作系统；真正失陷的密钥范围与客户端的潜在影响范围并不相同。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

正文使用方括号编号对应来源，所有外部引用链接集中列在附录。所列版本是截至核查日期已确认包含本事件修复的版本基线，部署时优先选择同一受支持分支中更新的稳定版本。

## TL;DR

**结论：已确认失陷的是 8 个中间 CA 私钥；现有通报不支持“根私钥或整个 HTTPS 密码体系被普遍破解”。需要更新的信任生态接近全局，是否仍有风险取决于具体应用。**[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

1. \*\*普通用户：\*\*更新浏览器、操作系统及安全组件；Android 同时更新 Google Play 服务。Firefox Android 使用 158.0.2 或更新版本。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[2](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-2)
2. \*\*服务器：\*\*更新发行版的 `ca-certificates`／NSS，并检查应用自带的证书库；不能只更新宿主机。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)[8](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-8)[10](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-10)
3. \*\*开发环境：\*\*按需更新 Node 24 至 24.22.1 或更新版；Python 环境至少更新 pip 26.2.2、certifi 2026.10.19、uv 0.13.4。Go 程序需取得修复版二进制或重建；Java 按发行商公告更新。[12](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-12)–[15](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-15)
4. \*\*部署生效：\*\*重启相关服务，重建并重新部署容器；使用 Cloudflare Tunnel 时更新 cloudflared 至 2026.10.2 或更新版。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)
5. \*\*网站证书：\*\*链中含被吊销或封锁的中间 CA、或被取消信任的根时，更换受影响证书链；换证不能替代客户端信任库更新。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)[8](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-8)
6. \*\*验收：\*\*逐个应用验证其真实 TLS 路径；证书拒绝与超时、DNS 失败必须区分。保持证书验证开启，不用 `-k` 或跳过验证来消除报错。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)

## 1 事件事实与成因

### 已经确认的事实

Mozilla 与 Google 已确认 eMudhra 的 8 个中间 CA 私钥存在问题。研究者提交了私钥控制证明，Mozilla 随后独立恢复私钥，证实问题可以复现。其中 6 个中间 CA 用于 TLS，另 2 个用于代码签名。[2](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-2)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

问题集中在密钥生成结果：这些中间 CA 使用 P-384 椭圆曲线，私钥却全部是小于 256 的整数。这与正常从巨大范围中安全随机生成私钥的要求相差极远，因此恢复这些私钥不能作为正常强度 P-384 已被攻破的证据。[2](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-2)

这里的“证书被破解”应准确理解为“对应私钥可被恢复”。证书及其中的公钥本来就可以公开；真正需要保密的是能够生成有效签名的私钥。

### 仍在调查的生成流程问题

eMudhra 的初步说明将问题追溯到 2025 年 4 月的密钥生成仪式。其解释涉及一次密钥封装和解封装步骤：在原本的强密钥之外出现另一组弱密钥，弱密钥随后被用于证书申请和签发。公司仍表示准确根因尚未最终确认。[6](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-6)

因此，能够确定的是这些密钥严重薄弱、已经失陷；不能把故障进一步写成某款 HSM 的硬件随机数源已经被证明有缺陷，也不能将其描述为 RSA、ECC 或 TLS 的普遍密码学突破。

### 根证书取消信任的含义

浏览器或操作系统可以直接封锁受影响中间 CA 的证书或公钥，也可以移除通往它们的根信任。后一种措施会连带拒绝同一根下的部分合法证书。

Google 已安排移除 `emSign ECC Root CA - G3`，以保护不接收 CRLSet 更新的 Chrome 根库使用者。根库移除预计在北京时间 10 月 27 日至 28 日相应时段推送；Google 原文时间为 10 月 27 日美国太平洋夏令时间上午。这个计划与此前已经部署的紧急公钥封锁是两件事。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)

**根被取消信任，是处置措施；它本身不能证明根私钥失陷。**

## 2 为什么影响范围接近全局

### 失陷范围与信任范围

| 判断对象          | 本次事件中的范围                        |
| ------------- | ------------------------------- |
| 已确认有问题的密钥     | eMudhra 的 8 个中间 CA 私钥           |
| 可能需要采取措施的平台   | 公共根库、浏览器、操作系统、语言运行时、软件包和容器生态    |
| 可能被冒充的 TLS 身份 | 仍接受相关伪造证书链的客户端所访问的网站或服务         |
| 是否代表所有设备已经被入侵 | 不代表；信任条件、攻击者网络位置和其他验证策略共同决定能否利用 |
| 是否代表所有合法证书失效  | 不代表；连带失效取决于客户端取消信任了哪些根或证书链      |

Red Hat 明确将利用条件限定为客户端仍接受相关链、攻击者持有失陷私钥，并能够在网络中拦截连接。风险覆盖面与已发生的攻击数量不能混为一谈。[10](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-10)

### 网站使用其他 CA 也可能被冒充

假设一个网站真实使用 Let’s Encrypt 证书，而访问者的客户端同时信任多个公共 CA。攻击者可以尝试利用失陷的中间 CA，为同一个域名制作另一张证书。客户端通常不会预先要求该域名永远只能使用 Let’s Encrypt；如果伪造链仍被接受，网站真实使用哪家 CA 就不足以排除此类攻击。[8](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-8)

这个机制说明：更换一张原本正常的其他 CA 证书，并不会自动修复客户端对失陷 CA 的信任。真正需要切断的是客户端接受伪造身份的路径。

### 三种影响需要分别处理

\*\*身份冒充风险：\*\*尚未封锁相关链的客户端可能接受攻击者伪造的身份，导致敏感请求被发送给冒牌服务。

\*\*合法服务可用性风险：\*\*移除根信任后，某些原本合法的网站也会出现证书错误，需要迁移到另一条仍被接受的证书链。

\*\*部署遗漏风险：\*\*操作系统已经修复，但应用内置证书库、虚拟环境、旧容器镜像或已编译程序仍保留原来的验证行为。

这三个范围并不重合。Cloudflare 的处置涉及远端身份验证、共享信任库、基础镜像和独立应用，正体现了后两类工作的独立性。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)

## 3 受影响的 CA 与证书提供商

### 提供商与影响类型

| 提供商或体系                                                    | 本次事件中的角色                        | 需要区分的边界                            |
| --------------------------------------------------------- | ------------------------------- | ---------------------------------- |
| eMudhra／emSign                                            | 直接发生中间 CA 私钥失陷                  | 不能把全部 eMudhra 根及全部证书都写成已被破解        |
| Sectigo 相关交叉签名链                                           | 为同一批受影响公钥签发了交叉证书，形成另一条信任路径      | 需要封锁对应交叉证书或公钥；未证明 Sectigo 根私钥失陷    |
| Internet2／InCommon 的相关证书层级                                | 部分合法证书依赖拟被移除的 emSign ECC 根，涉及迁移 | 属于根取消信任的连带影响，不能计作那 8 个弱密钥中间 CA     |
| Let’s Encrypt、DigiCert、Google Trust Services、GlobalSign 等 | 未被本次通报列为私钥失陷方                   | 合法证书不会统一作废；脆弱客户端仍可能接受冒充它们所服务网站的假证书 |
| CDN、云平台、证书经销商                                             | 可能提供相关证书，或在连接源站和 API 时使用公共信任库   | 要检查实际证书链与验证器，不能只看平台或商品名称           |

私钥失陷与 Sectigo 交叉签名情况见 Mozilla 通知；Google 在公开事件跟踪中明确讨论了 Internet2／InCommon 所在合法层级的迁移问题。[2](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-2)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5) Cloudflare 发布修复则是服务和客户端的信任处置，不表示其自身 CA 私钥失陷。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)

### TLS 证书链与交叉签名

以下关系仅说明这次 TLS 相关路径，不包含代码签名路径，也不表示这些路径在所有平台上目前仍被信任。[17](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-17)

- `emSign ECC Root CA - G3` → `emSign Root TLS CA - G3` → 受影响的 TLS 中间 CA 公钥 → 为目标域名伪造的证书
- `AAA Certificate Services` → 受影响的 TLS 中间 CA 公钥 → 为目标域名伪造的证书

`emSign Root TLS CA - G3` 是 TLS 中间 CA 的直接签发者之一，在部分信任库中也可以直接充当信任锚；`emSign ECC Root CA - G3` 提供另一层交叉签名信任。Sectigo 的 `AAA Certificate Services` 为同一批中间 CA 公钥形成另一条路径。[17](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-17)

因此，修复时有两个不同粒度：

- \*\*精确封锁中间 CA 或其公钥：\*\*能保留同一根下其他正常层级，适合支持相应机制的验证器。
- \*\*取消根信任：\*\*可以保护缺少中间 CA 封锁能力的客户端，但会产生兼容性影响，并且需要覆盖客户端实际接受的其他路径。[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

不应把“删除所有 Sectigo／eMudhra 根”作为无差别通用步骤，也不应只删掉一个名称相近的证书就认定所有路径已经封闭。

## 4 操作系统与浏览器覆盖情况

### 主要平台

| 平台                          | 已知处置情况                               | 使用时应检查的范围                                 |
| --------------------------- | ------------------------------------ | ----------------------------------------- |
| Windows 与 Windows Server    | Microsoft 已通过自动证书信任列表更新分发封锁          | 设备是否收到更新；独立 CA bundle 不一定使用 Windows 的验证路径 |
| macOS、iOS、iPadOS 等 Apple 平台 | 事件协调者确认 Apple 已部署相关封锁                | 不能保证每个旧版本和第三方应用均获得相同覆盖                    |
| Android                     | Google 通过 Google Play 服务分发等效封锁       | 无 Google Play 服务的 ROM 应按厂商公告核查；应用自带验证器另查  |
| Ubuntu                      | 已提供系统证书包修复，包含多个当前和旧版本分支              | 旧版本的 ESM 支持条件、容器内部证书包及应用自带库               |
| Debian 与 Devuan             | Debian 已记录 ca-certificates 修复        | 必须核对实际使用分支和已安装包，不能照抄另一分支版本号               |
| RHEL 及衍生产品                  | 官方列 RHEL 6、7、8、9、10，并覆盖可能受影响的相关产品和镜像 | 截至本次核查，公告尚未列出完整修复勘误；“未找到更新”不能视为不受影响       |
| Fedora、Arch、Gentoo、Alpine 等 | 事件维护者已汇总相应修复记录                       | 按发行版、版本分支和镜像独立确认                          |
| FreeBSD                     | 官方列出全部受支持版本并提供系统信任库修复                | 更新后按公告重启相关守护进程；独立应用信任库另查                  |

Windows、Apple 及发行版汇总见 [4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)；Android 见 [1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)；Ubuntu、Debian、RHEL、FreeBSD 的发行方记录分别见 [8](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-8)–[11](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-11)。

停止支持的系统、离线设备、NAS、路由器和其他嵌入式环境，需要确认是否仍信任相关链，以及是否具备接收撤销或软件更新的渠道。平台名称本身不能替代对实际验证行为的检查。

### 浏览器保护与操作系统保护不同

Chrome 使用 CRLSet 分发紧急封锁；Firefox 使用 OneCRL 等机制。Firefox 还发布了包含封锁信息的版本，为没有正常接收远程设置的配置提供补充保护。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[3](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-3)

Firefox Android 的部分配置曾未在启动时正确应用更新后的列表，Mozilla 已说明该问题由 158.0.2 修复。因此不能把早期 158.0.1 的状态扩大为所有 Android Firefox 配置均已保护。[2](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-2)

Apple 和 Windows 的系统验证已采取措施，也不代表同机所有命令行程序均会走系统验证。事件维护者特别提示了部分 macOS 内置工具使用独立证书文件的情况；检查时应记录实际 TLS 后端和 CA 来源。[4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)

### 证书透明度的保护边界

Google 确认，在其实施封锁之前，这 6 个 TLS 中间 CA 没有签发出已进入 CT 日志的 TLS 证书。因此，强制执行 CT 的 Chrome 客户端具有额外保护。这个事实不能排除不执行 CT 的其他客户端接受过未记录证书的可能性。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

“原来能链到受信根”“存在潜在利用条件”“已经发生攻击”是三个不同判断，不应相互替代。

## 5 开发环境与运行时修复基线

以下是已确认包含相应修复的基线，不是要求长期固定这些版本。发行版可能通过回移补丁修复旧版本编号，应同时查看其安全公告。

| 组件                  | 已确认的版本或更新方式                | 部署注意事项                                                                                                         |
| ------------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Node.js 24          | 24.22.1 或同分支更新稳定版          | 包含根库更新及对被封锁公钥链的拒绝；检查服务实际使用的 Node 路径并重启                                                                         |
| Python certifi      | 2026.10.19 或更新版            | 检查每个实际运行环境；不能只更新全局 Python 下的一份包                                                                                |
| pip                 | 26.2.2 或更新版                | 单独更新旧虚拟环境中的 pip，并复查新环境创建后的版本                                                                                   |
| uv                  | 0.13.4 或更新版                | 按实际安装方式更新工具副本                                                                                                  |
| Go                  | 1.27.3 或 1.26.10，对应分支更新版亦可 | 更新工具链后重建并部署相关程序，或取得供应商修复版二进制                                                                                   |
| Oracle JDK          | 相应受支持版本线的关键补丁              | 不同 JDK 发行商按各自公告处理；没有适用于所有 Java 发行版的单一版本号                                                                       |
| Cloudflare Tunnel   | cloudflared 2026.10.2 或更新版 | 更新正在运行的服务；容器部署需要替换镜像并重新部署                                                                                      |
| Cloudflare One／WARP | 平台对应的已修复客户端版本或更新稳定版        | 客户端和服务器侧措施分开确认，具体平台版本见附录 [7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7) |

Node、Python、Go、Oracle 和 Cloudflare 的原始说明分别见 [13](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-13)、[12](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-12)、[14](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-14)、[15](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-15)、[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)。

### Python 的独立证书库问题

Python 官方指出，旧 pip 会组合使用系统信任与内置 certifi。仅修改系统证书库，或给 pip 增加一个 CA 文件，并不能可靠排除其内置旧信任。因此，`PIP_CERT`、`REQUESTS_CA_BUNDLE` 或 `--cert` 不能作为旧 pip 的通用修复替代品。[12](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-12)

更新后，应检查既有虚拟环境；创建新虚拟环境时，也要确认实际生成的 pip 版本，避免旧的引导组件重新引入旧工具。进行首次升级时，可以按 Python 官方公告提供的明确下载来源和 SHA-256 校验步骤完成引导，再升级其他包。[12](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-12)

### Go 与其他已编译程序

Go 的修复改变了 `crypto/x509` 的验证逻辑。[14](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-14) 从部署机制看，更新开发机上的编译器不会重写已经部署的二进制。要获得新的代码层封锁，应重建并替换应用，或者采用供应商提供的更新版。旧程序是否也能受益于系统根库更新，还取决于它实际使用的验证路径。

### 容器与打包应用

容器中的系统证书包、应用依赖和运行时通常由镜像内容决定。宿主机更新不等于镜像内容更新；需要更新基础镜像和依赖，重新构建、部署并检查实际运行实例。打包应用和自带运行时的桌面程序也应按供应商发布渠道更新。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)[10](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-10)

## 6 修复实施说明

### 先确定检查对象

建议为需要保护的服务记录以下信息，再选择相应修复路径。这是部署检查清单，不要求每个系统都存在全部组件。

| 项目    | 需要记录的内容                                     |
| ----- | ------------------------------------------- |
| 应用与用途 | 浏览器、支付 API 客户端、邮件发送服务、下载工具、反向代理等            |
| 运行位置  | 宿主机、容器、虚拟机、桌面应用或移动设备                        |
| 验证实现  | 操作系统验证器、OpenSSL、Node、Python 库、Java 或应用自定义实现 |
| 信任来源  | 系统 CA 包、certifi、JDK 信任库、自带 CA bundle 或企业配置  |
| 修复状态  | 已安装版本、补丁来源、是否重启或重新部署                        |
| 验收结果  | 受影响链是否被拒绝、正常业务连接是否成功、检查时间                   |

Cloudflare 的开发者指引特别指出，SDK 可能把验证委托给其他组件；只更新最上层 SDK，不一定改变真正的信任策略。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)

### 操作系统与浏览器

\*\*Windows：\*\*启用并确认自动证书信任列表更新。受管理环境按既有策略分发；离线或禁用自动更新的设备应使用相应管理流程落实封锁。需要单独检查不使用 Windows 系统验证的程序。[4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)

\*\*Apple 平台：\*\*完成系统、安全组件和应用更新。对 macOS 上的开发工具另查其 TLS 后端、证书文件和安装来源，不能仅凭 Safari 已拒绝测试链就判定整机完成修复。[4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)

\*\*Android：\*\*有 Google Play 服务的设备应完成相关组件更新；Google 表示重启设备可以触发即时更新。没有该服务的设备，根据厂商或 ROM 公告处理，不将 Google 的覆盖声明直接套用到所有 Android 设备。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)

\*\*Ubuntu／Debian：\*\*使用受支持的软件源更新证书包，并核对对应发行版公告。例如，在使用 APT 的系统上可以针对性执行：

```bash
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates
```

Ubuntu 22.04、24.04、26.04、26.10 的相关更新属于标准支持；更早版本应核对 ESM 支持和仓库状态。命令成功结束之后仍应比较公告中的修复包版本。[8](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-8)[9](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-9)

\*\*RHEL 及相关产品：\*\*按产品渠道检查证书包和安全勘误。版本检查可使用：

```bash
rpm -q ca-certificates
```

使用支持的 DNF／YUM 更新机制获取供应商补丁；若渠道尚未提供修复，不把“没有可更新包”当成已安全。需要临时取消根信任时，采用厂商明确列出的措施，并评估合法业务证书的兼容性。[10](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-10)

\*\*FreeBSD：\*\*按官方安全公告更新相应系统分支，随后重启使用相关 OpenSSL 信任配置的守护进程或重启系统。[11](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-11)

### 应用与镜像

在完成对应运行时和证书依赖更新后，检查服务实际运行的可执行文件路径，避免终端已经切换新版本，而守护进程仍使用旧安装目录。对于多环境 Python、服务容器和自带运行时的应用，应分别检查。

对需要重新构建的组件，保存构建版本、依赖版本及部署镜像标识。验收对象是实际运行实例，不能只检查构建机或镜像仓库中的新标签。[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)[12](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-12)[14](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-14)

### 网站证书迁移

如果网站证书链包含被吊销或封锁的中间 CA，或最终依赖被取消信任的根，应向提供商申请另一条仍被客户端接受的证书链，安装完整的服务器侧链，并检查所有入口，包括负载均衡器、反向代理、CDN 与直连源站。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

是否需要迁移，以实际链为依据。仅按证书销售品牌筛选，可能漏掉转售或交叉签名关系；仅等待常规到期续签，也不一定能赶在根库更新之前完成迁移。

对于其他 CA 签发且不依赖受影响根的正常网站证书，不需要因为这次事件一律重签。与此同时，网站服务器自身调用外部服务时，仍应执行客户端侧的修复检查。

## 7 验证修复是否真正生效

### 版本检查与行为检查分别进行

版本检查用于确认补丁或已修复组件已经部署；行为检查用于确认应用实际使用了预期验证路径。两个检查解决不同问题，均不能被“更新命令执行成功”取代。

事件维护者提供了测试站点和证书链材料，入口集中在附录 [4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)。应在目标应用的实际运行环境中验证，保持正常证书验证配置。[4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)[7](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-7)

| 检查结果                   | 可以得出的结论              |
| ---------------------- | -------------------- |
| 明确因为受影响链不受信任而拒绝        | 说明被测试的验证路径拒绝了该链      |
| 正常接受受影响链               | 表明这条路径需要继续修复或检查配置    |
| DNS 错误、连接超时、代理拒绝或服务不可达 | 不能据此认定证书风险已消除        |
| 浏览器拒绝，但应用调用未检查         | 只能确认浏览器，不能代表后台程序     |
| 一条链被拒绝                 | 仍需考虑客户端是否接受另一条交叉签名路径 |

测试应同时覆盖正常业务连接，避免通过移除过多信任造成业务故障后，误把所有请求失败视为修复成功。

### 建议的完成条件

- 受影响组件的更新来源和版本已记录。
- 对应运行实例已完成重启、重建或重新部署。
- 实际应用拒绝受影响链，且正常业务的 TLS 验证继续工作。
- 不存在为恢复连接而临时关闭证书验证的配置。
- 如涉及网站证书迁移，所有对外入口均已切换并验证。

以上完成条件是针对本次处置的运维验收建议；它不等同于证明设备没有其他安全问题。

## 8 历史 HTTPS 流量与风险边界

### 三类密钥用途不同

| 密钥    | 主要用途                  |
| ----- | --------------------- |
| CA 私钥 | 对证书中的身份与公钥绑定进行签名      |
| 网站私钥  | 在证书认证的 TLS 握手中证明服务器身份 |
| 会话密钥  | 保护某条连接中实际传输的数据        |

获得 CA 私钥，并不等于获得网站私钥或所有会话密钥。采用临时密钥交换、具备前向保密性的正常连接，不会仅因长期签名密钥后来失陷而自动暴露历史会话。TLS 1.3 的相关安全属性见 RFC 8446。[16](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-16)

本次主要风险发生在身份验证阶段：如果客户端接受了冒牌服务器的证书，它可能与攻击者建立一条本身仍然加密的连接。TLS 1.3 也需要可信身份验证；仅升级协议版本不能替代封锁失陷 CA。

### 目前可以与不能作出的判断

\*\*可以确认：\*\*特定中间 CA 私钥已经失陷；相关公共信任路径具有广泛影响；主流平台和多个软件生态已经采取处置。[1](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-1)[4](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-4)[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

\*\*不能由此确认：\*\*所有用户已经遭遇中间人攻击、其他 CA 私钥也失陷、所有历史 HTTPS 流量都可解密，或更新某个浏览器后整台设备所有应用都已获得保护。

对特定服务的最终判断，应基于其证书链、验证策略、实际运行组件和更新状态，而不是仅看地址栏是否为 HTTPS。

## 附录 A 受影响中间 CA 名称

以下名称用于资产核查。名称本身不能代替证书指纹或公钥标识；自动化匹配时，应采用事件维护者或供应商提供的精确标识，并覆盖交叉签名证书。[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)

| 中间 CA              | 用途   | 关联组织        |
| ------------------ | ---- | ----------- |
| EM EV TLS CA - G3B | TLS  | eMudhra BV  |
| EM OV TLS CA - G3B | TLS  | eMudhra BV  |
| EM DV TLS CA - G3B | TLS  | eMudhra BV  |
| EM EV TLS CA - G3C | TLS  | eMudhra Inc |
| EM OV TLS CA - G3C | TLS  | eMudhra Inc |
| EM DV TLS CA - G3C | TLS  | eMudhra Inc |
| EM OV CS CA - G3B  | 代码签名 | eMudhra BV  |
| EM OV CS CA - G3C  | 代码签名 | eMudhra Inc |

TLS 与代码签名的验证器及撤销机制并不完全相同。本文重点为 HTTPS/TLS；代码签名环境应采用 Microsoft、JDK 或相关软件供应商针对该验证用途的处置，不把浏览器测试结果当作代码签名验收。[5](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-5)[15](https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide#source-15)

## 附录 B 引用链接

以下来源均于 2026 年 10 月 22 日核查。滚动公告可能继续更新，正文中的状态与版本应按本文件日期理解。

### 事件事实与平台处置

**\[1] Google Chrome 与 Android 官方公告**\
说明私钥缺陷、SPKI 封锁、Google Play 服务分发、CT 保护与 Chrome 根库移除计划。\
[Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/)

**\[2] Mozilla Bugzilla 2083449 事件记录**\
包含原始报告、独立验证、生成流程调查、Firefox Android 后续修复和合法证书迁移讨论；重点可查评论 5、11、29、30。\
[eMudhra Private key compromise of Intermediate Certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449)

**\[3] Mozilla Firefox 安全公告**\
说明 OneCRL 紧急分发与后续 Firefox／NSS 处置。\
[Protecting Firefox users following the compromise of eMudhra intermediate certificates](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)

**\[4] 事件协调者 Dennis Jackson 维护的汇总与检测入口**\
提供平台与软件修复状态、测试入口、公共证书链材料及 Windows／macOS 等环境的补充说明。测试结果仅代表实际被测验证路径。\
[eMudhra Intermediate CA Compromise](https://emudhra.we-have-a-problem.com/)

**\[5] Mozilla 发给发行版与信任库维护者的通知**\
说明 6 个 TLS 与 2 个代码签名中间 CA、Sectigo 交叉签名、撤销和根信任处理边界，并列出精确证书与公钥标识。\
[oss-security eMudhra Intermediates Compromise](https://www.openwall.com/lists/oss-security/2026/10/20/1)

**\[6] eMudhra 官方事件声明**\
提供厂商对密钥生成流程的初步解释；准确根因仍以完成后的调查结论为准。\
[eMudhra Statement on Recent Certificate Security Incident](https://emudhra.com/en/post/certificate-security-incident)

**\[7] Cloudflare 官方事件与修复说明**\
覆盖 WARP、Cloudflare Tunnel、源站验证、运行时依赖、镜像更新及验证方法。\
[8 eMudhra certificates are compromised Here is what you need to know](https://blog.cloudflare.com/emudhra-certificate-compromise/)

### 操作系统与发行版

**\[8] Ubuntu 官方修复公告**\
列出各版本 ca-certificates 修复包、支持渠道和针对性更新步骤。\
[eMudhra CA compromise fixes available](https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available)

**\[9] Debian 官方问题与修复记录**\
应以维护者的修复记录和对应发行版包为准，不把问题讨论中的早期临时建议当作最终方案。\
[Debian bug 1151413 eMudhra Intermediate CA key compromise](https://bugs.debian.org/1151413)

**\[10] Red Hat 官方安全公告 RHSB 2026 012**\
列出 RHEL 6 至 10、相关产品和容器影响，以及修复发布和临时处置入口。\
[Certificate compromise eMudhra](https://access.redhat.com/security/vulnerabilities/RHSB-2026-012)

**\[11] FreeBSD 官方安全公告**\
提供受影响系统分支、修复版本与服务重启要求。\
[FreeBSD SA 26 73 caroot](https://www.freebsd.org/security/advisories/FreeBSD-SA-26:73.caroot.asc)

### 运行时与协议

**\[12] Python 官方事件说明**\
提供 pip、certifi、uv 等修复基线，说明旧 pip 独立信任库问题，并给出带 SHA-256 校验的初始升级方式。\
[Information for Python users regarding eMudhra emSign CA certificate security incident](https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576)

**\[13] Node.js 24.22.1 官方发布**\
包含 NSS 根库更新与拒绝包含被封锁公钥证书链的变更。\
[Node.js 24.22.1 security release](https://github.com/nodejs/node/releases/tag/v24.22.1)

**\[14] Go 官方安全发布**\
说明 Go 1.27.3／1.26.10 的 crypto/x509 证书链过滤更新。\
[Go 1.27.3 and Go 1.26.10 are released](https://groups.google.com/g/golang-announce/c/66pojueaQek)

**\[15] Oracle JDK 官方处置说明**\
说明 JDK 关键补丁与无法立即升级时的相关配置措施。\
[Distrusting eMudhra Intermediate Certificates in Oracle JDK](https://ops.java/emudhra)

**\[16] TLS 1.3 协议标准 RFC 8446**\
参见附录 E.1 等关于身份认证、临时密钥交换及前向保密性的说明。\
[The Transport Layer Security Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446.html)

**\[17] 事件相关根证书与签发关系数据**\
用于理解直接签发者与交叉签名关系；其中的根库纳入状态不能替代客户端最新撤销或封锁状态。\
[Root certificate relationships JSON](https://emudhra.we-have-a-problem.com/roots.json)

## 安全维护咨询

不确定证书信任变化如何影响你的系统？我们可以协助排查受影响的客户端，并制定安全更新计划。

[咨询安全更新](<https://keendigit.com/zh/contact?service=security-remediation#form>)

[原始页面](<https://keendigit.com/zh/insights/emudhra-ca-incident-remediation-guide>) · [内容索引](<https://keendigit.com/zh/llms.txt>)

KeenDigit LLC · 怀俄明州登记编号: 2026-002106155

[前往怀俄明州州务卿官网核验](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · 美国怀俄明州 Sheridan · 保留所有权利。