Fix ASP.NET Core SQL Server 'Certificate Not Trusted' Error

Your ASP.NET Core app connected to SQL Server fine for months. Then you upgraded a NuGet package or moved to .NET 8, and now every connection fails before it even logs in: "A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The certificate chain was not issued by a trusted authority.)". Your code didn't change. What changed is a default deep inside the SQL Server driver — and the fix is one connection-string property, once you understand the trade-off.

What actually changed

Microsoft's modern SQL Server driver, Microsoft.Data.SqlClient, flipped its Encrypt default from false to true in version 4.0 (early 2022). EF Core 7+ and the current ASP.NET Core data templates all pull in a 4.x+ driver, so the moment you upgrade, every connection tries to negotiate TLS and then validate the server's certificate against a trusted certificate authority.

SQL Server, by default, presents a self-signed certificate. A self-signed cert isn't issued by a trusted CA, so the client rejects it during the pre-login handshake — hence "the certificate chain was not issued by a trusted authority." The connection never reaches the login step.

The connection-string options

Two properties govern this behaviour. Understanding both is the difference between a safe fix and a footgun:

PropertyEffect

Encrypt=true (default)Negotiate TLS for the connection AND validate the server certificate against a trusted CA

TrustServerCertificate=trueStill encrypt, but skip the certificate-trust check (accept a self-signed cert)

Encrypt=falseDon't encrypt the connection at all (no TLS)

The quick fix — and exactly when it's safe

The common fix is to keep encryption on but stop validating the certificate:

Server=localhost;Database=MyApp;User Id=myapp;Password=...;

Encrypt=True;TrustServerCertificate=True;

TrustServerCertificate=True keeps the connection encrypted but tells the client to accept the server's self-signed certificate without checking the chain. The critical nuance: encryption without validation protects against passive eavesdropping but not against an active man-in-the-middle who could present their own certificate. That risk only matters if the connection crosses an untrusted network.

So TrustServerCertificate=True is perfectly safe when the app and SQL Server are on the same machine or the same trusted private network — the traffic never leaves a network you control, so there's no attacker in the middle to worry about. It's the standard, correct setting for that topology. It is not appropriate when your app connects to a SQL Server across the public internet.

The proper fix for cross-network connections

If your app and database genuinely sit on different machines across an untrusted network, don't suppress validation — fix the trust instead:

Install a certificate on SQL Server that's issued by a CA your app's host trusts (an internal CA, or a public one), then leave Encrypt=True and TrustServerCertificate=False. The chain validates and the warning disappears for the right reason.

Make sure the certificate's subject/SAN matches the server name you put in the connection string — a name mismatch fails validation even with a trusted CA.

Setting Encrypt=False is the option to avoid: it turns encryption off entirely, which is worse than a self-signed cert. Only consider it on a fully isolated local connection, and even then TrustServerCertificate=True (encrypt + don't validate) is the better choice.

Don't confuse this with a login or timeout failure

The pre-login handshake error happens before authentication, so it's not a wrong-password problem. If your connection gets past the handshake and then fails, you're looking at a different issue — a login/permissions error, or a timeout. For the latter, see our guide to SQL Server connection timeout errors in ASP.NET Core.

How this works on Adaptive Web Hosting

On Adaptive Web Hosting's ASP.NET Core plans, your application and its SQL Server 2022 database run on the same Windows server, so your app connects over a local connection that never crosses an untrusted network:

Same-host connection — because the database is local to your app, Encrypt=True;TrustServerCertificate=True is both the working setting and the safe one: there's no public-network hop for a man-in-the-middle to exploit.

Real SQL Server 2022, not Express — a full instance with no database-size caps or Express feature limits, so you're not working around edition restrictions on top of the cert issue.

Plesk-managed databases — create databases and users from the Plesk control panel; the connection details Plesk gives you work with the connection string above.

Side-by-side runtimes — whether you're on .NET 8 LTS, .NET 10 LTS, or running self-contained, the Microsoft.Data.SqlClient behaviour is identical; the fix above applies across versions.

Frequently asked questions

Is TrustServerCertificate=True a security risk?

Only on untrusted networks. It keeps the connection encrypted but skips certificate validation, which leaves it theoretically open to a man-in-the-middle who can intercept the traffic. When the app and SQL Server are on the same machine or the same private network — the common case — there's no such attacker position, so it's the standard, safe setting.

Why did this start happening after I upgraded?

You almost certainly moved to Microsoft.Data.SqlClient 4.0 or later (pulled in by EF Core 7+, .NET 8, or a package update). Version 4.0 changed the Encrypt default from false to true, so connections that previously skipped TLS now negotiate it and validate the certificate. Your code didn't change — the driver default did.

What's the difference between Encrypt=False and TrustServerCertificate=True?

Encrypt=False turns off encryption entirely — data travels in clear text. TrustServerCertificate=True keeps encryption on but doesn't validate the certificate. The second is almost always the better choice: you keep the wire encrypted and only relax the trust check.

Does System.Data.SqlClient behave differently?

Yes. The legacy System.Data.SqlClient kept Encrypt=false as its default, so apps on it don't hit this until migrated. Microsoft.Data.SqlClient is the actively-developed driver and the one to standardise on; just be aware of its encrypt-by-default behaviour.

I added TrustServerCertificate=True and it still fails — why?

If it still fails at the handshake, check that the property is on the connection string the app actually uses (not a different environment's config), and that there's no stray Encrypt/TrustServerCertificate being overridden in code via SqlConnectionStringBuilder. A failure after the handshake is a different problem — login, firewall, or timeout.

Bottom line

"The certificate chain was not issued by a trusted authority" is the SQL Server driver doing its job after Microsoft.Data.SqlClient 4.0 made Encrypt=true the default. For an app and database on the same machine or trusted network, add TrustServerCertificate=True — encrypted and safe for that topology. For connections across untrusted networks, install a CA-trusted certificate instead of suppressing the check.

On Adaptive Web Hosting, your app and its real SQL Server 2022 run on the same Windows server, so the local connection is safe and the standard connection string just works. Every plan includes a 30-day money-back guarantee. Compare hosting plans, read our SQL Server connection timeout guide, or talk to an ASP.NET specialist.