We are implementing SQL 2014 encrypted connections in the near future. I want to do my due diligence and confirm the cert validation process. I also want to use the trustservercertificate=false option. I want all connections to actually use cert validation. If a server certificate gets revoked, I want the connection to fail. So I have implemented a certificate on the SQL server and revoked it. if I use certutil -verify, I confirm the revocation. However, even with trustservercertificate=false, my sql connection still succeeds.
This is my full SQL connection parameters:
$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()
Because many TLS libraries only do minimal checking of server certificates, either for performance reasons or because developers see no need to implement better checks.
In this particular case the .Net documentation hints at what checks are performed:
In other words the only1 security check that's being done with the combination of "encrypt=true;trustservercertificate=false" is to see if the certificate hostname matches the hostname of the server you're trying to connect to.
I wouldn't be surprised if using an expired TLS server certificate would also work without fail.
1 Well not quite the only check,
trustservercertificate=false
won't accept self-signed certificates so the certificate must still be signed by a known/trusted CA