CVE-2026-91403 高危漏洞预警：Java JSSE 信任链被攻破 全场景修复方案与Linux系统级彻底清理实操

前言

2026年10月Oracle披露的CVE-2026-91403（CVSS 9.1）是近期影响范围极广的证书信任漏洞。很多运维团队的修复动作仅停留在JDK层面，却忽略了一个关键事实：操作系统证书库是全系统共用的信任根，curl、wget、Python脚本、Nginx反向代理、系统包管理器等所有依赖系统证书的应用，都共享同一条风险信任链。只修复JDK而不清理系统证书，相当于只封堵了一半的攻击面。

本文从漏洞原理出发，覆盖独立JDK、系统包管理器安装JDK、系统级证书等全场景修复方案，补充了Linux环境下底层证书残留的彻底清理实操与效果验证方法，并整理生产环境高频踩坑点，帮助团队完成完整闭环的风险处置。

---

发布日期 ：2026-10-23

标签：Java安全 / CVE-2026-91403 / JSSE / 中间人攻击 / 证书信任链

一、漏洞概述与背景

2026年10月21日，Oracle官方发布安全快讯，披露了Java SE与GraalVM中的高危证书信任漏洞CVE-2026-91403。该漏洞位于JSSE加密通信组件，CVSS 3.1评分高达9.1，攻击者无需身份认证即可远程利用。

核心风险是：Java默认信任了eMudhra（emSign）存在私钥缺陷的中间CA证书，攻击者可在网络中间路径为任意域名伪造合法SSL证书，劫持Java应用的HTTPS通信，窃取支付凭据、API密钥等敏感数据。

重要提醒 ：风险不止局限于Java应用。操作系统级的证书库是公共信任根，curl、wget、Python脚本、Nginx反向代理、系统包管理器等所有依赖系统证书的应用，都会受这条信任链影响。只修复JDK而不清理系统证书，等于只封堵了一半风险面。

二、漏洞原理：攻击是如何生效的

HTTPS/TLS的安全建立在证书链信任之上，而系统与Java各维护一套独立的信任库：

1. 信任预置：系统证书库与Java自带的cacerts信任库中，均预置了eMudhra旗下emSign的多根根证书（G1、C1、G3、C3）。
2. 私钥缺陷：eMudhra签发的一批中间CA证书私钥强度不足，可被推导或利用。
3. 证书伪造：攻击者利用弱私钥为任意目标域名签发证书，证书链可完整回溯到被信任的emSign根证书。
4. 中间人劫持：攻击者通过DNS劫持、路由污染插入通信链路，出示伪造证书即可通过信任校验，进而窃取或篡改全量通信数据。

高风险场景：所有主动外呼HTTPS的服务，包括支付网关调用、外部API请求、CI/CD依赖拉取、系统自动化脚本等。

三、受影响版本清单

根据OpenJDK官方公告，以下JDK版本及更早均受影响：

产品	受影响版本
Java SE / OpenJDK	8u512、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1
GraalVM for JDK	对应上述JDK版本
GraalVM Enterprise Edition	21.3.20 及更早

注：所有使用系统证书库的非Java应用同样存在同类中间人攻击风险，需同步做系统级清理。

四、修复方案大全（按场景分类）

方案一：升级JDK版本（首选，最彻底）

升级到官方修复版本是最彻底的方式，修复版本通过内置黑名单精准拦截受影响的中间证书。

• 独立安装的OpenJDK / Temurin / Oracle JDK：升级至高于上表所列的版本。
• 系统包管理器安装的JDK：同步执行系统证书更新（见方案二）。

方案二：操作系统证书更新（系统级修复）

通过包管理器更新系统证书库，修复范围覆盖全系统所有依赖系统证书的应用，包括apt安装的JDK、curl、wget、Python、Nginx等。

Ubuntu / Debian：

sudo apt update
sudo apt install --only-upgrade ca-certificates ca-certificates-java

Ubuntu安全公告USN-8944-1明确该更新会移除emSign全系列根证书；ca-certificates-java负责将系统证书同步至Java环境。

RHEL / CentOS / Fedora：

sudo yum update ca-certificates
# 或
sudo dnf update ca-certificates

方案三：替换黑名单文件（独立JDK临时缓解）

无法立即升级JDK时，可替换官方证书黑名单文件临时阻断风险。

