当遇到 JDK 版本不支持 TLS 1.3 时，可以通过以下四种方案来解决。具体选择取决于您的项目约束（如是否允许升级 JDK 版本）：

方案一：升级 JDK 版本（首选推荐）
不同版本的 JDK 对 TLS 1.3 的原生支持程度不同，升级是最稳妥的方案：
JDK 8：原生不支持，必须升级到 8u261 或更高版本 才能获得对 TLS 1.3 的良好支持。
JDK 11：默认支持 TLS 1.3，但需确认具体环境配置无误。
JDK 17 及以上：原生支持 TLS 1.3，无需任何额外配置。

方案二：使用 JVM 启动参数显式启用（针对 JDK 8u261+）
如果您的 JDK 版本已经是 8u261 以上，但默认未启用 TLS 1.3，可以通过添加 JVM 启动参数来强制开启：
-Djdk.tls.client.protocols=TLSv1.3
注：如果需要兼容旧服务，也可以设置为 -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2"。

方案三：引入第三方安全提供程序（针对不升级 JDK 的情况）
如果项目受限无法升级 JDK 版本，可以通过引入第三方加密库来为旧版本 JDK 增加 TLS 1.3 支持：
Azul OpenJSSE：适用于 JDK 8。将 OpenJSSE 库添加到项目中，并在 JAVA_HOME/jre/lib/security/java.security 文件中将其配置为第一个安全提供程序：security.provider.1=org.openjsse.net.ssl.OpenJSSE。
BouncyCastle：适用于 JDK 1.6 / 1.7。下载对应的 FIPS 库文件放入 {JRE_HOME}/lib/ext 文件夹下，并在 java.security 文件中将 BouncyCastle 的 Provider 置于列表首位。

方案四：排查并修改安全配置文件
有时 JDK 版本本身支持 TLS 1.3，但由于安全策略配置禁用了该协议，也会导致连接失败。
检查禁用列表：找到 JDK 目录下的 java.security 文件（JDK 11+ 位于 JAVA_HOME/conf/security/，JDK 8 位于 $JAVA_HOME/jre/lib/security/）。
修改配置：检查 jdk.tls.disabledAlgorithms 属性，如果其中包含了 TLSv1.3，将其删除即可。

⚠️ 关键排查提醒：
在修改客户端配置前，请务必同时检查服务端（接口提供方）的配置。如果服务端不支持 TLS 1.3，即使客户端成功启用了该协议，双方也无法完成握手，依然会导致接口访问不通。

在Java中强制使用TLSv1.3协议，可以根据具体的应用场景选择以下三种主流方案：

JVM 全局启动参数（推荐）
如果你的应用（如Spring Boot项目）依赖JVM默认的HTTPS连接堆栈，通过启动参数进行全局配置是最简单有效的方式。这种方式不仅适用于普通应用，也适用于Gradle等构建工具的依赖解析。
命令行启动：在运行Java程序时添加参数 -Djdk.tls.client.protocols="TLSv1.3"。如果为了兼容旧服务，也可以设置为 "TLSv1.3,TLSv1.2"。
Gradle 构建环境：在 gradle.properties 文件中添加 systemProp.jdk.tls.client.protocols=TLSv1.3，即可强制Gradle在下载依赖时仅使用TLS 1.3。

代码级显式控制（精细管理）
当需要在代码中对特定的网络连接进行精细的协议控制时，可以通过Java的SSL API显式指定：
SSLContext 初始化：在获取SSL上下文时直接指定协议版本，例如 SSLContext.getInstance("TLSv1.3")。
SSLParameters 配置：创建 SSLParameters 对象并调用 setProtocols(new String[]{"TLSv1.3"})，然后将其应用到 SSLSocket、SSLEngine 或 SSLServerSocket 上。
HttpClient 配置：在使用 Apache HttpClient 5.x 等第三方库时，可以通过 SSLContextBuilder 设置 .setProtocol("TLSv1.3")，并在 SSLConnectionSocketFactory 中显式限定允许的协议版本。

JVM 系统属性屏蔽旧协议（安全加固）
为了从根本上防止协议降级攻击，可以通过设置系统属性彻底禁用旧版本的TLS协议。例如，在代码中设置 System.setProperty("jdk.tls.disabledAlgorithms", "SSL, TLSv1, TLSv1.1, TLSv1.2")，或者在启动参数中配置 -Djdk.tls.disabledAlgorithms="SSLv3, TLSv1, TLSv1.1, RC4, DES"，从而强制客户端仅能协商使用TLS 1.3。

