为什么 SQLclient 仍然允许证书被吊销的加密连接?

为什么 SQLclient 仍然允许证书被吊销的加密连接?

我们将在不久的将来实施 SQL 2014 加密连接。我想尽职尽责并确认证书验证过程。我还想使用 trustservercertificate=false 选项。我希望所有连接都实际使用证书验证。如果服务器证书被吊销,我希望连接失败。所以我在 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()

答案1

为什么 SQLclient 仍然允许与已撤销的证书建立加密连接?

因为许多 TLS 库仅对服务器证书进行最少的检查,要么是出于性能原因,要么是因为开发人员认为没有必要实施更好的检查。

在这个特殊情况下.Net 文档 提示执行了哪些检查:

SqlConnection.ConnectionString 属性 -->Encrypt
trueSQL Server 使用 SSL 加密客户端和服务器之间发送的所有数据时如果服务器已安装证书。可识别的值为truefalseyesno。有关详细信息,请参阅连接字符串语法。
从 .NET Framework 4.5 开始,当TrustServerCertificatefalseEncrypttrue,SQL Server SSL 证书中的服务器名称(或 IP 地址)必须与连接字符串中指定的服务器名称(或 IP 地址)完全匹配。否则,连接尝试将失败。

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

如果使用过期的 TLS 服务器证书也能成功运行,我不会感到惊讶。


1 嗯,不完全是仅有的查看,trustservercertificate=false不接受自签名证书,因此证书仍必须由已知/受信任的 CA 签名

相关内容