The certificate chain was issued by an authority that is not trusted is a common SQL Server connection error that appears when the client encrypts the connection but cannot validate the SQL Server TLS certificate. It can occur in SSMS, applications using Microsoft.Data.SqlClient, ODBC, and other SQL Server clients.

The issue became more common after newer SQL Server drivers and SSMS 20+ changed their default encryption behavior. The long-term fix is to use a SQL Server certificate that the client trusts. For development or controlled environments, you can also enable Trust server certificate to bypass certificate validation.

Why does this SQL Server certificate error occur?

During an encrypted connection, the client validates the certificate presented by SQL Server. The certificate chain must lead to a certificate authority (CA) trusted by the client, and the certificate name must match the server name being used for the connection.

The error usually means the client cannot build a trusted certificate chain. Common causes include:

  • The SQL Server certificate is self-signed or issued by a private CA that the client doesn’t trust.
  • The issuing CA or an intermediate CA certificate is missing from the client trust store.
  • The SQL Server certificate is expired, invalid, or otherwise unsuitable for the connection.
  • The server name used by the client doesn’t match the certificate’s CN or SAN.
  • A newer client driver has encryption enabled by default, exposing a certificate configuration problem that older drivers didn’t report.

Why does it happen with SSMS 20 and later?

Starting with SSMS 20, the connection dialog uses Mandatory encryption by default. The Encryption and Trust server certificate settings are available directly on the connection page. With certificate validation enabled, SSMS expects the SQL Server certificate to be trusted by the client.

This is also relevant when applications move to newer Microsoft SQL Server drivers. For example, Microsoft ODBC Driver 18 enables encryption by default, so an application that previously connected without validating a server certificate can start showing this error after a driver upgrade.

How to fix the error in SSMS

If you need to connect to a SQL Server that doesn’t currently have a certificate trusted by the client, SSMS provides a direct connection option.

  1. Open SQL Server Management Studio and select Connect > Database Engine.
  2. Enter the SQL Server instance and authentication details.
  3. On the connection page, open Connection Security.
  4. Leave Encryption enabled as required and select Trust server certificate.
  5. Select Connect.
Trust server certificate option in the SSMS SQL Server connection dialog

Important: this option does not fix the underlying certificate configuration. It tells the client to encrypt the connection without validating the SQL Server certificate chain. Microsoft documents this as a less secure option because it removes server certificate validation.

How to fix it properly with a trusted certificate

For production environments, the preferred solution is to configure SQL Server with a TLS certificate issued by a CA trusted by the client. The client must be able to build the certificate chain to a trusted root CA, and the server name used for the connection must match the certificate’s CN or SAN.

  • Obtain a suitable TLS certificate from a trusted public or corporate CA.
  • Install and configure the certificate for the SQL Server Database Engine.
  • Make sure the client trusts the issuing root and intermediate CA certificates.
  • Connect using a server name that matches the certificate.
  • Keep Trust server certificate disabled so the certificate is actually validated.

Fix the error in a connection string

If the application is using Microsoft.Data.SqlClient, a temporary or controlled-environment workaround is to set TrustServerCertificate=True while encryption remains enabled:

Data Source=<sql server instance name>;
Initial Catalog=<database name>;
Integrated Security=True;
Encrypt=True;
TrustServerCertificate=True;

With TrustServerCertificate=True, TLS encryption is still used, but the client bypasses certificate-chain validation. This should not be treated as equivalent to using a trusted server certificate.

What if you use ODBC Driver 18?

ODBC Driver 18 and later use encryption by default. If the SQL Server certificate isn’t trusted by the client, you can use TrustServerCertificate=yes as a workaround, or configure a certificate that the client trusts. ODBC also supports Encrypt=optional, Encrypt=mandatory, and Encrypt=strict, depending on the scenario.

Microsoft recommends provisioning a certificate trusted by the client rather than permanently bypassing certificate validation.

What if the error says the target principal name is incorrect?

This is a different certificate problem. If the error says “The target principal name is incorrect” or indicates that the certificate subject name doesn’t match the host name, check the certificate’s CN/SAN and the server name used by the client.

For Microsoft.Data.SqlClient, HostNameInCertificate can be used when the expected certificate name differs from the server name in the connection string. With newer SqlClient versions, ServerCertificate can also be used for an exact certificate match in supported encryption modes.

Should you use TrustServerCertificate=True?

Use it as a deliberate workaround, not as a replacement for certificate configuration. It is useful for local development, testing, isolated environments, or situations where certificate deployment cannot be completed immediately. In production, a trusted certificate provides server identity validation in addition to encryption.

Quick troubleshooting checklist

  • Is encryption enabled by SSMS or your client driver?
  • Is the SQL Server TLS certificate expired or otherwise invalid?
  • Does the client trust the issuing CA and all required intermediate certificates?
  • Does the certificate CN/SAN match the server name used by the client?
  • Did the problem start after upgrading ODBC, OLE DB, SqlClient, or SSMS?
  • Are you using TrustServerCertificate=True intentionally, or was it added only to bypass the error?

Summary

The “certificate chain was issued by an authority that is not trusted” error means the SQL Server client cannot validate the certificate presented during the encrypted connection. In SSMS 20+ and newer SQL Server drivers, this can appear after encryption defaults become stricter.

For a durable production fix, use a SQL Server TLS certificate that the client trusts. If you need an immediate workaround, enable Trust server certificate in SSMS or use TrustServerCertificate=True in the appropriate connection string, understanding that certificate validation is bypassed.

For the latest driver-specific behavior, see Microsoft’s documentation for SSMS connection encryption, Microsoft.Data.SqlClient connection strings, and certificate chain trust errors after driver upgrades.

Kunal Rathi

With over 15 years of experience in data engineering and analytics, I've assisted countless clients in gaining valuable insights from their data. As a dedicated supporter of Data, Cloud and DevOps, I'm excited to connect with individuals who share my passion for this field. If my work resonates with you, we can talk and collaborate.