ErrorHarbor
Error Library

SQL Server: The Certificate Chain Was Issued by an Authority That Is Not Trusted

This error places the failure at the SQL connection's TLS/certificate-validation boundary: the client is evaluating a server certificate chain it does not trust under the active connection settings. If it appeared after upgrading to ODBC Driver 18, OLE DB Driver 19, Microsoft.Data.SqlClient 4+, or SSMS 20+, the SQL Server may not have changed—the newer client can require encryption/certificate validation where the previous path did not. For production, identify the certificate actually presented on the failing endpoint and repair the intended trust path. Treat TrustServerCertificate as a deliberate identity-validation bypass, not as proof that the certificate is trustworthy.

SQL Server · TLS · Certificate trustODBC 18 · OLE DB 19 · SqlClient · SSMS 20+Last reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
The message says The certificate chain was issued by an authority that is not trusted, often with SSL Provider or error -2146893019.The connection reaches the TLS/certificate-validation phase and fails on the server certificate chain before normal application work proceeds.The error started after a driver, application runtime, or SSMS upgrade—or only on a machine/container that does not trust the issuing CA.
30-second decision — do not bypass validation before choosing the branch
Started after client upgradeIdentify the actual driver/tool first. ODBC 18, OLE DB 19, SqlClient 4+, and SSMS 20+ changed encryption defaults.
Production / Internet / sensitive networkPrefer a SQL Server certificate chaining to a CA trusted by clients. Do not make TrustServerCertificate the permanent fix.
Internal/dev self-signed serverA temporary validation bypass may restore connectivity, but document that identity validation is skipped.
SSMS 20+ with Strict encryptionTrust server certificate is unavailable; Strict always validates the certificate. Fix trust/name/certificate instead.
Only one client failsCompare that client’s root/intermediate trust and driver configuration with a working client.
Difficulty: ModerateSecurity-sensitive
⚡ Quick Check — what changed?

Before editing the connection string, record the client and its encryption setting. A common pattern is an upgrade from an older SQL client to a version that enables encryption by default.

1
Client/tool
ODBC 18+? MSOLEDBSQL19? Microsoft.Data.SqlClient 4+? SSMS 20+?
2
Encryption mode
Mandatory/True, Optional/False, or Strict?
3
Certificate
Public CA, enterprise/internal CA, or SQL Server self-signed fallback?

Verify: reproduce once with the exact client that fails. Do not assume an SSMS result proves your application driver uses the same settings.

ADSENSE · reserved slot after the first useful step

Why this suddenly appears after an upgrade

Microsoft documents a major compatibility boundary: ODBC Driver 18+ defaults encryption to mandatory, OLE DB Driver 19+ defaults to mandatory, Microsoft.Data.SqlClient 4.0+ defaults Encrypt=True, and SSMS 20+ defaults encryption to Mandatory. Older clients often did not require encryption by default. Once encryption is required, the client validates the SQL Server certificate and an existing self-signed or privately issued certificate can suddenly become visible as a trust failure.

Reader shortcut: if the error began immediately after upgrading the client, do not start by rebuilding SQL Server. First confirm whether the upgrade changed encryption/certificate validation behavior.

Verify: compare the failing client version and connection properties with the last known working environment.

Fix #1 — production path: repair certificate trust

The strongest long-term fix is for the endpoint the client actually reaches to present the intended TLS certificate and chain that the client can validate. Do not infer the presented certificate only from SQL Server Configuration Manager or an inventory record: aliases, listeners, proxies/load balancers, containers, different instances/ports, or stale bindings can make the failing path present something else. For an enterprise/internal CA, distribute the approved root/intermediate chain through your PKI mechanism.

Security gate: do not download an arbitrary root certificate from the web or copy a certificate from an unknown machine into Trusted Root just to make the error disappear. Confirm the expected SQL Server identity, issuer, thumbprint, and approved CA chain first.

Also separate chain trust from name validation. If the chain becomes trusted but the server name does not match the certificate, the next error may be “target principal name is incorrect” or a hostname mismatch. That is a different branch, not evidence that trust repair failed.

Verify: reconnect through the same hostname/instance/port or listener used by the failing application with certificate validation enabled. Confirm the certificate actually presented is the intended one and that its chain and server name validate without TrustServerCertificate.

Fix #2 — understand TrustServerCertificate before using it

TrustServerCertificate tells the client to skip server-certificate validation when the connection is encrypted; it does not turn encryption on by itself. Whether traffic is encrypted still depends on the client Encrypt setting and server-side Force Encryption/Strict settings. Microsoft warns that bypassing validation weakens protection against an adversary-in-the-middle attack. Use it only for controlled development/internal scenarios or temporary recovery—not as a certificate-chain repair.

ODBC: TrustServerCertificate=yes Microsoft.Data.SqlClient: TrustServerCertificate=True OLE DB provider string: TrustServerCertificate=yes
Not a paste-ready connection string: these are only the relevant keywords. Add the correct keyword to your existing connection configuration; never paste credentials into public logs or examples.

With SSMS 20+, the equivalent is the Trust server certificate option on the Login page. With Strict encryption, this bypass is unavailable because the certificate is always validated.

Verify: if bypassing validation makes the connection work, you have confirmed a certificate-validation branch. You have not proved that the certificate or CA is trustworthy, and you should separately confirm that the resulting connection is actually encrypted.

Fix #3 — use the setting that belongs to your actual client

