Checking SQL Server connection encryption after SSMS 21

If SQL Server connections suddenly behave differently after updating SSMS (SQL Server Management Studio), check the connection encryption settings before changing the server.

Newer SSMS versions use newer Microsoft SQL client libraries, and those libraries are more strict about encrypted connections than many older tools were. The practical symptom is usually a certificate-related connection error, usually along these lines:

The certificate chain was issued by an authority that is not trusted.

Or, it could be a pre-login handshake error:

A connection was successfully established with the server,
but then an error occurred during the pre-login handshake.

This often happens when connecting to an on-premises SQL Server that uses a self-signed certificate or a certificate that the client machine does not trust.

For application connection strings, make the encryption setting explicit.

Server=sqlserver01;
Database=MyDatabase;
Integrated Security=true;
Encrypt=True;
TrustServerCertificate=False;

This is the preferred direction when the SQL Server certificate is trusted by the client. For local development or lab environments however, you may temporarily trust the server certificate:

Server=localhost;
Database=MyDatabase;
Integrated Security=true;
Encrypt=True;
TrustServerCertificate=True;

Tip: TrustServerCertificate=True is convenient for development, but avoid using it as the default fix for production systems. The better production fix is to install a certificate that the client trusts.

You can also inspect your current connection string from C# using SqlConnectionStringBuilder:

using Microsoft.Data.SqlClient;
...
SqlConnectionStringBuilder builder = new(connectionString);
Console.WriteLine($"Encrypt: {builder.Encrypt}");
Console.WriteLine($"TrustServerCertificate: {builder.TrustServerCertificate}");

This is useful when the connection string comes from configuration, environment variables, or deployment secrets. For command-line testing, try a direct SQLCMD connection with encryption options:

sqlcmd -S sqlserver01 -d MyDatabase -E -N true -C false

Use -C true only when you intentionally want to trust the server certificate.

Handy: check both SSMS and application behavior. SSMS connection settings do not automatically change your ASP.NET or Windows service connection strings.

Good places to review:

• ASP.NET connection strings
• Windows service configuration files
• Azure DevOps pipeline variables
• PowerShell deployment scripts
• SSMS registered servers
• scheduled jobs and maintenance tools.

If the application uses Microsoft.Data.SqlClient, remember that encryption is no longer something to leave implicit. State the intended behavior clearly in the connection string.

For modern SQL Server clients, the safer default is encrypted traffic with a trusted certificate.

Happy hacking!