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

Posted by Kyle Hankinson July 31, 2026

---

You update a driver, a NuGet package, or a client tool. You change nothing on the database server. And a connection that has worked for years suddenly fails with:

[Microsoft][ODBC Driver 18 for SQL Server]SSL Provider: The certificate
chain was issued by an authority that is not trusted.

The wording shifts with the platform. On macOS and Linux, where ODBC Driver 18 validates through OpenSSL, I reproduced the same failure against SQL Server 2022 as:

SSL Provider: [error:0A000086:SSL routines::certificate verify failed:
self-signed certificate]

and Go-based tools like modern sqlcmd report it as a TLS handshake failure with an x509 error naming a certificate called SSL_Self_Signed_Fallback. Different words, one problem.

What actually changed

Starting with ODBC Driver 18, OLE DB Driver 19, and Microsoft.Data.SqlClient 4.0 (which is why Entity Framework Core 7 upgrades trip this too), Microsoft flipped the encryption default. Older drivers assumed Encrypt=no unless told otherwise; the new ones assume Encrypt=yes. And once the client requests encryption, it must validate the certificate the server presents. Microsoft documents the change and its remedies in its certificate chain troubleshooting article.

Here is the part that catches people: a SQL Server that was never given a certificate still encrypts on request. It generates its own self-signed certificate at startup (that SSL_Self_Signed_Fallback name above) so encryption is always possible. But no client trusts that certificate's issuer, because the issuer is the server itself. Old driver: never checked. New driver: checks, and refuses.

So the error is not telling you encryption failed. It is telling you the client could not verify who it encrypted to. That distinction decides which fix is appropriate.

Fix 1: trust the server certificate (the dev-loop unblock)

Every Microsoft driver has a switch that says "encrypt, but skip issuer validation":

Client	Setting
ODBC connection string	TrustServerCertificate=yes;
ADO.NET / EF Core connection string	TrustServerCertificate=True;
JDBC connection string	trustServerCertificate=true;
sqlcmd	the -C flag

I verified the sqlcmd form directly: connecting to a fresh SQL Server 2022 container fails without -C and succeeds with it:

sqlcmd -S localhost,1433 -U sa -P 'YourStrongPassword' -C -Q "SELECT @@VERSION;"

Understand the tradeoff before you paste this into anything permanent. The connection is still encrypted, but you skipped the step that proves the server is the machine you meant to reach. Anything that can intercept your traffic can present its own certificate and read everything, including your SQL login credentials. For a container on localhost or a throwaway dev VM, that risk is theoretical and TrustServerCertificate is the pragmatic answer. For a production connection string crossing a network you do not fully control, it is the wrong answer, and it has a way of surviving in config files for years once added.

Fix 2: turn encryption back off

The other quick option is restoring the old behavior: Encrypt=Optional (or Encrypt=no) in ODBC 18 terms, Encrypt=False in ADO.NET terms. The connection then proceeds without certificate validation because the data channel is not encrypted at all.

You can see the difference from the server side. After connecting each way, I checked:

SELECT encrypt_option
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Connection	encrypt_option
Encrypt optional, no trust flag	FALSE
Encrypted with trust flag	TRUE

That FALSE means login packets are still protected during the handshake, but your queries and result sets travel in plain text. Between fixes 1 and 2, prefer fix 1: an encrypted channel to an unverified server still beats an unencrypted one. Fix 2 is mostly useful for legacy servers whose TLS stack is too old to negotiate with modern drivers at all.

Fix 3: the production fix, a certificate the client can verify

The reason the error exists is that Microsoft wanted encrypted-and-verified to be the default posture. Matching that posture means giving SQL Server a certificate that chains to an authority your clients already trust:

• A certificate from a public or corporate CA. Per Microsoft's encryption configuration documentation, the certificate must be issued for server authentication, and its subject or subject alternative name must match the hostname clients use to connect. It is installed via SQL Server Configuration Manager on Windows, followed by a service restart.
• If you run an internal CA, the alternative is distributing that CA's root certificate to client machines, so certificates it issues validate everywhere in your organization.

Server certificate installation is a server-admin task and the steps above summarize Microsoft's documentation rather than something you can do from a client tool. But it is the only fix on this list that removes the error without weakening anything.

If you see this against Azure SQL

Azure SQL Database presents a certificate chained to a public CA, so a default-configured client validates it fine. Hitting this error there usually means something is intercepting the connection, most often a corporate proxy or firewall doing TLS inspection, or a connection string pointed somewhere unexpected. Do not reach for TrustServerCertificate on Azure; find out what is actually terminating your TLS first.

Fixing it in a GUI client

Desktop clients surface the same driver options as checkboxes. In SQLPro for MSSQL the connection editor exposes the encryption mode and a server-certificate trust setting per connection, which maps exactly onto the table above: trust the certificate for a dev container, and leave validation on for anything production-facing. The same reasoning about tradeoffs applies no matter which client the checkbox lives in.

If you are setting up a Mac SQL Server workflow from scratch, our guide to connecting to SQL Server from a Mac covers the client options and where this error fits among the usual first-connection failures.

The short version

Situation	Do this
Local container / dev VM	TrustServerCertificate=yes (or -C)
Legacy server, can't do TLS	Encrypt=Optional, accept plaintext knowingly
Production	CA-issued certificate on the server, validation left on
Azure SQL	Neither; investigate what is intercepting TLS

The error reads like the server broke. It didn't. Your client got stricter, and the fastest fix, trusting blindly, is also the one worth removing again once a real certificate is in place.

---