ODBC Driver 18+: encryption is enabled by default. Use the ODBC Encrypt and TrustServerCertificate settings or their DSN equivalents. If the chain is trusted but the hostname is the remaining mismatch, HostNameInCertificate can specify the expected certificate name. In supported Strict/TDS 8.0 scenarios, ODBC 18.1+ also supports ServerCertificate to match the presented server certificate against a certificate file. These are identity-validation tools, not substitutes for an untrusted CA chain.

OLE DB Driver 19+: encryption defaults to Mandatory. Provider/ADO keyword spelling differs, so follow the connection API you actually use rather than copying an ODBC string.

Microsoft.Data.SqlClient 4+: Encrypt=True became the default. Inspect the application’s effective connection string/configuration, not just SQL Server settings.

SSMS 20+: Encryption defaults to Mandatory and Trust server certificate defaults off. The Login page exposes Optional, Mandatory, and Strict where supported.

Verify: capture the effective driver/provider and its actual encryption properties from the failing application. Avoid “works in SSMS” as the only test for an application failure.

Fix #4 — Strict encryption changes the decision

In SSMS 20+ and supported SQL Server/Azure SQL scenarios, Strict encryption requires certificate validation. The Trust server certificate control is unavailable under Strict. If Strict is intentional, repair certificate trust and identity rather than searching for a bypass checkbox.

Do not silently downgrade Strict to Mandatory/Optional just to clear the error. First confirm the security requirement and server capability.

Verify: reconnect using the intended encryption level and confirm the certificate presented by the intended server validates without bypass.

Fix #5 — should you set Encrypt to Optional?

Microsoft documents Optional/False as a compatibility setting when the client does not require encryption. This can resemble pre-upgrade client behavior, but it is a security decision, not a certificate fix. It also does not guarantee plaintext: server-side Force Encryption or another negotiated/server requirement can still result in an encrypted connection. Conversely, when encryption is not required by either side, relying on Optional can leave application traffic without the TLS protection you intended.

Use Optional only when your environment’s security requirements explicitly permit it. For production systems that require TLS, fix the server certificate and client trust instead.

Verify: inspect the resulting session/server-side connection state and document whether that actual application connection is encrypted. Do not infer encryption merely from the connection-string keyword or from “the application connects again.”

Fix #6 — works on one machine but fails on another

This pattern strongly points to client-side trust or configuration differences. Compare the issuing root/intermediate availability, machine/user certificate stores where relevant, container image, driver version, and effective connection settings. Enterprise policy can also distribute or remove trust differently across machines.

Do not bulk-copy Trusted Root stores from a working machine. Identify the specific approved CA chain required by the SQL Server certificate.

Verify: after deploying the approved CA chain/configuration, retest with certificate validation enabled on the previously failing client.

Final verification — prove trust, encryption, and server identity

A durable fix should answer three separate questions: is the connection encrypted, is the certificate chain trusted, and does the certificate represent the SQL Server name you intended to reach?

Production acceptance checklist:expected SQL Server hostname/instanceintended encryption modeserver certificate subject/SAN and issuerapproved root/intermediate chaincertificate validation enabledapplication connects with its real driver, not only SSMS

Verify: remove any temporary TrustServerCertificate bypass when the approved trust path is ready and confirm the real application still connects.

What not to do

Do not make TrustServerCertificate=True the default production answer without documenting that validation is bypassed.Do not import an unknown root certificate simply because a forum post says it clears the error.Do not downgrade ODBC/SSMS solely to hide the certificate problem.Do not disable encryption on an untrusted network just to reproduce old client behavior.Do not confuse a trusted chain with a matching hostname; they are separate checks.Do not assume every client uses the same keyword syntax or defaults.Do not use HostNameInCertificate to hide an untrusted CA-chain error; it addresses the expected server name after trust is established.Do not assume the certificate configured on the server is the certificate actually presented through the failing alias, listener, proxy/load balancer, instance or port.Do not equate Encrypt=Optional/False with “the connection is plaintext”; prove the negotiated session state because server requirements can still force encryption.Do not keep diagnosing chain trust once the intended chain validates and the failure changes to hostname, protocol, login or another connection stage.

Still seeing the certificate-chain error?

Capture these before escalating:exact error and provider nameSQL client/driver and versioneffective Encrypt/Encryption modewhether TrustServerCertificate is enabledSQL Server version and Force Encryption/Force Strict Encryption statecertificate actually presented on the failing hostname/instance/port or listener: subject/SAN, issuer, thumbprint, and expirywhether the issuing root/intermediate is trusted on the failing clientwhether another client succeeds with validation enabledthe exact hostname/instance/port/listener used by the failing applicationwhether the presented certificate differs across aliases, listeners, nodes, containers or load-balanced pathsthe actual negotiated encryption state after any compatibility testthe first different error after certificate-chain validation succeeds

If the next error becomes a hostname/target-principal mismatch, troubleshoot certificate naming rather than adding more trust. If the failure is only in one application, inspect that application’s effective provider and connection string.

Official references

Microsoft: untrusted certificate authority errorClient-version defaults, trust repair, bypass, and encryption options →Microsoft: certificate chain not trusted after driver upgradeODBC 18 / OLE DB 19 migration behavior and security warning →Microsoft: SSMS connection securityMandatory/Optional/Strict and Trust server certificate behavior →

Still stuck? Ask the community

Share the redacted provider/driver version, encryption mode, certificate issuer/subject, and whether the same server works from another client.

Keep it safe: never post database passwords, full connection strings with secrets, private keys, PFX files, internal tokens, or confidential certificate material.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…