说明：官方下载地址https://ops.java/unix/blocked.certs当前可能访问异常，无法下载时优先选择升级JDK，或从最新版OpenJDK安装包中提取对应文件。

操作步骤：

1. 获取官方blocked.certs文件

2. 备份原文件：

   # JDK 9+
   cp $JAVA_HOME/lib/security/blocked.certs $JAVA_HOME/lib/security/blocked.certs.bak
   # JDK 8
   cp $JAVA_HOME/jre/lib/security/blacklisted.certs $JAVA_HOME/jre/lib/security/blacklisted.certs.bak

3. 替换文件：

   • JDK 8：重命名为blacklisted.certs，覆盖$JAVA_HOME/jre/lib/security/
   • JDK 9+：保持原名blocked.certs，覆盖$JAVA_HOME/lib/security/

4. 必须重启所有Java进程，黑名单才会加载生效。

局限性：黑名单基于SHA-256指纹拦截，存在被攻击者通过证书重编码绕过的可能，仅作为临时缓解手段，后续仍需升级JDK。

方案四：JVM参数加固（补充防御）

在JVM启动参数中加入证书吊销检查，作为额外防御层：

-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true

五、进阶实操：Linux系统底层彻底清理残留证书

部分Linux版本的update-ca-certificates增量更新存在残留问题，执行apt升级后仍可能查到emSign证书。如需物理级彻底清理，可选择以下两种方式。

方式一：应急快速清理（直接删除物理文件）

适合紧急处置场景，操作简单见效快，安全效果达标，但会残留配置警告。

1. 查找系统中所有emSign证书文件（通常共4个：G1、C1、G3、C3）

   find /usr/share/ca-certificates/ -iname '*emsign*'

2. 物理删除证书文件并强制刷新证书库

   sudo rm /usr/share/ca-certificates/mozilla/emSign_ECC_Root_CA_-_G3.crt \
           /usr/share/ca-certificates/mozilla/emSign_Root_CA_-_C1.crt \
           /usr/share/ca-certificates/mozilla/emSign_Root_CA_-_G1.crt \
           /usr/share/ca-certificates/mozilla/emSign_ECC_Root_CA_-_C3.crt
   
   sudo update-ca-certificates --fresh

说明：执行后会出现4条W: ... not found警告，仅为配置一致性提示，不影响任何安全效果，证书已从系统生效信任库中移除；后续每次刷新证书都会重复该提示，属于运维残留。

方式二：规范无告警清理（修改配置清单）

推荐生产环境使用，符合系统设计逻辑，无残留告警。

# 从配置清单中移除所有emSign证书启用条目
sudo sed -i '/emSign/d' /etc/ca-certificates.conf

# 强制重建系统证书库
sudo update-ca-certificates --fresh

修复效果验证

系统层验证（最核心标准）：无任何输出即为清理干净

awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i emsign

Java层验证：官方修复为拉黑中间证书而非删除根证书，因此cacerts中仍可能查到emSign根证书，属于正常现象。可通过对比黑名单文件行数确认更新，最终以业务HTTPS外呼正常为准。

六、生产环境避坑指南

1. 系统与JDK是两套独立体系，必须同步处理

   系统证书库服务于全系统应用，JDK自带信任库仅服务于Java进程。只修JDK不修系统，curl、Python等应用仍存在风险；只修系统不修独立JDK，Java业务仍会受影响，二者缺一不可。

2. 修改后必须重启对应进程

   JVM启动时才加载信任库与黑名单，替换文件后必须重启Java进程；系统证书更新后，依赖证书的常驻服务（如Nginx、Java应用）也需重启才能加载新配置。

3. 警惕自定义TrustStore

   若应用通过-Djavax.net.ssl.trustStore指定了专属JKS证书库，该文件不会随系统或JDK自动更新，必须单独检查并清理其中的emSign证书。

4. 不要盲目全删根证书

   JDK层面不建议手动删除cacerts中的eMudhra根证书，官方策略是精准拦截问题中间证书，误删根证书可能导致正常使用emSign证书的业务中断。

5. 不要依赖增量更新，以实际证书校验为准

   部分Linux版本的update-ca-certificates默认采用增量更新逻辑，即使升级了ca-certificates包，也可能在最终的证书bundle中残留旧条目。执行时务必加上--fresh参数强制重建证书库，且修复完成必须通过openssl扫描实际生效的证书文件验证，不能仅以包版本更新就判定修复完成。

清理前：

清理后：