事件背景

• 2026 年 10 月，eMudhra CA 的私钥被证实已泄露（密钥生成环节实现错误，P-384 曲线对应的私钥数值异常小，可从公开证书中还原）。受影响的中级 CA 有 16 份（8 份由 emSign 根签发、8 份为 Sectigo 交叉签名副本），其中多数用于签发 TLS 证书。
• eMudhra 中级 CA 链至两条根：emSign ECC Root CA - G3（经 emSign Root TLS CA - G3 中级）与经 Sectigo 交叉签名的 AAA Certificate Services（Comodo AAA Services root）。这两张根证书都在 RHEL 系的系统信任库（ca-certificates 包）中，因此发行版的修复手段是取消信任这两张根证书。
• Red Hat 的总纲公告为 RHSB-2026-012（CVE-2026-114406）。RHEL 8/9/10 有正式 errata；Rocky / AlmaLinux / Oracle Linux 跟随 Red Hat 的包。强制校验证书透明度（CT）的浏览器不受影响；而 curl、wget、git、dnf/yum、各类 SDK 等依赖系统信任库、不检查吊销状态的组件会持续信任这些证书，必须通过本次更新修复。
• 注意节奏：Red Hat 10-20 的首批 errata 只取消了 emSign Root TLS CA - G3 与 AAA Certificate Services，保留了 emSign ECC Root CA - G3；10-23 的重建版本才把 emSign ECC Root CA - G3 也一并取消。只有升级到 10-23 重建版本（见下表）才算修复完整。

风险影响

攻击者在具备流量劫持或重定向能力的前提下，可伪造任意 TLS 端点身份，实施中间人攻击，破坏连接的机密性与完整性，且与真实站点使用哪家 CA 无关。公钥固定（pinning）与 DNS CAA 记录可帮助发现此类伪造证书，但依赖应用主动启用，实际使用率很低。

需要取消信任的根证书

处置策略总览

• Rocky 8/9/10, BaiduLinux 4.1/5.0（生命周期内） → dnf update ca-certificates，由上游分发包完成取消信任。
• CentOS 7 / CentOS 8 / BaiduLinux 2.0/3.0（已 EOL，含 CentOS Stream 8） → 上游不再发布更新，手动将两张根证书放入本地 blocklist 目录，再重建信任库。

修复版本矩阵

Rocky Linux和BaiduLinux 4.1

Rocky 与 RHEL 使用相同 NVR，以下为 10-23 重建版本（取消信任两张根证书的完整修复版本）

BaiduLinux 5.0

Rocky 8/9/10,BaiduLinux 4.1/5.0 修复步骤

第一步：确认当前是否受影响

1）核对软件包版本，低于上文矩阵即为受影响：

rpm -q ca-certificates

（2）查阅系统信任库，直接确认两张根证书是否还被信任。以下命令有输出 = 仍受影响：

1# a) p11-kit 信任锚列表（RHEL 原生方式，最直观）
2#    注意：Comodo 那张根在 trust list 里的 label 是 "Comodo AAA Services root"，
3#    不是 subject 的 "AAA Certificate Services"，grep 要用 label 名
4trust list --filter=ca-anchors \
5  | grep -iE 'emSign ECC Root CA - G3|Comodo AAA Services root'
6# b) 合并后的 CA bundle（按 subject，权威）
7openssl crl2pkcs7 -nocrl -certfile /etc/pki/tls/certs/ca-bundle.crt \
8  | openssl pkcs7 -print_certs -noout \
9  | grep -iE 'emSign ECC Root CA - G3|AAA Certificate Services'

第二步：应用更新

1sudo dnf clean all
2sudo dnf update -y ca-certificates
3sudo update-ca-trust extract

第三步：重启受影响的服务

本次更新不需要重启系统，但必须重启长期运行的服务，否则修复不生效。 进程通常启动时一次性把信任库读入内存，升级软件包不影响已运行的进程。重点关注：Nginx / Apache 等反向代理与 Web 服务、常驻应用服务、消息队列与数据库客户端、容器内进程（需重建或重启容器）。

1# el8+：needs-restarting 在 dnf-utils 中
2sudo dnf install -y dnf-utils
3sudo needs-restarting -s      # 列出需重启的服务
4sudo needs-restarting -r      # 判断是否需要重启系统

注意 needs-restarting 的局限： 它检测的是内核/共享库更新后是否需重启，而 ca-certificates 更新的是数据文件（提取出的 bundle），因此它基本不会据此报告任何服务，Reboot should not be necessary 不能证明在跑的服务已加载新信任库。判断服务是否仍握着旧 bundle，以验证清单检查 5 的 lsof 为准。

