.NET 8不同Docker构建结果差异：SSL连接失败原因排查

我有一个简单的.NET 8应用，代码如下：

await new HttpClient().GetAsync("https://ws.pharmos.cz/wssupp/SupplierWS.asmx");
Console.WriteLine("success");

对应的Dockerfile内容为：

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS publish
WORKDIR /src
COPY . .
RUN dotnet publish "DockerWebClientTest.csproj" -c Release -o /app/publish /p:UseAppHost=false

FROM mcr.microsoft.com/dotnet/runtime:8.0 AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DockerWebClientTest.dll"]

运行该镜像时出现以下错误：

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.

但改用mcr.microsoft.com/dotnet/sdk:8.0-jammy作为构建镜像时，应用能正常运行。SslLabs检测显示目标服务器证书无异常，请问这两种构建方式的差异是什么？

两种构建方式的核心区别在于基础镜像依赖的Linux发行版及配套的SSL库版本不同：

• mcr.microsoft.com/dotnet/sdk:8.0 默认基于Debian 11（代号bullseye），系统预装的OpenSSL版本为1.1.1n；
• mcr.microsoft.com/dotnet/sdk:8.0-jammy 基于Ubuntu 22.04（代号jammy），系统预装的OpenSSL版本为3.0.2。

.NET 8在Linux环境下的HTTPS通信直接依赖系统级的OpenSSL库，而目标服务器https://ws.pharmos.cz的SSL/TLS配置（比如支持的协议版本、密码套件）与Debian 11上的旧版OpenSSL存在兼容性问题，导致SSL握手失败，最终抛出EOF异常。而Ubuntu 22.04搭载的新版OpenSSL能够适配目标服务器的配置，因此可以顺利建立连接。

另外需要注意，若要确保运行环境与构建环境一致，建议将最终运行阶段的mcr.microsoft.com/dotnet/runtime:8.0也替换为mcr.microsoft.com/dotnet/runtime:8.0-jammy，避免因运行环境的SSL库版本差异再次出现问题。

内容的提问来源于stack exchange，提问作者Jan Zahradník