前言
2026年10月Oracle披露的CVE-2026-91403（CVSS 9.1）是近期影响范围极广的证书信任漏洞。很多运维团队的修复动作仅停留在JDK层面，却忽略了一个关键事实：操作系统证书库是全系统共用的信任根，curl、wget、Python脚本、Nginx反向代理、系统包管理器等所有依赖系统证书的应用，都共享同一条风险信任链。只修复JDK而不清理系统证书，相当于只封堵了一半的攻击面。
本文从漏洞原理出发，覆盖独立JDK、系统包管理器安装JDK、系统级证书等全场景修复方案，补充了Ubuntu环境下底层证书残留的彻底清理实操与效果验证方法，并整理生产环境高频踩坑点，帮助团队完成完整闭环的风险处置。
发布日期：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各维护一套独立的信任库：
- 信任预置：系统证书库与Java自带的cacerts信任库中，均预置了eMudhra旗下emSign的多根根证书（G1、C1、G3、C3）。
- 私钥缺陷：eMudhra签发的一批中间CA证书私钥强度不足，可被推导或利用。
- 证书伪造：攻击者利用弱私钥为任意目标域名签发证书，证书链可完整回溯到被信任的emSign根证书。
- 中间人劫持：攻击者通过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：
sudoaptupdatesudoaptinstall--only-upgrade ca-certificates ca-certificates-javaUbuntu安全公告USN-8944-1明确该更新会移除emSign全系列根证书；ca-certificates-java负责将系统证书同步至Java环境。
RHEL / CentOS / Fedora：
sudoyum update ca-certificates# 或sudodnf update ca-certificates方案三：替换黑名单文件（独立JDK临时缓解）
无法立即升级JDK时，可替换官方证书黑名单文件临时阻断风险。
说明：官方下载地址https://ops.java/unix/blocked.certs当前可能访问异常，无法下载时优先选择升级JDK，或从最新版OpenJDK安装包中提取对应文件。
操作步骤：
- 获取官方
blocked.certs文件 - 备份原文件：
# JDK 9+cp$JAVA_HOME/lib/security/blocked.certs$JAVA_HOME/lib/security/blocked.certs.bak# JDK 8cp$JAVA_HOME/jre/lib/security/blacklisted.certs$JAVA_HOME/jre/lib/security/blacklisted.certs.bak - 替换文件：
- JDK 8：重命名为
blacklisted.certs，覆盖$JAVA_HOME/jre/lib/security/ - JDK 9+：保持原名
blocked.certs，覆盖$JAVA_HOME/lib/security/
- JDK 8：重命名为
- 必须重启所有Java进程，黑名单才会加载生效。
局限性：黑名单基于SHA-256指纹拦截，存在被攻击者通过证书重编码绕过的可能，仅作为临时缓解手段，后续仍需升级JDK。
方案四：JVM参数加固（补充防御）
在JVM启动参数中加入证书吊销检查，作为额外防御层：
-Dcom.sun.net.ssl.checkRevocation=true-Dcom.sun.security.enableCRLDP=true五、进阶实操：Ubuntu系统底层彻底清理残留证书
部分Ubuntu版本的update-ca-certificates增量更新存在残留问题，执行apt升级后仍可能查到emSign证书。如需物理级彻底清理，可选择以下两种方式。
方式一：应急快速清理（直接删除物理文件）
适合紧急处置场景，操作简单见效快，安全效果达标，但会残留配置警告。
- 查找系统中所有emSign证书文件（通常共4个：G1、C1、G3、C3）
find/usr/share/ca-certificates/-iname'*emsign*' - 物理删除证书文件并强制刷新证书库
sudorm/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.crtsudoupdate-ca-certificates--fresh
说明：执行后会出现4条
W: ... not found警告，仅为配置一致性提示，不影响任何安全效果，证书已从系统生效信任库中移除；后续每次刷新证书都会重复该提示，属于运维残留。
方式二：规范无告警清理（修改配置清单）
推荐生产环境使用，符合系统设计逻辑，无残留告警。
# 从配置清单中移除所有emSign证书启用条目sudosed-i'/emSign/d'/etc/ca-certificates.conf# 强制重建系统证书库sudoupdate-ca-certificates--fresh修复效果验证
系统层验证（最核心标准）：无任何输出即为清理干净
awk-vcmd='openssl x509 -noout -subject''/BEGIN/{close(cmd)};{print | cmd}'</etc/ssl/certs/ca-certificates.crt|grep-iemsignJava层验证：官方修复为拉黑中间证书而非删除根证书，因此cacerts中仍可能查到emSign根证书，属于正常现象。可通过对比黑名单文件行数确认更新，最终以业务HTTPS外呼正常为准。
六、生产环境避坑指南
系统与JDK是两套独立体系，必须同步处理
系统证书库服务于全系统应用，JDK自带信任库仅服务于Java进程。只修JDK不修系统，curl、Python等应用仍存在风险；只修系统不修独立JDK，Java业务仍会受影响，二者缺一不可。修改后必须重启对应进程
JVM启动时才加载信任库与黑名单，替换文件后必须重启Java进程；系统证书更新后，依赖证书的常驻服务（如Nginx、Java应用）也需重启才能加载新配置。警惕自定义TrustStore
若应用通过-Djavax.net.ssl.trustStore指定了专属JKS证书库，该文件不会随系统或JDK自动更新，必须单独检查并清理其中的emSign证书。不要盲目全删根证书
JDK层面不建议手动删除cacerts中的eMudhra根证书，官方策略是精准拦截问题中间证书，误删根证书可能导致正常使用emSign证书的业务中断。不要依赖增量更新，以实际证书校验为准
部分Ubuntu版本的update-ca-certificates默认采用增量更新逻辑，即使升级了ca-certificates包，也可能在最终的证书bundle中残留旧条目。执行时务必加上--fresh参数强制重建证书库，且修复完成必须通过openssl扫描实际生效的证书文件验证，不能仅以包版本更新就判定修复完成。
