本文详解 java 运行时因系统 hosts 文件异常导致 ssl 证书验证失败（pkix path building failed）的根本原因、精准定位方法及安全修复步骤，适用于 jdk 11/17+ 环境下 gradle、maven、forge 安装器等工具的 https 请求中断问题。
本文详解 java 运行时因系统 hosts 文件异常导致 ssl 证书验证失败（pkix path building failed）的根本原因、精准定位方法及安全修复步骤，适用于 jdk 11/17+ 环境下 gradle、maven、forge 安装器等工具的 https 请求中断问题。
当 Java 应用（如 Gradle、Maven 或 Forge Installer）在发起 HTTPS 请求时抛出 PKIX path building failed: unable to find valid certification path to requested target 错误，绝大多数情况下并非 cacerts 证书库损坏或缺失，而是底层网络解析被意外劫持——而罪魁祸首往往藏在 Windows 系统最基础的网络配置文件中。
? 根本原因：hosts 文件被非法篡改
尽管错误堆栈指向证书信任链验证失败（SunCertPathBuilderException），但实际触发条件常为 DNS 解析异常：某些第三方软件（如旧版代理工具、恶意清理程序、过时的开发辅助工具）会在 C:\Windows\System32\drivers\etc\ 目录下生成非标准 hosts 文件（例如 host、hosts.bak、hosts.old，甚至大小写变异如 HOSTS），或向标准 hosts 文件中注入错误条目（如将 repo.gradle.org、maven-central.storage.googleapis.com 等域名映射到 127.0.0.1 或无效 IP）。这会导致 Java 的 HttpsURLConnection 在 TLS 握手前就解析到错误地址，后续证书校验自然失败——因为目标服务器并非真实 CA 签发证书的合法服务端。
⚠️ 注意：此问题与 JAVA_HOME、PATH、cacerts 路径无关。重装 JDK、重置环境变量、甚至手动导入根证书均无法解决，因其本质是网络层拦截，而非证书信任问题。
✅ 正确修复步骤（安全、彻底）
1. 定位并清理异常 hosts 相关文件
以管理员身份打开 PowerShell 或 CMD，执行：
立即学习“Java免费学习笔记（深入）”；
# 进入 hosts 目录
cd C:\Windows\System32\drivers\etc
# 列出所有疑似 hosts 文件（含隐藏/备份/大小写变体）
dir hosts*, host*, *.bak, *.old | Where-Object { $_.Name -notmatch "^hosts$" } | ForEach-Object {
Write-Host "⚠️ 发现可疑文件: $($_.Name)" -ForegroundColor Yellow
# 建议先重命名备份（而非直接删除）
Rename-Item $_.FullName "$($_.FullName).backup_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
}2. 检查并修正标准 hosts 文件
用记事本（务必以管理员权限运行）打开 C:\Windows\System32\drivers\etc\hosts，确保其内容仅包含默认注释与本地回环条目：
# Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host 127.0.0.1 localhost ::1 localhost
✅ 删除所有指向公共 Maven/Gradle 仓库（如 repo.maven.apache.org, repo.gradle.org, jcenter.bintray.com）或云服务域名（如 storage.googleapis.com）的自定义映射行。
3. 验证修复效果
重启终端，清除 Java 缓存（可选）：
# 清除 Gradle 缓存（避免旧失败状态干扰） gradle --stop rm -rf ~/.gradle/caches/ # 测试 HTTPS 连通性（无需证书操作） curl -I https://repo.maven.apache.org/maven2/ # 应返回 200 OK
再次运行 Gradle 或其他 Java 工具，错误应立即消失。
? 为什么 keytool 导入证书不是正解？
- keytool -importcert 需要目标服务器的 .cer 文件，而现代 HTTPS 服务（如 Maven Central）使用动态证书链，且其根 CA（如 DigiCert Global Root G2）已预置于 JDK cacerts 中；
- 强制导入中间证书反而可能破坏信任链完整性；
- 问题根源不在证书缺失，而在请求根本未抵达正确服务器。
✅ 最佳实践建议
- 禁止非管理员修改 C:\Windows\System32\drivers\etc\：通过组策略（Computer Configuration → Windows Settings → Security Settings → File System）限制该目录写权限；
- 使用 nslookup 快速诊断：nslookup repo.maven.apache.org 应返回权威 DNS 解析结果（如 151.101.2.209），若返回 127.0.0.1 或超时，则 hosts 干扰确认；
- JDK 升级后必查 hosts：Java 17+ 对 TLS 1.3 和证书链验证更严格，旧 hosts 规则更容易暴露问题。
修复完成后，Java 工具将恢复对标准 HTTPS 服务的正常访问——无需重装 JDK，不触碰证书库，直击病灶，高效可靠。
