替换Microsoft.Data.SqlClient后无法连接加密SQL Server实例的问题

1. localhost连接时证书验证失败的核心差异 #

System.Data.SqlClient和Microsoft.Data.SqlClient在证书名称验证逻辑上有本质区别：

• 旧库（System.Data.SqlClient）处理localhost连接时，针对强制加密场景，对证书主体名称/SAN的匹配要求宽松——只要证书本身有效（未过期、信任链完整），哪怕是*.mydomain.example这种通配符证书，也能通过验证。
• 新库（Microsoft.Data.SqlClient）默认启用了严格的RFC标准验证：当连接字符串指定Server=localhost时，客户端会要求证书的主体名称或SAN必须包含localhost，你的通配符证书不满足这个条件，因此触发TLS连接错误。

2. 改用server.mydomain.example后的连接失败原因 #

命名管道错误 #

当连接字符串只写Server=server.mydomain.example时，Microsoft.Data.SqlClient会按共享内存 → 命名管道 → TCP/IP的默认顺序尝试连接协议。你已经禁用了命名管道，所以尝试到这一步直接报错。

TCP连接被拒绝 #

强制用TCP:server.mydomain.example仍失败，大概率是这几个原因：

• SQL Server没在server.mydomain.example对应的127.0.0.1 IP上启用TCP监听：打开SQL Server配置管理器，检查SQL Server网络配置 → 目标实例的协议 → TCP/IP，确保已启用，且IP地址列表里的127.0.0.1状态为“已启用”。
• 没指定TCP端口：如果SQL Server没使用默认的1433端口，连接字符串必须显式加端口，比如Server=TCP:server.mydomain.example,1433。
• 本地防火墙拦截：哪怕是本地连接，防火墙也可能挡住对应端口的TCP请求，得确保防火墙规则允许SQL Server的端口通信。
• SQL Server未绑定到该主机名：检查SQL Server的启动参数或配置，确认它能识别server.mydomain.example作为有效主机名。

3. 旧库能正常工作的原因 #

System.Data.SqlClient的协议优先级和证书验证逻辑更宽松：

• 协议尝试上，会优先用共享内存协议（针对localhost连接），而共享内存的加密验证对证书名称匹配要求低；
• 证书验证环节没严格遵循RFC标准，允许通配符证书匹配非域名格式的localhost。

可行的解决办法 #

• 调整连接字符串与SQL Server配置：确保SQL Server启用TCP/IP协议，连接字符串显式指定端口（比如Server=TCP:server.mydomain.example,1433），同时确认防火墙放行该端口。
• 修改证书配置：给SQL Server的证书添加localhost作为SAN（主题备用名称），这样不管用localhost还是域名连接，都能通过证书验证。
• 临时放宽验证（生产环境不推荐）：如果是测试需求，可以在连接字符串里加TrustServerCertificate=True，跳过证书名称验证，但会降低连接安全性。

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