Arch虚拟机中.NET 7连接MS SQL <=2016（TLS1.1）失败求助

1. 验证环境变量是否真正生效 #

• 直接在终端执行 echo $CLR_OPENSSL_VERSION_OVERRIDE，确认输出为1.1，不要仅依赖.env文件（部分dotnet命令如scaffold可能不会自动加载.env）
• 测试时直接前置环境变量执行命令：CLR_OPENSSL_VERSION_OVERRIDE=1.1 dotnet ef dbcontext scaffold ...，观察是否正常运行
• 检查系统级环境变量冲突：执行env | grep SSL，查看是否存在OPENSSL_CONF等其他可能干扰的变量

2. 确认OpenSSL 1.1的可用性 #

• Arch默认使用OpenSSL 3.x，先检查是否安装openssl-1.1包：pacman -Q openssl-1.1，未安装则执行sudo pacman -S openssl-1.1
• 测试OpenSSL 1.1与数据库的TLS1.1握手：openssl s_client -connect <数据库IP>:1433 -tls1_1，对比正常设备的输出结果
• 检查dotnet链接的SSL库版本：ldd $(which dotnet) | grep ssl，若仍指向3.x，可尝试设置LD_LIBRARY_PATH=/usr/lib/openssl-1.1:$LD_LIBRARY_PATH后再运行dotnet命令

3. 调整SQL Server连接字符串参数 #

• 显式添加Encrypt=true;TrustServerCertificate=true，避免加密协商阶段的自动冲突
• 尝试加入TlsVersion=TLS1.1参数（部分驱动版本支持该配置）

4. 检查dotnet运行时/SDK差异 #

• 对比两台设备的dotnet版本：dotnet --version，确保主版本和小版本完全一致
• 重装dotnet运行时修复可能的损坏：sudo pacman -S dotnet-runtime-7.0
• 确认SDK版本一致：dotnet --list-sdks，scaffold命令依赖SDK，版本偏差可能引发问题

5. 抓取详细SSL握手日志 #

• 设置环境变量SSLKEYLOGFILE=/tmp/ssl.log后运行dotnet命令，生成的日志可通过Wireshark分析握手失败的具体阶段
• 启用dotnet调试日志：DOTNET_LOG_LEVEL=debug dotnet run，查看SSL连接相关的详细输出，定位错误节点

6. 排查虚拟机网络/防火墙规则 #

• 虽然Azure Data Studio能连接，但dotnet可能使用不同网络栈，检查虚拟机的iptables/nftables规则，确认无针对dotnet进程的限制
• 测试端口连通性：ncat --ssl --tls1.1 <数据库IP> 1433，验证TLS1.1协议下的端口通信是否正常

内容的提问来源于stack exchange，提问作者Gaël James