对于额外安装、不在包管理范围内的服务，仍需手动检查其是否引用证书链并重启。

CentOS 7 / CentOS 8 / BaiduLinux 2.0/3.0（已 EOL）手动处置步骤

CentOS 7和BaiduLinux 2.0（2024-06-30 EOL）与 CentOS 8和BaiduLinux 3.0 / CentOS Stream 8（2021-12-31 / 2024-05-31 EOL）上游不再发包。按 Red Hat KB 7149312 的思路，用信任库自带的 blocklist 机制取消信任，不要直接删除 bundle 文件。

`blocklist 目录名因 p11-kit 版本而异：

• CentOS 7 / CentOS 8（p11-kit 0.23.x）：/etc/pki/ca-trust/source/blacklist/（el7、el8 均实测确认用此目录，系统默认已存在）
• 较新 p11-kit（RHEL 9/10）：/etc/pki/ca-trust/source/blocklist/

不确定时用 man update-ca-trust 查本机实际目录名；不存在则 mkdir -p。`

1. 把两张根证书提取到 blocklist/blacklist 目录

用 trust extract 按 trust 标签 直接抠到禁止信任目录；--overwrite 避免目标已存在时报错。优先 blocklist，没有则 blacklist。

1d=/etc/pki/ca-trust/source/blocklist
2[ -d "$d" ] || d=/etc/pki/ca-trust/source/blacklist
3test -d "$d" \
4 && trust extract --overwrite --format=pem-bundle \
5      --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
6      "$d/Comodo_AAA_Services_root.pem" && test -s "$d/Comodo_AAA_Services_root.pem" \
7 && trust extract --overwrite --format=pem-bundle \
8      --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
9      "$d/emSign_ECC_Root_CA_-_G3.pem" && test -s "$d/emSign_ECC_Root_CA_-_G3.pem"

关键：object= 填的是 trust 标签，不是 subject CN。 Comodo 那张的 trust 标签是 Comodo AAA Services root（它的 subject CN 才是 AAA Certificate Services）。用 CN 去 filter 会抠出空文件；再漏掉 --overwrite，在 el8 上还会报 p11-kit: couldn't complete writing ... Unknown error 17。用对标签 + --overwrite 后，el8 实测正常。emSign 那张标签与 CN 相同，无此坑。

2. 核对指纹（务必校验，防止误删）

1openssl x509 -in "$d/Comodo_AAA_Services_root.pem" -noout -fingerprint -sha256
2# 期望: 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
3openssl x509 -in "$d/emSign_ECC_Root_CA_-_G3.pem"  -noout -fingerprint -sha256
4# 期望: 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

$d为上一步中的设置变量。指纹不一致时不要继续，重新核对来源。

3. 重建信任库

update-ca-trust extract

备选方式 - trust 不可用时，从 bundle 用 awk 抠取后再放进禁止目录：

1BUNDLE=/etc/pki/tls/certs/ca-bundle.crt
2dump=$(openssl crl2pkcs7 -nocrl -certfile "$BUNDLE" | openssl pkcs7 -print_certs)
3extract() {  # $1 = 证书名（只写裸名，不带 CN=）
4  printf '%s\n' "$dump" | awk -v cn="$1" '
5    index($0,"subject=")==1 && index($0,cn){grab=1}
6    grab && /-----BEGIN CERTIFICATE-----/{inc=1}
7    inc{print}
8    /-----END CERTIFICATE-----/{if(inc)exit}'
9}
10d=/etc/pki/ca-trust/source/blocklist; [ -d "$d" ] || d=/etc/pki/ca-trust/source/blacklist
11extract "AAA Certificate Services"  > "$d/Comodo_AAA_Services_root.pem"
12extract "emSign ECC Root CA - G3"   > "$d/emSign_ECC_Root_CA_-_G3.pem"
13# 同样先核对指纹（见步骤 2），再 update-ca-trust extract

备选方式的坑（el7/el8 实测）：匹配串只写裸证书名、不要带 CN=。 openssl pkcs7 -print_certs 的 subject 行格式随版本不同：el7（openssl 1.0.2）CN=AAA...、el8（1.1.1）CN = AAA...（带空格）。硬编码 CN= 在 el8 匹配不到会产出空文件。方式 B 在 el7、el8 均实测通过。

4. 同样需要重启服务

机制与 Rocky 一致：正在运行的进程已把旧信任库读入内存，必须重启相关服务（Nginx、应用服务、容器内进程等）才会加载新信任库。EOL 系统上 needs-restarting 可能不可用，可用 lsof 自查（见验证清单检查 5）。

修复是否成功：验证清单

