If you recently upgraded SQL Server Management Studio (SSMS) to version 19 or 20, or upgraded an application’s Microsoft Data SqlClient, ODBC Driver 18 or 19, or OLE DB Driver 18 or 19, and started seeing this error, the server did not change. The client changed.
Older SQL Server client tools and drivers assumed encryption was off by default and did not validate the server certificate. Starting with SSMS 19 (released 2022) and the Microsoft Data SqlClient 4.0 driver, the defaults changed: encryption is now on by default, and certificate chain validation is enforced by default. If the SQL Server instance is running a self-signed certificate (which SQL Server generates automatically at installation for its own use) or a certificate from an untrusted CA, the new client tools fail the connection with the SSL certificate error.
SSMS 20 (2024) went further: encryption is now set to Mandatory by default rather than Optional. Any SQL Server instance without a properly trusted certificate now fails connections from SSMS 20 out of the box.
This article covers the diagnostic steps to identify exactly which certificate problem applies, the correct permanent fix for each scenario, and when the bypass options are acceptable.
The SSL Certificate Error Messages and What Each Means
| Error message | What it means | Likely cause |
| The certificate chain was issued by an authority that is not trusted | Client validated the certificate chain and the root CA is not trusted | SQL Server using a self-signed certificate; or using an internal CA certificate not in the client’s trust store |
| The target principal name is incorrect | Certificate was presented but the hostname in the certificate does not match the server name the client used to connect | Certificate issued for a different hostname (FQDN vs. short name vs. IP address) |
| The certificate has expired or is not yet valid | Certificate is outside its validity period | Expired SQL Server certificate; check certificate expiry in SQL Server Configuration Manager |
| SSL Provider: An existing connection was forcibly closed by the remote host | Connection dropped during TLS negotiation; protocol/cipher incompatibility | TLS version mismatch between client and server; outdated SQL Server not supporting required TLS version |
| A connection was successfully established with the server, but then an error occurred during the login process | Connection succeeded but login encrypted handshake failed | Usually the chain-not-trusted error; check full error detail for underlying error code |
The SSMS 19 and 20 Default Encryption Change: Why This Broke Existing Connections
Understanding the version history of SSMS encryption defaults explains why this error started appearing for many environments that had worked fine for years:
| SSMS Version | Default encryption | Certificate validation | Behavior for self-signed certs |
| SSMS 18 and earlier | Off (not encrypted by default) | Not validated | Connected without errors; traffic not encrypted |
| SSMS 19 (2022) | On if Force Encryption is set; otherwise depends on server setting | Enforced when encryption is on (breaking change from SSMS 18 behavior) | Error if encryption is on and cert is self-signed; worked before because validation was not enforced |
| SSMS 20 (2024) | Mandatory by default | Enforced; Trust Server Certificate option available for Mandatory mode | Error by default for any SQL Server without a trusted certificate; requires Trust Server Certificate checkbox or a proper cert |
| SSMS 20 Strict mode | Strict (TDS 8.0 / TLS 1.3) | Enforced; Trust Server Certificate not available | Requires a properly trusted certificate; no bypass option exists |
The SSMS 20 Strict encryption mode uses TDS 8.0 and TLS 1.3. It is available for connections to SQL Server 2022 and Azure SQL. In Strict mode, the Trust Server Certificate option is disabled entirely and greyed out. There is no workaround for certificate issues in Strict mode: a properly trusted certificate on the SQL Server is required. Strict is not the default but is the most secure and recommended mode for SQL Server 2022 and Azure SQL Database.
Diagnosing the Specific Cause Before Applying a Fix
The correct fix depends on which specific certificate problem applies. Applying the wrong fix either creates a security gap or does not actually solve the root cause.
Check what certificate SQL Server is using
Open SQL Server Configuration Manager (search for it in the Start menu). Expand SQL Server Network Configuration, right-click on Protocols for your SQL Server instance, and select Properties. Go to the Certificate tab. If the Certificate field is blank, SQL Server is using its auto-generated self-signed certificate. If a certificate is listed, click to view it and check the subject name, expiry date, and issuer.
| — From SQL Server: check which certificate is being used
— (Works on SQL Server 2019+) SELECT certificate_name, expiry_date, pvt_key_encryption_type_desc, subject FROM sys.certificates WHERE pvt_key_encryption_type = ‘MK’;
— Alternatively: check the SQL Server error log for TLS certificate info — Look for lines starting with ‘The server will use…’ after startup EXEC xp_readerrorlog 0, 1, N’certificate’; |
Check if the certificate is trusted on the client
From the client machine that is receiving the connection error, open a browser and navigate to any HTTPS site using the same certificate (if it is an internal site). Or use PowerShell:
| # Check if the SQL Server certificate is trusted from the client machine:
$ $tcp = New-Object System.Net.Sockets.TcpClient $ $tcp.Connect(‘your-sql-server-hostname’, 1433) $ $sslStream = New-Object System.Net.Security.SslStream($tcp.GetStream(),$false, $Â Â {param($sender,$cert,$chain,$errors) Write-Host ‘Errors:’ $errors; return $true}) $ $sslStream.AuthenticateAsClient(‘your-sql-server-hostname’) $ $cert = $sslStream.RemoteCertificate $ Write-Host ‘Subject:’ $cert.Subject $ Write-Host ‘Issuer:’ $cert.Issuer $ Write-Host ‘Valid until:’ $cert.GetExpirationDateString() $ $tcp.Close() |
The Permanent Fix: Install a Trusted Certificate on SQL Server
This is the correct production solution. Install a certificate from a trusted CA on the SQL Server instance and configure SQL Server to use it. All clients that trust that CA will connect without errors and without bypasses.
Certificate requirements for SQL Server
- The certificate must be in the SQL Server service account’s personal certificate store on the local computer
- The certificate subject name or Subject Alternative Name must include the server hostname as clients will connect to it (both short name and FQDN if both are used)
- The certificate must have the Server Authentication extended key usage (EKU)
- The private key must be accessible to the SQL Server service account
- For internal SQL Servers not accessible from the public internet: a certificate from an internal CA (Active Directory Certificate Services) is appropriate
- For SQL Servers accessible from the public internet: a certificate from a public CA (Let’s Encrypt or commercial CA) is appropriate
| — After installing the certificate in the Windows Certificate Store,
— configure SQL Server to use it via SQL Server Configuration Manager: — SQL Server Network Configuration > Protocols for MSSQLSERVER — Properties > Certificate tab > select the installed certificate — Restart SQL Server service to apply
— Verify the new certificate is in use by checking the error log after restart: EXEC xp_readerrorlog 0, 1, N’certificate’; — Should show a line like: — ‘Server is listening on [ ‘any’ <ipv4>Â 1433] using certificate [YourCertCN]’ |
For SQL Servers in an Active Directory domain, AD Certificate Services (AD CS) is the most operationally efficient certificate source. AD CS can auto-enroll certificates to domain member servers, meaning SQL Server certificates are automatically issued, renewed, and trusted by all domain clients without manual intervention. The root CA certificate in AD CS is automatically distributed to all domain members via Group Policy, so clients trust the certificate without any additional configuration.
Intermediate Fix: Import the SQL Server’s CA Certificate to the Client Trust Store
If you are using an internal CA (private CA) that is not already in the client’s trust store, and installing a public CA certificate on the server is not practical immediately, you can import the internal CA’s root certificate into the client machine’s Trusted Root Certification Authorities store. This makes the client trust all certificates issued by that CA without bypassing certificate validation.
This is appropriate for: internal development environments, clients accessing SQL Servers with internal CA certificates in non-domain-joined scenarios, or temporary situations where the server certificate cannot be replaced immediately.
| # Import a CA root certificate into the Windows Trusted Root store:
# (Run as Administrator in PowerShell) $ Import-Certificate -FilePath ‘C:\path\to\internal-ca.cer’ -CertStoreLocation ‘Cert:\LocalMachine\Root’
# Verify the import: $ Get-ChildItem -Path ‘Cert:\LocalMachine\Root’ | Where-Object {$_.Subject -like ‘*YourCA*’}
# After importing, test the SQL Server connection without Trust Server Certificate enabled. # The connection should now succeed with proper certificate validation. |
The Bypass Options: When Acceptable and When Not
Two bypass options exist for the certificate error. Both should be treated as temporary measures, not permanent solutions.
SSMS: Trust Server Certificate checkbox
In SSMS 19 and 20, the connection dialog has a Trust Server Certificate option (Options tab, Connection Security or Login page depending on SSMS version). Checking this tells SSMS to encrypt the connection but skip certificate chain validation. The connection is encrypted; the server identity is not verified.
When acceptable: local development machines connecting to local or known development SQL Server instances, or internal tools where MITM attack is not a realistic threat model.
When not acceptable: any production connection, any connection across untrusted networks, any connection carrying sensitive data where the server identity must be verified.
Connection string: TrustServerCertificate=True
For application connections, the equivalent of the SSMS Trust Server Certificate checkbox is adding TrustServerCertificate=True to the connection string. This bypasses certificate chain validation while keeping encryption active.
| // .NET / C# connection string with bypass (development/testing only):
Server=myserver;Database=mydb;User Id=myuser;Password=mypass; Encrypt=True;TrustServerCertificate=True;
// NEVER use this in production connection strings. // It disables the identity verification that prevents MITM attacks.
// Correct production connection string (trusted cert on server): Server=myserver;Database=mydb;User Id=myuser;Password=mypass; Encrypt=True;TrustServerCertificate=False;
// Strict encryption (SQL Server 2022 / Azure SQL only): Server=myserver;Database=mydb;User Id=myuser;Password=mypass; Encrypt=Strict; // TrustServerCertificate is ignored in Strict mode; // a properly trusted certificate is required. |
TrustServerCertificate=True in a production connection string is a serious security misconfiguration. It disables certificate chain validation, meaning the client will connect to any server claiming to be the SQL Server, including an attacker performing a man-in-the-middle attack. If this setting exists in production connection strings because a proper certificate was never installed, it creates an exploitable gap. Audit all production connection strings for this setting and replace them with the proper certificate-based solution.
The Same Problem in MySQL and PostgreSQL
The certificate trust problem affects MySQL and PostgreSQL connections as well, with their own error messages and connection parameters.
MySQL SSL connection errors
MySQL connections use the ssl_ca parameter to specify a trusted CA certificate for verifying the server’s certificate. Without it, the driver may either refuse to connect (when ssl_mode=VERIFY_CA or VERIFY_IDENTITY) or connect without certificate validation (ssl_mode=REQUIRED).
| # MySQL connection string with CA certificate verification:
# (Python, using mysql-connector-python) config = { ‘host’: ‘mysql-server’, ‘user’: ‘myuser’, ‘password’: ‘mypass’, ‘ssl_ca’: ‘/path/to/ca-cert.pem’, ‘ssl_verify_cert’: True, ‘ssl_verify_identity’: True, # verifies hostname matches cert }
# MySQL ssl_mode options: # DISABLED:Â Â Â Â Â Â Â No SSL # REQUIRED:Â Â Â Â Â Â Â SSL required, no cert validation # VERIFY_CA:Â Â Â Â Â Â SSL + validate cert against ssl_ca # VERIFY_IDENTITY: SSL + validate cert + verify hostname match
# For Azure Database for MySQL, download the DigiCert Global Root G2 cert: # https://dl.cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem |
PostgreSQL SSL connection errors
PostgreSQL uses the sslmode parameter in the connection string and optionally sslrootcert to specify the CA certificate. The sslmode values range from disable (no SSL) to verify-full (SSL with hostname verification).
| # PostgreSQL connection string with full certificate verification:
# libpq connection string format: host=pgserver dbname=mydb user=myuser password=mypass sslmode=verify-full sslrootcert=/path/to/ca-cert.pem
# Python (psycopg2): conn = psycopg2.connect( host=’pgserver’, dbname=’mydb’, user=’myuser’, password=’mypass’, sslmode=’verify-full’, sslrootcert=’/path/to/ca-cert.pem’ )
# sslmode values: # disable:Â Â Â Â Â No SSL # allow:Â Â Â Â Â Â Â Try without SSL; use SSL if required # prefer:Â Â Â Â Â Â Try with SSL; fall back to no SSL (default in many clients) # require:Â Â Â Â Â SSL required; no cert validation # verify-ca:Â Â Â SSL + validate cert against sslrootcert # verify-full:Â SSL + validate cert + verify hostname (most secure)
# For Azure Database for PostgreSQL, download the Microsoft RSA Root CA 2017: # https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt # Convert if needed: openssl x509 -inform DER -in cert.crt -out cert.pem -outform PEM |
SQL Server 2025: Linked Server and Replication Breaking Changes
Microsoft’s SQL Server 2025 documentation explicitly lists certificate-related breaking changes. Organizations planning to upgrade to SQL Server 2025 from earlier versions should review these before migration.
Linked server connections fail after upgrade if the linked SQL Server does not have a trusted certificate installed. SQL Server 2025 uses Microsoft OLE DB Driver 19, which assumes encryption on by default. Existing linked server configurations created against older SQL Server instances that relied on unencrypted or self-signed-certificate connections will fail after the upgrade. The fix is to install trusted certificates on all SQL Server instances that are linked server targets before upgrading.
Replication (transactional, snapshot, peer-to-peer, and merge) also fails after upgrade if the publisher does not have a trusted certificate and Force Encryption or Force Strict Encryption is enabled. This requires the same fix: trusted certificates on all participating instances.
Before upgrading to SQL Server 2025, audit all linked server configurations and replication topologies for SSL certificate trust. Any SQL Server instance in the topology without a properly trusted certificate will become inaccessible after the upgrade until certificates are installed. A pre-upgrade certificate installation project is significantly less disruptive than an emergency certificate installation after a production upgrade fails.
Frequently Asked Questions
Why did my SQL Server connections start failing after upgrading SSMS?
SSMS 19 (2022) and SSMS 20 (2024) changed the default encryption behavior. SSMS 19 enabled certificate validation when encryption is active. SSMS 20 set encryption to Mandatory by default. Older SSMS versions connected without encryption or without validating the server certificate, so self-signed certificates (which SQL Server generates automatically) caused no error. The server has not changed; the client became stricter. The long-term fix is to install a trusted certificate on the SQL Server instance. The short-term workaround is to check Trust Server Certificate in the SSMS connection options, which should only be used in development environments.
Is TrustServerCertificate=True safe to use in production?
No. Setting TrustServerCertificate=True in a production connection string disables certificate chain validation, which removes the protection against man-in-the-middle attacks on the database connection. An attacker on the network path between the application and the SQL Server can intercept the connection and read or modify all database traffic without detection. This setting is acceptable for local development connecting to a local instance where no network traversal occurs. It is a security misconfiguration in any other context.
What certificate does SQL Server need to fix the SSL error?
SQL Server requires a certificate with the Server Authentication extended key usage, where the subject name or Subject Alternative Name includes the hostname clients will use to connect (both short name and FQDN if different clients use different forms). The certificate must be in the SQL Server service account’s personal certificate store. For internal SQL Servers, an internal CA (AD Certificate Services) is appropriate. For internet-accessible SQL Servers, a public CA certificate from Let’s Encrypt or a commercial CA is appropriate. After installing the certificate, configure SQL Server to use it in SQL Server Configuration Manager (Protocols > Properties > Certificate tab) and restart the service.
How do I fix SSL certificate errors connecting to Azure SQL Database or Azure Database for MySQL/PostgreSQL?
Azure managed database services use certificates from Microsoft’s certificate infrastructure. For Azure SQL Database, the certificates chain to publicly trusted roots in the Windows and browser trust stores, so properly configured connections with Encrypt=True should work without importing additional certificates. For Azure Database for MySQL and PostgreSQL, the specific root CA certificates required are available from Microsoft’s PKI pages: DigiCert Global Root G2 for MySQL, and Microsoft RSA Root Certificate Authority 2017 for PostgreSQL flexible server. Download the PEM file and specify it in the ssl_ca or sslrootcert connection parameter. Azure sometimes rotates these root certificates, which is the cause of sudden SSL errors in previously working connections.