⚠️ 关键注意事项
JDK版本要求：确保使用的是较新的JDK版本（如 Java 11.0.5+），因为早期版本的 Java 11 和 Java 12 在 TLS 1.3 的实现上存在已知Bug。
服务端兼容性：强制使用TLS 1.3前，务必确认目标服务器支持该协议。如果服务端已禁用TLS 1.2及以下版本，而客户端未配置TLS 1.3，将会导致握手失败（如抛出 protocol_version 异常）。
生产环境安全：生产环境中必须正确处理证书验证，严禁使用跳过验证的自定义信任管理器（TrustManager）来规避协议不匹配的问题。

在Java生态中，SSL证书的配置和验证逻辑与浏览器有显著差异。由于Java拥有独立于操作系统的信任库（cacerts），开发者在对接HTTPS接口或配置服务端时，常会遇到以下四大核心问题。结合行业实战经验，以下是常见问题及解决指南：

握手失败：PKIX path building failed
问题现象：Java客户端（如RestTemplate、HttpClient）访问HTTPS接口时，抛出 javax.net.ssl.SSLHandshakeException: PKIX path building failed: unable to find valid certification path to requested target。
问题原因：Java无法构建完整的信任链。这通常是因为服务端未提供完整的中间证书，或者客户端JDK版本过旧，其内置的信任库（cacerts）不包含最新的根证书。浏览器能正常访问是因为其具备自动下载缺失中间证书（AIA chasing）的功能，而Java默认不具备。
解决方案：
修复服务端：使用 openssl s_client -connect your.domain.com:443 -showcerts 检查证书链。若缺失中间证书，需在服务器端重新配置包含完整信任链的证书包（如 fullchain.pem）。
修复客户端：若服务端配置无误，需将目标站点的证书或企业根证书导入到实际运行程序的JDK信任库中。可使用命令：keytool -importcert -alias 域名 -file 域名.pem -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit。

密钥库与密码配置错误
问题现象：Tomcat等Java服务器启动失败，日志中报错 Keystore was tampered with, or password was incorrect 或 Cannot recover key。
问题原因：配置文件中指定的证书密码与真实密码不符，或者Tomcat的密钥库密码与密钥密码不一致。
解决方案：
确认 server.xml 中配置的证书密码与密码文件中的内容完全一致，注意不要包含多余的空格或换行符。
在Tomcat配置中，密钥库密码（keystorePass）和密钥密码必须相同。
确认配置的文件路径正确，且运行Tomcat的用户对证书文件拥有读取权限。

密码学库（BouncyCastle）依赖冲突
问题现象：在Spring Boot等项目中集成电子签章或加密SDK时，出现各种奇怪的SSL或加密异常。
问题原因：项目中引入了多个不同版本的密码学相关依赖（如 bcprov-jdk15on 与 bcprov-jdk18on），导致类加载冲突。
解决方案：
使用Maven依赖树（mvn dependency:tree -Dincludes=org.bouncycastle）分析冲突来源。
在 pom.xml 中使用 强制统一指定BouncyCastle的版本，并对旧版本的传递依赖进行 排除。

证书格式与协议兼容性
问题现象：证书无法被Java正确识别，或提示协议不匹配。
问题原因：Java对证书格式有特定要求，且对老旧的TLS协议支持不佳。
解决方案：
格式转换：Java专属格式为JKS或PKCS12（.p12/.pfx）。现代Java已原生支持PKCS12，推荐使用 openssl pkcs12 -export 将PEM证书和私钥打包为PKCS12格式，无需再转换为JKS。
协议配置：为保障安全性并避免兼容性问题，应在服务器配置中禁用老旧且不安全的协议（如SSLv3, TLSv1.0, TLSv1.1），仅启用 TLSv1.2 和 TLSv1.3。

⚠️ 安全红线提示：在开发调试时，严禁在生产代码中使用“信任所有证书”（TrustManager）的方式绕过SSL校验。这种做法虽然能让程序快速跑通，但会留下致命的中间人攻击安全隐患。正确的做法永远是精确配置信任链。

在开发和测试环境中，如果为每个服务都单独生成自签名证书，浏览器会频繁弹出“不安全”的警告，且每次都需要手动导入，管理成本极高。真正的终极解决方案是：建立自己的私有PKI（公钥基础设施）体系。

其核心原理是：创建一个私有根CA（Certificate Authority），用它来签发所有的服务器证书。客户端（浏览器或操作系统）只需要信任这个根CA一次，就能自动信任由它签发的所有子证书。

以下是构建私有CA并实现“一次配置，永久信任”的完整实战方案：

第一步：创建私有根CA（信任的源头）
根CA是整个信任体系的“宪法”，必须妥善保管。
创建工作目录并生成高强度的CA私钥（建议4096位）：
openssl genrsa -out ca.key 4096
生成自签名的根证书（可设置较长有效期，如10年）：
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/CN=My Internal Root CA"

