2026 年 10 月 20 日，第三方证书颁发机构 eMudhra 的部分中间 CA 私钥泄露事件被公开披露。未经授权的第三方可能利用泄露的私钥签发伪造的 TLS 证书，并在能够拦截或劫持网络流量时冒充 HTTPS 服务，实施中间人攻击，窃取或篡改通信数据。
该事件属于第三方 CA 信任问题，不是 TencentOS 软件本身的代码漏洞，也不表示系统已遭受攻击。TencentOS 默认系统信任库中的相关根证书能够为涉事中间 CA 建立信任链，因此仍需处理证书信任风险。业务即使未使用 eMudhra 签发的证书，也可能因客户端仍信任涉事证书链而受到影响。
本次事件的处置分两层：取消系统信任库中两张根证书的信任，可立即生效并阻断相关信任路径；相关组件的正式修复版本正在测试验证中，发布后通过官方软件源提供，本预警同步更新。
警告：
取消根证书信任后，仅能链到这两张根 CA 的服务证书将不再受信任。若服务提供方尚未更换证书链，且没有其他受信任的证书链，TLS 校验会失败，相关客户端可能无法连接。操作前请评估业务依赖、备份相关配置并在测试环境验证，必要时安排维护窗口。请联系服务提供方更换证书链，不要关闭 TLS 校验或使用
curl -k 等方式绕过校验。1. 事件详情
在公开密钥基础设施（PKI）中，客户端通过“服务器证书 > 中间 CA 证书 > 受信任的根 CA 证书”组成的证书链验证服务身份。本次泄露的是中间 CA 用于签发证书的私钥；相关中间 CA 可通过签名链或交叉签名链连接到系统信任库中的
Comodo AAA Services root 与 emSign ECC Root CA - G3。当证书链、有效期、用途等校验均通过时，仍信任这些根证书的客户端可能接受伪造的服务证书。虽然上游已进行吊销操作和浏览器更新，但并非所有客户端都会立即拒绝涉事证书链。不同应用对 CRL、OCSP 或其他吊销机制的支持与配置不同，部分客户端不会主动获取或强制检查相关吊销状态。因此还需取消系统信任库中对这两张根证书的信任，并检查应用独立维护的证书库。
本方案取消对以下两张根证书的信任，其中
emSign ECC Root CA - G3 为签名链根证书，Comodo AAA Services root 为交叉签名链根证书。下表中的 trust 标签用于命令定位，SHA-256 指纹用于核对证书身份：
根证书（trust 标签） | 证书主题 CN | SHA-256 指纹 |
emSign ECC Root CA - G3 | emSign ECC Root CA - G3 | 86:A1:EC:BA:08:9C:4A:8D:3B:BE:27:34:C6:12:BA:34:1D:81:3E:04:3C:F9:E8:A8:62:CD:5C:57:A3:6B:BE:6B |
Comodo AAA Services root | AAA Certificate Services | D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7:1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4 |
实际使用系统信任库校验 TLS 证书的程序可能受影响，例如
curl、wget、yum/dnf，以及使用该信任库的 OpenSSL、GnuTLS、NSS 等应用。是否受影响取决于程序实际使用的信任库及证书链，不应仅凭程序名称判断。2. 影响范围
本次事件的影响分两层：系统信任库由
ca-certificates 提供，所有 TencentOS Server 版本均受影响，是本方案的主要处置对象；部分组件不读取系统信任库、或内置独立信任列表，需分别升级。2.1 系统信任库（ca-certificates）
TencentOS Server 2.4、TencentOS Server 3.1、TencentOS Server 3.3、TencentOS Server 4 全系列产品均受影响。系统默认自带
ca-certificates 提供系统级信任库，其中包含上述两张根证书。正式修复版本正在测试验证中，发布后通过官方软件源提供；在修复版本发布前，请参见 缓解方案：取消根证书信任。2.2 独立信任库组件
以下组件不读取系统信任库，或内置独立的信任列表，需分别升级，其修复版本同样尚未发布。上游为便于跟踪和分发信任库更新分配了相应 CVE 编号：
CVE 编号 | 影响组件 | 受影响范围 | 修复状态 |
CVE-2026-114406 | ca-certificates | 所有系统：TencentOS Server 2.4/3.1/3.3/4 | 修复中 |
CVE-2026-111943 | Golang | 仅使用 Go 应用的系统：TencentOS Server 2.4/3.1/3.3/4 | 修复中 |
CVE-2026-91403 | Java | 仅运行 Java 应用的系统： TencentOS Server 2.4/3.1/3.3/4 | 修复中 |
CVE-2026-114820 | Java | 仅运行 Java 应用的系统： TencentOS Server 2.4/3.1/3.3/4 | 修复中 |
CVE-2026-113812 | perl-Mozilla-CA | 不受影响 | 无需处理 |
CVE-2026-113470 | Firefox | 仅使用 Firefox 且无法访问 Mozilla Remote Settings 的环境：TencentOS Server 2.4/3.1/3.3/4 | 修复中 |
自查方式
以下命令均为只读，用于确认系统中是否存在相关组件、判断本机受影响范围：
# 1. 系统信任库：是否仍信任本次处置的两张根证书，有输出即受影响trust list --filter=ca-anchors | grep -iE 'Comodo AAA Services root|emSign ECC Root CA - G3'# 2. ca-certificates 版本rpm -q ca-certificates# 3. Go 工具链版本rpm -qa golang# 4. Java：已安装的 JDK / JRE、默认 java 指向、运行中的 Java 进程rpm -qa | grep -iE 'jdk|jre'readlink -f "$(command -v java)" 2>/dev/nullps -ef | grep -i '[j]ava'# 5. Firefox 版本rpm -q firefox# 6. Python：certifi 实际使用的证书文件# 指向 /etc/pki/... 为系统信任库；指向 site-packages 下的 cacert.pem 则为自带证书库python3 -c 'import certifi; print(certifi.where())' 2>/dev/null# 7. Node.js 版本：nodejs:20 / nodejs:16 使用系统信任库，nodejs:10 为内置证书库rpm -qa | grep -iE '^nodejs'; node -v 2>/dev/null# 8. 本机容器镜像：镜像自带信任库，不随宿主升级podman images 2>/dev/null || docker images 2>/dev/null
说明：
升级宿主机不会自动更新容器镜像、Python certifi、Node.js 内置 CA、应用自带 Java keystore 及其他独立维护的信任库，需进入对应环境单独确认并更新。
3. 解决方案
3.1 缓解方案：取消证书的信任
本方案适用于读取系统信任库的软件，执行后即时生效。以下情况需额外处理：Go 程序适用，但每个进程只在启动时加载一次信任库，需重启相关服务才生效；若程序显式指定了自定义根证书池，或用
SSL_CERT_FILE / SSL_CERT_DIR 指向其他证书，则本方案对其无效。Java 程序与容器镜像不适用，须分别升级 JDK、重建镜像。操作前提：需 root 权限，在同一个 Bash 会话中依次执行；先确认
trust、openssl、update-ca-trust 命令可用，不可用时请停止操作并确认工具安装状态。已有同名禁止信任文件会被提取命令覆盖，操作前请备份到信任库目录之外。任何一步失败或输出为空都应停止排查，不能将命令不存在或无输出视为处置成功。1. 用只读命令查看当前软件包版本，再将两张根证书提取到本地禁止信任目录（优先使用 blocklist 目录，没有时使用 blacklist 目录）：
rpm -q ca-certificatesd=/etc/pki/ca-trust/source/blocklist[ -d "$d" ] || d=/etc/pki/ca-trust/source/blacklisttest -d "$d" &&trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' "$d/emSign_ECC_Root_CA_-_G3.pem" &&test -s "$d/emSign_ECC_Root_CA_-_G3.pem" &&trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' "$d/Comodo_AAA_Services_root.pem" &&test -s "$d/Comodo_AAA_Services_root.pem"
openssl x509 -in "$d/emSign_ECC_Root_CA_-_G3.pem" -noout -subject -fingerprint -sha256openssl x509 -in "$d/Comodo_AAA_Services_root.pem" -noout -subject -fingerprint -sha256
3. 确认证书身份正确后，重新生成系统信任库：
update-ca-trust extract
4. 验证。检查系统证书包中是否仍包含这两张根证书，期望无匹配输出：
trust list --filter=ca-anchors | grep -iE 'Comodo AAA Services root|emSign ECC Root CA - G3'
注意：
请勿直接编辑
/etc/pki/tls/certs/ca-bundle.crt 等自动生成的文件，其内容会在执行 update-ca-trust 或升级软件包后被覆盖。本地禁止信任配置会影响 AAA Certificate Services 的全部用途（包括邮件保护），范围比正式软件包修复更广。确需回退时，应先评估恢复信任的安全风险并取得变更授权，再移除本次添加的两个 PEM 文件并执行 update-ca-trust extract 验证业务；回退可能重新引入对涉事证书链的信任，不应作为连接失败时的常规处理方式。3.2 正式修复
相关组件正在修复中，经过测试验证后发布，发布后本预警同步更新具体版本信息。
4. 常见问题
这是 TencentOS 的软件漏洞吗？
不是。这是第三方 CA 的私钥泄露事件。TencentOS 受到影响，是因为系统信任库包含能为涉事中间 CA 建立信任链的根证书。可通过取消根证书信任、并修复自带证书校验逻辑的组件来消除风险。
我的系统是否已经被攻击？
私钥泄露只意味着存在被攻击的可能，不代表系统已经被攻击。攻击者必须处于中间人位置，并出示用泄露私钥签发的伪造证书，才能实施攻击。
取消根证书信任后，业务连不上了怎么办？
说明服务方仍在沿用涉事证书链。正确做法是联系服务提供方更换为其他受信任 CA 签发的证书链，而不是关闭 TLS 校验、使用
curl -k 绕过校验，或把证书重新加回信任。业务没有购买或使用 eMudhra 证书，是否可以不处理？
不可以据此排除风险。攻击者可以伪造目标业务的证书，风险取决于客户端是否接受该证书链，而不是业务当前证书的签发机构。应检查实际信任库，并完成对应处置。
取消了系统信任库中的根证书，为什么还要处理 Go、Java 和其他独立证书库？
系统信任库的处置只覆盖实际使用且已加载该信任库的校验路径。Go 的相关验证代码通常编译在应用二进制中，需要修复后重新构建；Java 使用 JDK 自带的 cacerts，不读取系统信任库；容器镜像与其他内嵌证书库也要分别处理。不能假定处置系统信任库会自动修复所有应用。
