概述

• 2026 年 10 月 20 日，eMudhra CA 的私钥被证实已泄露（公开报道：问题源于密钥生成环节的实现错误，P-384 曲线对应的私钥数值异常小，可从公开证书中还原）。
• 受影响的 8 张中级 CA 中，6 张用于签发 TLS 证书，链至 emSign Root TLS CA – G3；2 张用于代码签名。此外存在由 Sectigo 签发、链至 AAA Certificate Services 的交叉签名副本。
• eMudhra CA 本身并不在 Ubuntu / Debian 的根信任库中，但上述两张根证书交叉签名了它，因此发行版的修复手段是移除这两张根证书。
• 强制校验证书透明度（CT）的浏览器（Chrome、Edge、Firefox、Safari）不受影响；而 curl、wget、git、apt、各类 SDK 等依赖系统信任库、且不检查吊销状态的组件会持续信任这些证书，必须通过本次更新修复。

风险影响

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

被移除的根证书

修复版本矩阵（Ubuntu LTS）

Ubuntu 本次发布了两份公告，对应两个相互独立的软件包，二者都需要升级：ca-certificates 提供系统 PKI 根信任库（USN-8944-1），libnss3 是 NSS 库自带的内置信任库（USN-8947-1）。因此下表每个发行版列出两个版本号，分别对应这两个包，不是同一个版本号重复。

修复版本矩阵（Debian）

Ubuntu 22.04/24.04/26.04修复步骤

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

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

dpkg -l ca-certificates 'libnss3*' | grep ^ii

（2）查阅系统信任库，直接确认两张根证书是否还在。以下四条命令只要有任意一条产生输出，说明本机信任库仍信任受影响的证书链：

1# 1）证书源文件是否还在（注意 AAA 根证书在不同版本有两种文件名）
2ls -l /usr/share/ca-certificates/mozilla/ 2>/dev/null \
3  | grep -iE 'emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root'
4# 2）是否已启用到系统信任目录
5ls /etc/ssl/certs/ | grep -iE 'emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root'
6# 3）启用清单（conf 中记录的是文件名，带下划线，不是证书显示名）
7grep -nE '^!?mozilla/(emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root)\.crt' /etc/ca-certificates.conf
8# 4）最权威：合并后的 CA 包按 subject 匹配，完全不依赖文件名
9openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
10  | openssl pkcs7 -print_certs -noout \
11  | grep -iE 'emSign ECC Root CA - G3|AAA Certificate Services'

判定口径：

命令 1、2、4 有输出 = 仍受影响，无输出 = 已清理。命令 3 要看行首：输出 mozilla/emSignECC_Root_CA-_G3.crt 且行首无 !，说明该根证书仍处于启用状态，即未修复；输出 !mozilla/... 表示已停用；无输出表示该行已随软件包更新从清单中移除，两者都属已修复。

第二步：应用更新

执行以下命令升级ca-certificates和libnss3包到最新版本

sudo apt update && sudo apt install --only-upgrade ca-certificates 'libnss3*'

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

重要：

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

`sudo apt install -y needrestart

sudo needrestart -r l`

needrestart 是什么：

它是一个独立的小工具，用于扫描正在运行的进程，找出哪些进程仍在使用已被更新替换掉的库文件或信任库，从而给出需要重启的服务清单，省去逐个猜测。参数 -r l 表示 list，只列出不自动操作；-r i 为交互式逐个询问；-r a 为自动重启。它只负责「发现并重启」，本身不做任何证书相关的修复。对于额外安装不在包管理范围内的服务，仍需要您手动检查是否引用证书链并进行重启。

EOL版本的临时规避（Ubuntu 18.04 / 20.04）

第一步：核对证书指纹，避免误删同名证书

