SSMS Certificate Chain Not Trusted Error (Trust Server Certificate Fix)

If you have upgraded SSMS or a driver recently and a connection that worked yesterday has stopped working today, this is almost certainly what you are looking at. Nothing changed on the server. The client got stricter, and it is now refusing a certificate it used to accept without comment.

The full error, as it appears:

This one became far more common with SSMS 20 and the Microsoft ODBC Driver 18, because both changed their default: connections now encrypt by default and validate the certificate. Nothing about your server changed. The client got stricter.

That matters, because the fastest fix and the correct fix are different, and most search results only give you the fast one.

What Is Actually Happening

SQL Server encrypts the login handshake whether you asked it to or not. To do that it needs a certificate. If you never installed one, SQL Server generates a self-signed certificate at startup and uses that.

A self-signed certificate is not issued by any authority your machine trusts. Older clients did not check. New ones do. Hence the error.

So there are exactly two honest options: tell the client not to check, or give the server a certificate worth checking.

The Fast Fix (and when it is acceptable)

In SSMS: on the connection dialog, Options → Connection Properties → tick “Trust server certificate”.

In a connection string:

Server=YOURSERVER;Database=YourDb;Encrypt=True;TrustServerCertificate=True;

With sqlcmd (driver 18 and later):

sqlcmd -S YOURSERVER -d YourDb -C

-C is the same as TrustServerCertificate=True.

What this actually does: the connection is still encrypted, but the client no longer verifies that the server is who it claims to be. You are protected against passive eavesdropping and not against an active man-in-the-middle.

That is fine on a laptop talking to a local dev instance. It is not fine across a network you do not control, and it is not fine as a permanent answer on a production server just because it made the error go away. If you find yourself setting this in application connection strings across an estate, you have quietly turned off certificate validation everywhere.

The Proper Fix

Install a certificate that the connecting machines already trust, from your internal CA in a domain environment, or a public CA for internet-facing instances.

The certificate must satisfy SQL Server’s requirements or the service will silently fall back to its self-signed one:

• The subject (or a SAN entry) must match the name clients actually connect with. If people connect to sqlprod01.corp.local, a certificate for sqlprod01 will not do.
• It needs the Server Authentication EKU (1.3.6.1.5.5.7.3.1).
• The private key must be present, and the SQL Server service account needs read permission on it.
• It must be in the Local Computer personal store, not the user store.

Then set it in SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for [instance] → Properties → Certificate tab, and restart the service.

Check what the instance is actually using:

-- What encryption are current connections really getting?
SELECT c.session_id,
       c.encrypt_option,
       c.protocol_type,
       c.client_net_address,
       s.program_name,
       s.login_name
FROM   sys.dm_exec_connections c
JOIN   sys.dm_exec_sessions s ON s.session_id = c.session_id
WHERE  c.session_id > 50
ORDER  BY c.encrypt_option DESC, s.login_name;

And confirm whether the certificate in use is the self-signed one:

EXEC xp_readerrorlog 0, 1, N'certificate', NULL, NULL, NULL, N'DESC';

A line reading “The server could not load the certificate… using a self-generated certificate” tells you the certificate you installed was rejected, and the reason is nearly always the private key permission or a subject name mismatch.

If It Is Not the Certificate

The same SSL Provider error text appears for problems that have nothing to do with trust:

• TLS version mismatch. Older SQL Server builds do not support TLS 1.2 without a patch, and newer Windows builds have disabled TLS 1.0 and 1.1. Both sides need one protocol in common.
• A cipher suite mismatch after a security hardening pass, which is the same shape of problem.
• Force Encryption is on at the server and the client cannot meet it.

The error log is again the place that tells the truth. If the handshake failed before login, you will see it there and not in any client message.

Stopping It Recurring

• Decide the policy once, per environment. TrustServerCertificate=True for local development, a real certificate everywhere else. Mixed practice is how it ends up permanently in production.
• Diary the expiry. A certificate that expires takes every application down at once, and the error looks identical to this one.
• When you patch or upgrade tooling, expect this. Driver 18 and SSMS 20 are the reason most people meet this error, and the next default change will do the same thing again.

Common Questions

Related Scripts

• Forcing Encrypted Connections Using Certificates, the full setup
• Check Connection Encryption and Protocol, what your connections are really negotiating
• Install and Update SSMS, where the stricter defaults came from
• SQL Server Error Severities Explained