内容摘要：连SQL Server报SSL安全错误，十有八九不是数据库本身挂了。我上周帮一个客户排查，他们运维半夜打电话说生产库连不上，错误日志里全是"SSL Provider: 证书链是由不受信任的颁发机构颁发

连SQL Server报SSL安全错误，可用十有八九不是存s错误数据库本身挂了。我上周帮一个客户排查，安全他们运维半夜打电话说生产库连不上，可用错误日志里全是存s错误"SSL Provider: 证书链是由不受信任的颁发机构颁发的"。第一反应是安全数据库崩了，结果登服务器一看，可用SQL Server服务跑得好好的存s错误，端口1433也在监听。安全问题出在客户端和服务器之间的可用TLS握手阶段。

SQL Server从2016版本开始默认强制加密连接，存s错误这个变化很多人没注意到。安全以前SQL Server 2008 R2那会儿，可用客户端连上去基本不加密，存s错误除非你主动配置。安全现在不一样了，服务器端会主动要求加密。如果客户端驱动版本太老，或者证书配置有问题，握手直接失败。表现就是连不上，但服务状态正常。

证书过期是最常见的坑

SQL Server安装时会自动生成一个自签名证书，有效期通常一年。这个证书到期后不会自动续，也不会弹窗提醒。某天早上你打开SSMS，突然发现连不上了，错误提示里带着"证书已过期"或者"远程证书无效"。我见过最离谱的案例是证书过期了三年没人发现，因为那个实例只跑本地定时任务，用的还是旧版驱动，压根没走加密通道。直到有个新项目接入，用了新版JDBC驱动，才把这个雷踩出来。

检查方法很简单。在服务器上打开证书管理器，看"个人"存储区里那个以计算机名命名的证书，过期时间一目了然。或者直接跑一句SQL：SELECT * FROM sys.dm_os_performance_counters WHERE counter_name LIKE '%SSL%'，不过这个DMV信息有限，不如直接看证书存储来得快。

客户端驱动版本不匹配也会触发这个错误

有个做ERP的哥们儿，服务器端SQL Server 2019配了正规CA签发的证书，按理说没问题。但部分客户端用的老版ODBC驱动，只支持TLS 1.0，而服务器端已经禁用了TLS 1.0。握手阶段直接谈崩，报的错就是"SSL安全错误"。他折腾了一整天，重装SQL Server、重建证书、改注册表，最后发现是客户端驱动太老。升级到ODBC Driver 17 for SQL Server，问题消失。

这种情况在混合环境里特别常见。开发机是Windows 10，自带较新的驱动，测试通过。生产环境有些老服务器跑Windows Server 2012 R2，系统自带的驱动还是SQL Server Native Client 11.0，默认走TLS 1.0。两边配置不一致，连不上是必然的。

强制加密配置引发的连锁反应

有人为了安全，在SQL Server配置管理器里把"强制加密"打开了。这个选项一开，所有连接必须加密，包括本地连接。如果证书配置有问题，连本机SSMS都连不上。更麻烦的是，某些旧版应用程序用的驱动根本不支持加密连接，直接报"SSL Provider: 无法建立信任关系"。

我自己的做法是，先确认证书是否有效，再检查客户端驱动版本，最后看服务器端加密配置。三步走完，基本能定位问题。别一上来就重装数据库，那是最笨的办法。有个客户听了某云厂商的建议，把SQL Server卸载重装，结果证书问题依旧，白白停机四小时。

说到底，SQL Server的SSL错误本质上是信任链问题。要么证书不被信任，要么加密协议版本不匹配，要么驱动太老不支持。排查方向对了，解决起来很快。方向错了，折腾几天都搞不定。