当企业策略更新导致Eclipse无法访问HTTPS仓库（如Marketplace、P2更新源或Maven中央仓库）并报PKIX证书路径验证失败时，只需在eclipse.ini中配置-Djavax.net.ssl.trustStoreType=Windows-ROOT，即可让Eclipse直接复用Windows系统级受信任根证书，无需手动导入证书或修改JVM默认信任库。
当企业策略更新导致eclipse无法访问https仓库（如marketplace、p2更新源或maven中央仓库）并报pkix证书路径验证失败时，只需在eclipse.ini中配置`-djavax.net.ssl.truststoretype=windows-root`，即可让eclipse直接复用windows系统级受信任根证书，无需手动导入证书或修改jvm默认信任库。
在企业环境中，IT部门常通过组策略强制部署私有CA证书到Windows系统信任根存储（即“Windows-ROOT”证书库），但默认情况下，Eclipse（基于Java运行）仅信任其内置的cacerts文件（位于JRE的lib/security/目录下），而不会自动加载Windows系统证书库。一旦公司启用中间人代理（如Zscaler、Blue Coat）或内部SSL解密网关，所有HTTPS流量会被重签发为公司CA签名的证书——这些证书虽已安装至Windows“受信任的根证书颁发机构”，却未同步到Java信任库，从而触发经典的PKIX path building failed错误：
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
✅ 正确解决方案：启用Java对Windows系统证书库的原生支持
自Java 9起，SunMSCAPI安全提供者支持Windows-ROOT和Windows-MY两种信任库类型。只需在Eclipse启动配置中显式声明信任库类型，即可绕过Java默认cacerts的局限性。
✅ 操作步骤（适用于Windows + Eclipse 2020-03 及后续版本）
关闭Eclipse；
打开Eclipse安装目录下的 eclipse.ini 文件；
-
在 -vmargs 行之后、其他JVM参数之前，添加以下行：
-Djavax.net.ssl.trustStoreType=Windows-ROOT
⚠️ 注意：必须放在 -vmargs 下方，且不要加空行或注释；若已有类似-Djavax.net.ssl.trustStore=参数，请删除或注释掉，避免冲突。
保存文件，重启Eclipse。
? 验证是否生效
- 尝试打开 Help → Eclipse Marketplace 或 Help → Install New Software；
- 访问任意HTTPS P2源（如 https://download.eclipse.org/releases/2023-03）；
- 若不再报SSL握手异常，且能正常列出插件/更新项，即表示配置成功。
? 补充说明与注意事项
- 此方案仅适用于Windows平台（依赖SunMSCAPI提供者），Linux/macOS不支持Windows-ROOT；
- 不影响原有Java cacerts，而是扩展信任范围：Java会同时校验系统根证书+JVM内置证书；
- 无需重启操作系统、禁用防火墙、导出/导入证书，也无需修改Maven或Gradle配置；
- 若仍失败，请确认：
- Eclipse使用的是系统已安装JDK/JRE（而非自带JRE），且版本 ≥ 9；
- 企业证书确实已正确安装至Windows“受信任的根证书颁发机构”（可通过certmgr.msc查看）；
- eclipse.ini 中无拼写错误（如trustStoreType大小写、等号前后空格）。
该方法简洁、安全、可维护性强，是企业环境下解决Eclipse SSL信任问题的推荐实践。
