If you’ve recently upgraded SQL Server Management Studio and suddenly can’t connect to SQL Server, you may see an SSL or certificate error during login.
This commonly appears after upgrading to newer SSMS versions and is caused by a change in how SSMS handles encryption by default.
The good news: this is usually quick to fix once you understand what changed.
If you’ve not yet updated, see Install and Update SQL Server Management Studio (SSMS) for background on recent SSMS changes, update cadence, and default behaviour.
The Error Message
You may see an error similar to the following when connecting:
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.)The connection reaches SQL Server successfully, but fails during the encrypted login handshake.
This does not mean SQL Server is down or misconfigured.
Why This Happens in Newer SSMS Versions
Recent SSMS releases changed their default connection behaviour.
By default, SSMS now attempts to connect using encrypted connections, and it expects the SQL Server certificate to be trusted by the client.
This exposes situations where:
- SQL Server is using a self-signed certificate
- A certificate is issued by an internal CA not trusted by the client machine
- No explicit certificate configuration exists
Older SSMS versions often connected successfully because encryption was optional or less strictly enforced.
Nothing necessarily changed on the SQL Server, the client became stricter.
Resolution 1: Enable “Trust Server Certificate” (Most Common Fix)
The fastest and most common fix is to explicitly trust the server certificate during connection.
In the SSMS connection dialog:
- Open Options
- Go to the Connection Properties tab
- Enable Trust server certificate
- Connect again
This tells SSMS to use encryption but skip certificate chain validation.
This is commonly acceptable for:
- Internal servers
- Non-internet-facing environments
- Lab, test, and controlled production networks
Resolution 2: Change Encryption Setting to Optional
Newer SSMS versions expose encryption behaviour directly in the connection dialog.
Under Encryption, you may see options such as:
- Strict (SQL Server 2022 / Azure SQL only)
- Mandatory
- Optional
To bypass the certificate chain error:
- Open Options
- Set Encryption to Optional
- Connect again
With Optional selected, SSMS will still encrypt the connection where possible, but it will not fail the login if the certificate is untrusted.
Which Option Should You Use?
For most DBA environments:
- Trust Server Certificate is the quickest and clearest fix
- Optional encryption gives more control and visibility
If the SQL Server is:
- Internet-facing
- Subject to compliance or security audits
- Required to use validated certificates
Then the long-term solution is to install a properly trusted certificate on the SQL Server itself.
That is a different task and intentionally outside the scope of this post.
Important Notes
A few points worth keeping in mind:
- This error does not indicate database corruption
- SQL Server is usually operating normally
- The failure occurs during encrypted login only
- Upgrading SSMS can surface issues that previously went unnoticed
Understanding this prevents unnecessary server-side troubleshooting.
Final Thoughts
This error is one of the most common surprises after upgrading SSMS.
Nothing broke, the rules just changed.
Once you know where to look, fixing the “certificate chain not trusted” error takes seconds and restores normal connectivity without touching SQL Server itself.
If you manage multiple environments, it’s worth knowing exactly which encryption behaviour your SSMS installations are using.
Leave a Reply