1# 0）先确认本机发行版、openssl 与包版本，不要凭主机名判断
2. /etc/os-release; echo "$ID $VERSION_ID ($VERSION_CODENAME)"; openssl version
3dpkg-query -W -f='${Package} ${Version}\n' ca-certificates
4# 1）按证书主题扫描信任库并核对指纹（不要按文件名猜，文件名随版本变化）
5for f in /usr/share/ca-certificates/mozilla/*.crt; do
6  s=$(openssl x509 -in "$f" -noout -subject 2>/dev/null)
7  case "$s" in
8    *"AAA Certificate Services"*|*"emSign ECC Root CA - G3"*)
9      echo "FOUND: $f"
10      openssl x509 -in "$f" -noout -subject -fingerprint -sha256 ;;
11  esac
12done
13echo "---- scan done ----"

应与下列指纹逐字一致，不一致则停止操作：

• 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
• 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

第二步：停用这两张根证书

直接改配置文件，给目标行加 ! 前缀表示停用。

1# 0）关闭 bash 历史展开，否则双引号中的 ! 会被当成历史替换，报 event not found
2set +H
3# 1）按主题定位真实文件名（18.04 上为 Comodo_AAA_Services_root.crt，较新版本为 AAA_Certificate_Services.crt）
4TARGETS=$(for f in /usr/share/ca-certificates/mozilla/*.crt; do
5  openssl x509 -in "$f" -noout -subject 2>/dev/null \
6    | grep -qE 'CN ?= ?(AAA Certificate Services|emSign ECC Root CA - G3)' && basename "$f"
7done)
8echo "targets = ${TARGETS:-NONE}"
9# 若输出 NONE，不要继续往下执行，先回到第一步排查
10# 2）备份
11sudo cp -a /etc/ca-certificates.conf /etc/ca-certificates.conf.bak.$(date +%F)
12# 3）停用：含 ! 的替换串必须放在单引号内，文件名用变量拼接进来
13for n in $TARGETS; do
14  esc=$(printf '%s' "$n" | sed 's/\./\\./g')
15  sudo sed -i -E 's|^(mozilla/'"$esc"')$|!\1|' /etc/ca-certificates.conf
16  grep -nE '^!mozilla/'"$esc"'$' /etc/ca-certificates.conf \
17    || echo "WARN: $n 未被停用，请检查 /etc/ca-certificates.conf"
18done
19# 4）重建系统信任库
20sudo update-ca-certificates --fresh

libnss3:Ubuntu18.04/20.04的公共镜像没有预置libnss3-tools包，因此这两个版本镜像不受该漏洞影响

第三步：验证规避是否生效

1set -o pipefail
2# 1）证书不再出现在系统信任目录（兼容两种文件名）
3ls /etc/ssl/certs/ | grep -iE 'emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root'
4# 2）最权威：合并后的 CA 包按 subject 匹配，不依赖文件名
5subjects=$(openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt | openssl pkcs7 -print_certs -noout) \
6  && printf '%s\n' "$subjects" | grep -E 'subject=.*(AAA Certificate Services|emSign ECC Root CA - G3)'
7# 3）确认 CA 包未被读空，并与停用前的计数对比
8printf '%s\n' "$subjects" | grep -c '^subject='
9# 4）确认停用条目已写入 conf
10grep -nE '^!mozilla/' /etc/ca-certificates.conf

规避成功后，第一步和检查2的扫描仍会打印 FOUND，这是正常现象。! 前缀只是在清单中停用该条目，/usr/share/ca-certificates/mozilla/ 下的证书文件由软件包管理、不会被删除（只有升级 ca-certificates 到修复版本才会真正删掉）。因此判断是否生效只看第四步的四项结果，不要用第一步的扫描结果反推失败。 可重复执行：方式 B 的 sed 模式要求行首无 !，对已停用的行不再匹配，重复运行不会叠成 !!，证书计数也不会继续下降。 一次成功的输出基线（Ubuntu 18.04，仅 AAA Certificate Services 需处置）：grep 回显 42:!mozilla/Comodo_AAA_Services_root.crt，update-ca-certificates --fresh 报 132 added, 0 removed（停用前为 133），按 subject 匹配 bundle 无输出。

风险与回退

• 不要直接编辑 /etc/ssl/certs/ca-certificates.crt。它是自动生成文件，执行 update-ca-certificates 或升级软件包时会被覆盖。
• 取消根证书信任后，仅能链到这两张根 CA 的服务会出现 TLS 校验失败。应推动对端更换证书链，不要用 curl -k 等方式绕过校验。
• 回退需先评估重新引入信任的风险并取得变更授权：恢复备份的 /etc/ca-certificates.conf 后执行 sudo update-ca-certificates --fresh。回退不应作为连接失败时的常规处理手段。
• 操作前在测试机验证，必要时安排维护窗口；完成后仍需按第三步之外的常规要求重启长期运行的服务。

Debian 修复步骤

Debian 13（trixie）

按 DSA-6572-1 升级到 20250419+deb13u1。先确认 security 源已启用：

`grep -rE 'security' /etc/apt/sources.list /etc/apt/sources.list.d/

sudo apt update && sudo apt install --only-upgrade ca-certificates`

Debian 12（bookworm）

该版本没有单独的安全公告，升级 ca-certificates 到 20250419~deb12u2 即可：

`grep -rE 'security' /etc/apt/sources.list /etc/apt/sources.list.d/

sudo apt update && sudo apt install --only-upgrade ca-certificates`

两个版本通用的补充动作

• 升级前后同样使用「Ubuntu 22.04/24.04/26.04修复步骤」第一步中的信任库查阅命令确认结果，判定口径一致。
• Debian 的本次处置落在 ca-certificates 上；如机器上安装了 libnss3（Firefox、部分客户端会依赖），请一并执行常规安全更新，使其跟进上游 NSS 的信任库变更。
• 同样需要重启服务：本次更新无需重启系统，但正在运行的进程已把旧信任库读入内存，必须重启相关服务（Nginx、应用服务、容器内进程等）才会加载新的信任库。可用 needrestart 列出清单后逐个处理。对于额外安装不在包管理范围内的服务，仍需要您手动检查是否引用证书链并进行重启。

`sudo apt install -y needrestart

sudo needrestart -r l`

修复是否成功：验证清单

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

1dpkg -l ca-certificates 'libnss3*' | grep ^ii
2# 自动化判定（示例：Debian 13，注意，这里的版本号需要根据修复矩阵 手动替换 为对应的版本号）
3dpkg --compare-versions "$(dpkg-query -W -f='${Version}' ca-certificates)" ge 20250419+deb13u1 \
4  && echo "ca-certificates OK" || echo "ca-certificates NOT FIXED"

预期：版本不低于上文矩阵中对应发行版的修复版本。

检查 2：两张根证书已从系统信任库移除

1ls /usr/share/ca-certificates/mozilla/ | grep -iE 'emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root'
2ls /etc/ssl/certs/ | grep -iE 'emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root'
3grep -nE '^!?mozilla/(emSign_ECC_Root_CA_-_G3|AAA_Certificate_Services|Comodo_AAA_Services_root)\.crt' /etc/ca-certificates.conf

预期：前两条命令无输出；第三条无输出，或输出行首带 !。若输出 mozilla/emSignECC_Root_CA-_G3.crt 且行首没有 !，说明该根证书仍被启用，更新未生效。

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

1openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
2  | openssl pkcs7 -print_certs -noout \
3  | grep -iE 'emSign ECC Root CA - G3|AAA Certificate Services'
4# 等价写法（storeutl 必须带 -text，否则只输出序号行）
5openssl storeutl -noout -text -certs /etc/ssl/certs/ca-certificates.crt \
6  | grep -iE 'emSign ECC Root CA - G3|AAA Certificate Services'

预期：无输出。crl2pkcs7 写法在 OpenSSL 1.0.x 上同样可用，16.04 / 14.04 也适用。判定前先用 grep -c '^subject=' 确认读到的证书总数正常（130 张以上），避免把"包被读空"误判为"证书已移除"。

检查 4：NSS 内置信任库（Ubuntu 需执行）

1# 1）先定位真实路径（libnssckbi.so 在 nss/ 子目录下，单层通配匹配不到）
2NSSCKBI=$(dpkg -L libnss3 | grep -E 'libnssckbi\.so$' | head -n1)
3echo "path = ${NSSCKBI:-NOT FOUND}"
4ls -l "$NSSCKBI" && readlink -f "$NSSCKBI"
5# 2）直接匹配二进制中的证书显示名
6grep -aoE 'emSign ECC Root CA - G3|AAA Certificate Services' "$NSSCKBI"

预期：第 1 步能打印出真实路径（形如 /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so），第 2 步无输出。注意，若第 1 步打印 NOT FOUND，说明路径没取到，此时第 2 步的"无输出"不能作为修复证据。最终仍以检查 1 中 libnss3 的版本为准。

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

`sudo needrestart -r l # 列出仍在使用旧库的服务

sudo lsof 2>/dev/null | grep -c 'ca-certificates.crt (deleted)'` 预期：没有服务仍引用已删除的旧信任库文件，计数为 0；否则重启对应服务。

注意事项

移除根证书会带来副作用：由这两张根 CA 最终签发的合法证书也将不再被信任，少量站点或内部服务可能出现证书校验失败。这是与 Debian、Mozilla NSS 等上游一致的预期行为，不是更新出错。遇到此类失败应推动对端更换证书链，不要把根证书重新加回信任库。

更新系统信任库只覆盖读取系统根 CA 存储的组件。自带证书包的客户端（如 snap 形式的浏览器、部分语言生态的运行时与包管理器、固化了旧信任库的容器镜像）需要按各自上游公告单独升级或重建。

参考原文

1. Canonical, eMudhra CA compromise fixes available（2026-10-20 发布，10-22 更新）
2. Ubuntu Security Notice, USN-8944-1: ca-certificates update
3. Ubuntu Security Notice, USN-8947-1: NSS update（2026-10-21）
4. Debian Security, DSA-6572-1
5. Launchpad Bug, nss compromised certs tracking bug