检查 1：软件包版本已达修复版本

1rpm -q ca-certificates
2# 自动化判定：按本机发行版从矩阵取对应 release 串（el8_10 / el9_8 / el10_2）
3# Rocky 8 用 81.3.el8_10；Rocky 9 用 90.3.el9_8；Rocky 10 用 100.3.el10_2
4rel='100.3.el10_2'   # ← 改成本机对应值
5rpm -q ca-certificates | grep -q "$rel" && echo "ca-certificates OK" || echo "NOT FIXED"

预期： 版本不低于矩阵中对应发行版的修复版本。注意判定串必须匹配本机发行版——用 el9 的串去判 el10 机器会得到误报的 "NOT FIXED"。

检查 2：两张根证书已从信任锚列表移除

`trust list --filter=ca-anchors \

| grep -iE 'emSign ECC Root CA - G3|Comodo AAA Services root|AAA Certificate Services'`

预期： 无输出。

注意 trust list 的 label 与 subject CN 不一致： Comodo 那张根在 trust list 里的 label 是 Comodo AAA Services root，而它的 subject CN 是 AAA Certificate Services。只 grep AAA Certificate Services 会在 trust list 上漏掉它，所以上面两个名字都要匹配。最权威的判定是下面检查 3 的 ca-bundle（按 subject） 校验。

检查 3：合并后的 CA bundle 内已无这两张根证书

set -o pipefail 确保 openssl 流水线失败时不会误判为"已移除"；CN ?= ? 同时兼容 el7（CN=）和 el8（CN = ）两种 subject 格式：

1set -o pipefail
2subjects=$(openssl crl2pkcs7 -nocrl -certfile /etc/pki/tls/certs/ca-bundle.crt \
3  | openssl pkcs7 -print_certs -noout) \
4  && printf '%s\n' "$subjects" \
5  | grep -E 'subject=.CN ?= ?(AAA Certificate Services|emSign ECC Root CA - G3)'

预期： 无匹配输出、且 grep 退出码为 1（正常的"无匹配"）。只有在证书列表成功提取、openssl 无报错、grep 无输出时，才算两张根已不在 bundle 中；若打印出 subject，或出现读取/解析报错，都不能认定成功。

检查 4：应用自带 / NSS 信任库

RHEL 系多数应用通过 p11-kit 共享系统信任（/usr/lib64/pkcs11/p11-kit-trust.so），检查 2/3 已覆盖。但以下自带独立证书库，需单独处理：

• Java：JDK 自带 cacerts（$JAVA_HOME/lib/security/cacerts），用 keytool -list -alias <别名> 查、keytool -delete 删，或升级 JDK。
• Python：certifi 自带 bundle（python -m certifi 看路径），升级 certifi 或改用系统 CA。
• Node.js：内置 CA，用 --use-system-ca / NODE_EXTRA_CA_CERTS，或升级版本。
• Go：静态程序可能内嵌证书，随应用更新。
• 独立 NSS 库（部分浏览器、客户端自建 nssdb）：单独更新。

检查 5：运行中的进程已加载新信任库

1# Rocky（dnf-utils 已装）
2sudo needs-restarting -s
3# 通用：查找仍引用已删除旧信任库文件的进程
4sudo lsof 2>/dev/null | grep -cE 'ca-bundle\.crt \(deleted\)|tls-ca-bundle\.pem \(deleted\)'

预期： 计数为 0；否则重启对应服务。

注意事项

• 取消信任会带来副作用： 由这两张根 CA 最终签发的合法证书也将不再被信任，少量站点或内部服务可能出现证书校验失败。这是与上游一致的预期行为，不是更新出错。遇到此类失败应推动对端更换证书链，不要把根证书重新加回信任库。
• 更新系统信任库只覆盖读取系统根 CA 存储的组件；自带证书包的运行时与固化了旧信任库的容器镜像需按各自上游公告单独升级或重建。
• EOL 系统（CentOS 7/8）长期不再收到安全更新，手动 blocklist 只是止血措施，建议规划迁移到 Rocky / Alma 等在维护发行版。

参考原文

1. Red Hat, RHSB-2026-012 Certificate compromise - eMudhra (CVE-2026-114406, CVE-2026-111943, CVE-2026-91403, CVE-2026-113812)
2. Red Hat, RHSA-2026:88455 - Security Advisory
3. Red Hat KB 7149312（RHEL 系 blocklist 处置方法，自 RHSB-2026-012 链接）
4. Oracle Linux ELSA-2026-88550 / 88459 / 88455（el8/el9/el10 重建版本，可核对 NVR）；OL7 ELSA-2026-500496