.NET 6容器连接SQL Server：未加密连接为何需设置SECLEVEL=1？

核心原因 #

哪怕你设置了Encrypt=False，SQL Server与Microsoft.Data.SqlClient在预登录握手阶段依然会进行TLS协议的协商交互，这个过程会触发OpenSSL的加密套件校验。而你使用的mcr.microsoft.com/dotnet/aspnet:6.0-focal基于Ubuntu 20.04，该系统默认OpenSSL安全级别（SECLEVEL=2）对加密套件的要求高于SQL Server支持的标准，导致协商失败，抛出握手错误。

详细拆解 #

• Ubuntu 20.04默认的OpenSSL SECLEVEL=2，会强制要求：
  • 仅支持TLS 1.2+的强加密套件
  • 禁用SHA-1签名证书、密钥长度不足等被判定为不安全的加密算法
• Encrypt=False控制的是最终连接是否加密传输业务数据，而非完全跳过预登录阶段的TLS协商。这个协商步骤是SQL Server客户端与服务器的固有流程，用来确认双方是否支持加密、可用的加密方式，哪怕最终不启用加密，这个交互也会发生。
• 当你将SECLEVEL调整为1时，OpenSSL放宽了加密套件的要求，允许SQL Server支持的相对老旧的套件通过校验，预登录握手顺利完成后，连接就会按照Encrypt=False的配置以明文传输数据。

补充说明 #

• 你使用的Microsoft.Data.SqlClient 2.1.4及EF Core 6确实默认Encrypt=False，但这个参数不影响预登录阶段的TLS协商逻辑。
• TrustServerCertificate=True仅作用于证书信任校验，不会改变TLS套件的协商规则。

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