TLS 1.3 证书在 Windows Server 2022 以下版本无法建立 SSL 连接的问题与解决方案

背景介绍

在使用 GoDaddy 注册局提供的 TLS 1.3 版本证书和密钥时，我们的 EPP 程序在连接注册局服务器时遇到了连接问题。由于对方服务器采用 TLS 1.3 协议，而运行环境为 Windows Server 2019，该系统原生不支持 TLS 1.3 及其相关加密套件，导致程序无法正常建立连接。

问题排查过程

初始连接失败

程序配置证书及服务器端口后，连接时报错：

Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'

OpenSSL 验证

使用 OpenSSL 连接服务器进行验证：

openssl s_client -connect server:port -cert cert.crt -key key.pem

验证结果显示证书和服务器端口配置正常，能够成功连接并获取返回信息。

协议分析

通过 OpenSSL 连接输出的信息分析，发现服务器协商使用的是 TLSv1.3 协议，加密套件为 TLS_AES_256_GCM_SHA384。这证实了连接失败的根本原因是 Windows Server 2019 不支持 TLS 1.3 协议。

解决方案

系统限制确认

Windows Server 2022 才开始原生支持 TLS 1.3 协议，Windows Server 2019 及更早版本均不支持。.NET 运行时的加密能力依赖于操作系统提供的加密套件，因此无法绕过此系统限制。

BouncyCastle 解决方案

采用 BouncyCastle 库实现自定义 TLS 1.3 客户端，绕过 Windows 自带的加密套件限制。

自定义 TLS 1.3 客户端实现

public class Tlsv13Client : DefaultTlsClient
{
    // 实现细节包括：
    // - SNI 服务器名称指示
    // - 支持的协议版本设置为 TLSv1.3
    // - 支持的加密套件配置
    // - 客户端证书和私钥处理
    // - 认证流程管理
}

自定义 TLS 1.3 认证实现

internal class Tlsv13Authentication : TlsAuthentication
{
    // 实现客户端凭据获取
    // 处理服务器证书通知
    // 使用 BcTlsCrypto 进行加密操作
}

证书格式注意事项

最初使用 PFX 格式证书文件时出现读取问题，可能导致 CA 证书和中间证书丢失。建议将证书和密钥分别导出为独立的 PEM 文件，并将 CA 证书与中间证书保存在一起，以确保连接正常。

总结

项目	说明
根本原因	Windows Server 2019 及以下版本不支持 TLS 1.3 协议及其加密套件
解决方案	使用 BouncyCastle 库实现自定义 TLS 1.3 客户端
核心技术	继承 DefaultTlsClient，重写协议版本和加密套件配置
最佳实践	使用 PEM 格式证书文件，避免 PFX 格式可能导致的证书链问题

通过这种方案，成功在 Windows Server 2019 环境下实现了与 TLS 1.3 服务器的安全连接，为类似环境下的 TLS 1.3 兼容性问题提供了有效的解决路径。