第二步：为服务器签发证书
为了让证书支持多域名和IP，需要借助SAN（Subject Alternative Name）扩展字段。
生成服务器私钥：
openssl genrsa -out server.key 2048
创建SAN扩展配置文件（如 v3.ext），绑定具体的域名和IP：

  authorityKeyIdentifier=keyid,issuer

basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = nginx.internal
IP.1 = 192.168.10.100

生成证书签名请求（CSR）：
openssl req -new -key server.key -out server.csr -subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/CN=nginx.internal"
使用根CA签署服务器证书：
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256 -extfile v3.ext

第三步：客户端“一次配置，永久信任”
将根证书（ca.crt）安装到所有需要访问服务的客户端信任库中。不同平台的配置方式如下：
Windows：双击 ca.crt，选择“安装证书”，将其放入“受信任的根证书颁发机构”存储区。
macOS：双击证书打开“钥匙串访问”，将其添加到“系统”钥匙串，并设置信任方式为“始终信任”。
Linux：将证书复制到 /usr/local/share/ca-certificates/，然后执行 sudo update-ca-certificates 更新系统信任库。
Firefox浏览器：由于Firefox不使用系统证书库，需在“隐私与安全”设置中手动导入该CA证书。

第四步：部署到 Nginx
将生成的 server.crt 和 server.key 配置到 Nginx 中，重启服务即可。

💡 进阶替代方案：使用 mkcert 工具
如果你觉得 OpenSSL 命令过于繁琐，可以使用专为本地开发设计的工具 mkcert。它会自动在本地创建一个根CA并安装到系统的信任存储中。之后，你只需执行 mkcert example.com "*.example.com" 即可一键生成受信任的证书。若要在多台机器间同步信任，只需将 mkcert 生成的根证书（如 rootCA.pem）拷贝到其他机器上手动安装即可。

⚠️ 安全提示：自签名证书及其私有CA仅适用于内网、本地开发或测试环境。在生产环境中，请务必使用由受信任的全球公共CA（如 DigiCert、Let's Encrypt）签发的证书。

SSL证书的正确部署是保障网站数据安全、避免浏览器提示“不安全”的关键环节。尽管不同服务器（如Nginx、Apache、IIS）的具体配置指令有所差异，但核心的部署流程是通用的。以下是标准化的部署步骤：

一、 部署前准备与文件上传
获取证书文件：在证书机构（CA）审核通过并签发后，下载完整的证书文件包。通常包含域名证书（如 .crt 或 .pem 格式）、证书私钥（.key 格式）以及中间证书链（.ca-bundle 格式）。
上传至服务器：将上述文件上传至服务器的指定安全目录。推荐将证书存放于 /etc/ssl/certs/，私钥存放于 /etc/ssl/private/。
设置私钥权限：为防止私钥泄露，必须严格限制其访问权限，建议将私钥文件的权限设置为 600。

二、 修改服务器配置
以主流的 Nginx 服务器为例，需编辑站点配置文件，完成以下核心参数的绑定：
监听端口：将原有 listen 80 修改为 listen 443 ssl。
绑定域名：在 server_name 中填写证书绑定的实际域名。
指定证书路径：配置 ssl_certificate 指向域名证书（或合并后的完整证书链文件）的绝对路径，配置 ssl_certificate_key 指向私钥文件的绝对路径。
安全协议配置：为提升安全性，建议禁用老旧协议，仅启用 TLSv1.2 和 TLSv1.3，并配置高强度的加密套件（如 ECDHE-RSA-AES128-GCM-SHA256）。
强制HTTPS跳转：在监听80端口的 server 块中添加 return 301 https://hostrequest_uri; 规则，确保所有HTTP请求自动重定向至HTTPS，防止中间人攻击。

三、 验证配置并重载服务
语法检查：修改配置后，切勿直接重启。应先执行 nginx -t 命令测试配置文件语法，确保输出 syntax is ok 和 test is successful。
重载服务：测试通过后，执行 nginx -s reload 或 systemctl reload nginx 使配置生效，此操作不会中断现有连接。

四、 部署后验证与排查
浏览器验证：通过 https:// 访问网站，检查浏览器地址栏是否显示安全锁图标（注：Chrome 117及以上版本需点击图标查看安全状态）。
在线工具检测：可使用 SSL Labs 等在线工具检测证书链的完整性及整体安全评分。
常见问题排查：
提示“连接不安全”：检查证书是否过期、绑定的域名是否匹配，或是否遗漏了中间证书链。
无法访问HTTPS：检查服务器防火墙及云安全组是否已放行 443 端口。
混合内容警告：确保网页内引用的所有资源（图片、JS、CSS等）均使用了 HTTPS 协议。