为什么SQLclient仍然允许用撤销证书encryption连接？

我们正在实施SQL 2014encryption连接在不久的将来。我想做我的尽职调查，并确authentication书validation过程。我也想使用trustservercertificate = false选项。我想要所有连接来实际使用证书validation。如果服务器证书被吊销，我想连接失败。所以我已经在SQL服务器上实现了一个证书并将其吊销。如果我使用certutil -verify，我确认撤销。但是，即使trustservercertificate = false，我的sql连接仍然成功。

这是我的完整的SQL连接参数：

$cn = New-Object System.Data.SqlClient.SqlConnection $cn.ConnectionString = "data source=fqdnservername;user=blah;password=blah;encrypt=true;trustservercertificate=false" $cn.Open() $cmd = $cn.CreateCommand() $cmd.CommandText = "select sysdatetimeoffset()" $dto = $cmd.ExecuteScalar() Write-Output "Current SQL server time: $dto" $cmd.Dispose() $cn.Close()

为什么SQLclient仍然允许一个带有撤销证书的encryption连接？

由于许多TLS库只对服务器证书进行最小限度的检查，无论是出于性能原因，还是因为开发人员认为不需要执行更好的检查。

在这种特殊情况下，.Net文档提示要进行什么检查：

SqlConnection.ConnectionString属性 – > Encrypt
如果为true ，则SQL Server将在客户端和服务器之间发送的所有数据使用SSLencryption（ 如果服务器已安装证书） 。公认的价值观是true ， false ， yes ， no 。有关更多信息，请参阅连接string语法。
从.NET Framework 4.5开始，当TrustServerCertificate为false且Encrypt为true ，SQL Server SSL证书中的服务器名称（或IP地址）必须与连接string中指定的服务器名称（或IP地址）完全匹配。否则，连接尝试将失败。

换句话说，使用“encrypt = true; trustservercertificate = false”组合的唯一一项安全检查就是查看证书主机名是否与您尝试连接的服务器的主机名相匹配。

如果使用过期的TLS服务器证书，也不会感到惊讶。

1 _{不完全是唯一的检查， trustservercertificate=false将不接受自签名证书，所以证书仍然必须由已知/可信CA}