.NET 8运行时因底层OS镜像差异出现异常，求助排查

问题现象 #

• 使用标准.NET 8运行时镜像访问https://ws.pharmos.cz/wssupp/SupplierWS.asmx时，抛出Received an unexpected EOF or 0 bytes from the transport stream错误
• 切换至基于Ubuntu 22.04 Jammy的.NET 8运行时镜像，请求可正常返回401 Unauthorized
• .NET 9+暂无对应Jammy版本的官方运行时镜像，导致该问题无法通过镜像切换规避

可复现Dockerfile #

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

RUN echo 'await new System.Net.Http.HttpClient().GetStringAsync("https://ws.pharmos.cz/wssupp/SupplierWS.asmx");' > Program.cs
RUN echo '<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>net8.0</TargetFramework></PropertyGroup></Project>' > test.csproj

RUN dotnet build -o /app

# 抛出EOF错误的镜像
#FROM mcr.microsoft.com/dotnet/runtime:8.0

# 正常返回401的镜像
FROM  mcr.microsoft.com/dotnet/runtime:8.0-jammy

WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "test.dll"]

已排查结论 #

两个镜像中执行curl -vvvv https://ws.pharmos.cz/wssupp/SupplierWS.asmx均成功建立TLS 1.2连接，证书验证通过，排除基础网络、服务器证书及系统级TLS配置问题，问题根源在.NET运行时与底层OS依赖的交互层面。

排查方向建议 #

1. 对比SSL库版本：分别在两个镜像中执行openssl version，确认OpenSSL版本差异。部分旧版本OpenSSL与目标服务器的TLS握手逻辑存在兼容问题，Jammy镜像使用的较新版本库可能修复了该问题
2. 显式配置TLS参数：在代码中强制指定TLS 1.2及服务器支持的Cipher Suites，避免.NET运行时使用不兼容的默认配置：

using System.Net;
using System.Net.Http;
using System.Security.Authentication;

var handler = new HttpClientHandler
{
    SslProtocols = SslProtocols.Tls12,
    // 可通过curl输出的SSL握手信息获取服务器支持的Cipher Suites，按需添加
    CipherSuitesPolicy = new CipherSuitesPolicy(new List<TlsCipherSuite>
    {
        TlsCipherSuite.Tls_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
        TlsCipherSuite.Tls_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    })
};

using var client = new HttpClient(handler);
await client.GetStringAsync("https://ws.pharmos.cz/wssupp/SupplierWS.asmx");

3. 启用TLS跟踪日志：通过环境变量COMPlus_TraceFile=tls.log和COMPlus_TraceLevel=4启用.NET的TLS详细日志，对比两个镜像中握手流程的差异，定位具体失败环节
4. 自定义.NET 9镜像：基于.NET 9官方镜像，手动安装Jammy版本的libssl3、libcrypto3等依赖库，验证是否能解决兼容性问题

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