.NET Core 3.1 WebApi SSL连接失败但同地址curl可正常访问如何解决

1. 开启.NET Core 3.1 SSL详细日志 #

在RedHat服务器上启动你的API服务前，先执行以下命令设置环境变量，即可输出SSL握手全流程的日志信息：

export COMPlus_RetailDebug=1
export COMPlus_DebugWriteToStdErr=1
export DOTNET_SYSTEM_NET_HTTP_LOGGING_ENABLED=1
export DOTNET_SYSTEM_NET_SECURITY_LOGGING_ENABLED=1

启动服务后发起请求，从服务输出日志中可以看到具体的证书校验失败原因，例如根证书不信任、证书链不完整、吊销检查失败、域名不匹配等。

2. 高频问题解决方案 #

你遇到的curl/openssl正常但.NET Core校验失败的情况，绝大多数是证书吊销检查导致的：
curl、openssl默认不会主动执行证书吊销校验，而.NET Core在Linux环境下默认开启证书吊销检查，如果你的服务器无法访问对方证书中配置的CDP（证书吊销列表）地址，就会直接判定证书无效。

验证方法 #

在你的HttpClient初始化代码中临时添加校验回调，打印具体错误信息：

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = (sender, cert, chain, error) =>
{
    Console.WriteLine($"校验错误类型：{error}");
    foreach (var status in chain.ChainStatus)
    {
        Console.WriteLine($"证书链错误：{status.Status} - {status.StatusInformation}");
    }
    return error == SslPolicyErrors.None;
};
var httpClient = new HttpClient(handler);

如果日志中出现RevocationStatusUnknown、OfflineRevocation类错误，即可确认是吊销检查问题。

修复方案 #

• 临时验证：可先关闭吊销检查确认问题是否解决，配置为handler.CheckCertificateRevocationList = false;
• 生产修复：确保你的RedHat服务器网络可以正常访问对方证书标注的CDP地址即可

其他可能的问题及修复 #

• 系统CA存储未更新：执行命令sudo update-ca-trust extract刷新系统根证书库后重启服务
• 硬编码TLS版本过低：检查代码中是否有固定TLS版本的配置，例如ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11，需修改为支持TLS 1.2及以上版本，推荐直接使用系统默认配置
• 证书链不完整：如果对方服务返回的证书缺失中间证书，可手动将对方的中间证书导入到系统CA存储中

内容的提问来源于stack exchange，提问作者Niall