Quick answer: if you see The certificate chain was issued by an authority that is not trusted, the preferred fix is to make the SQL Server certificate chain trusted by the client and verify that the certificate identity matches the server name you use. If you need an immediate workaround in a controlled environment, add TrustServerCertificate=True to the connection string. The connection remains encrypted, but certificate validation is bypassed.
Background
Connecting to an SQL Server might sometimes throw errors related to SSL certificates.
One standard error is caused by the server's certificate not being trusted by the client machine.
This article will guide you through resolving such SSL certificate trust issues.
This can appear even when the SQL Server itself has not changed. Newer client drivers increasingly enable encryption by default. In Microsoft.Data.SqlClient, Encrypt defaults to true starting with version 4.0 and to Mandatory starting with version 5.0. Once encryption requires certificate validation, a certificate chain that the client cannot trust becomes visible as a connection failure.
The Certificate Chain Was Issued by an Authority That Is Not Trusted
You might encounter the following SQL Server login error in Microsoft.Data.SqlClient or a related SQL client:
Failed to detect SqlServer version.
A connection was successfully established with the server, but then an error occurred during the login process.
(provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)Microsoft.Data.SqlClient.SqlException (0x80131904):
A connection was successfully established with the server, but then an error occurred during the login process.
(provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
---> System.ComponentModel.Win32Exception (0x80090325):
The certificate chain was issued by an authority that is not trusted.This error indicates that the SSL certificate provided by the SQL Server is not trusted by the client machine.
More precisely, the client established contact with SQL Server but could not validate the certificate presented during TLS negotiation. Typical causes include an untrusted issuing CA, a missing intermediate certificate, a self-signed certificate, or a certificate name that does not match the server name used by the client.
Steps to Resolve the Issue
Install the Root Certificate: Ensure that the root certificate used by the SQL Server is installed in the Trusted Root Certification Authorities store on the client machine.
Update Connection String: Modify the connection string to either bypass certificate validation (not recommended for production environments) or to explicitly trust the server certificate.
Recommended order: fix the certificate and trust chain first. Use TrustServerCertificate=True only when you understand why validation is being bypassed, for example in a controlled local development environment.
Step 1: Establish a Trusted Certificate Chain
The durable fix is not simply to copy any certificate into the Trusted Root store. SQL Server should present a certificate that the client can validate to a trusted root certification authority.
Check the Certificate Used by SQL Server
On the SQL Server machine, open MMC.
Go to File > Add/Remove Snap-in, select Certificates, and choose Computer account.
Inspect Personal > Certificates and identify the certificate configured for SQL Server.
Check its issuer, expiration date, intended usage, and subject/SAN names.
Trust the Issuing CA on the Client
If the certificate was issued by an internal CA, install the appropriate root CA certificate in Trusted Root Certification Authorities and any required intermediate CA certificates in the appropriate intermediate store on the client machine.
If SQL Server is intentionally using a self-signed certificate, trusting that exact certificate may be acceptable in a tightly controlled environment, but a CA-issued certificate is the better production model.
For applications running as Windows services, IIS application pools or other machine identities, use the Local Computer certificate stores rather than assuming the current user's store is sufficient.
Step 2: Update the Connection String
How to Use TrustServerCertificate=True
If you need to connect immediately while the certificate trust problem is being fixed, add TrustServerCertificate=True to the SQL Server connection string:
"umbracoDbDSN": "Server=MSSQL-7CC6CS1;Database=YOUR-DB-DEV;Integrated Security=True;Encrypt=True;TrustServerCertificate=True;Connection Timeout=300"Important: in the example above, Encrypt=True explicitly requires TLS encryption, while TrustServerCertificate=True bypasses normal certificate-chain trust validation. This can be useful as a controlled workaround or diagnostic step, but it is not equivalent to fixing certificate trust.
Should You Use TrustServerCertificate=True in Production?
Usually, no. For a normal production configuration, prefer a certificate that chains to a CA trusted by the client and keep certificate validation enabled. This verifies not only that traffic is encrypted, but also that the client is talking to the expected server.
TrustServerCertificate=True can still be reasonable in a deliberately controlled environment where you understand the trust model. Do not use it automatically just because it makes the exception disappear.
Preferred Production Connection String
When the server certificate is correctly provisioned and trusted, make the security intent explicit:
Server=sql.example.internal;
Database=YOUR-DB;
Integrated Security=True;
Encrypt=True;
TrustServerCertificate=False;With validation enabled, the server name used by the client must be compatible with the identity in the certificate. If you connect through a DNS alias, check the certificate Subject Alternative Name configuration before disabling validation.
Which Fix Should You Use?
Situation | Preferred action |
|---|---|
Production or sensitive environment | Provision a valid certificate and make the issuing chain trusted by the client. |
Internal CA | Deploy the CA trust chain to clients and verify the certificate name. |
Local development or short-lived controlled environment |
|
Error appeared after a driver/tool upgrade | Check whether the new client changed its default encryption behavior before changing SQL Server configuration. |
Troubleshooting Tips
Verify SQL Server Configuration: Ensure that SQL Server is configured to use the expected TLS certificate.
Inspect the full certificate chain: Confirm that the client trusts the root CA and has any required intermediate certificates.
Verify the server name: Make sure the DNS name used in the connection matches the certificate identity.
Check the client driver version: A driver upgrade can change encryption defaults even when the server has not changed.
Review SQL Server and client logs: Use the exact exception and environment details to distinguish trust-chain problems from hostname, protocol, or authentication failures.
Final Thoughts on Resolving SQL Server SSL Certificate Issues
Following these steps, you should be able to resolve SSL certificate trust issues when connecting to SQL Server.
For production, prefer fixing certificate trust rather than suppressing validation. TrustServerCertificate=True is useful because it can quickly prove that certificate validation is the failing part of the connection, but that diagnostic success does not make it the strongest long-term security configuration.
Frequently Asked Questions
Why did the SQL Server certificate error appear after an upgrade?
Newer SQL client versions can enable encryption by default. For example, Microsoft.Data.SqlClient changed the default Encrypt behavior in version 4.0, which can expose certificate trust problems that older clients did not validate by default.
What does TrustServerCertificate=True do in a SQL Server connection string?
TrustServerCertificate=True allows TLS encryption while bypassing normal certificate-chain trust validation. It can be practical in controlled development or temporary troubleshooting scenarios, but it is usually not the preferred production configuration.
Should I import the SQL Server certificate into Trusted Root Certification Authorities?
Usually you should trust the CA that issued the server certificate, not place an ordinary leaf server certificate in the root store. A self-signed certificate is a special case because it acts as its own trust anchor.
Can a hostname mismatch cause a SQL Server TLS connection failure?
Yes. When certificate validation is enabled, the server name used by the client must match the identity represented by the certificate, subject to the driver's certificate-validation rules.
