"The certificate chain was issued by an authority that is not trusted" when connecting DB in VM Role from Azure website

I am experiencing error when connecting MY DB which is in VM Role(I have SQL VM Role) from Azure Website. Both VM Role and Azure Website are in West zone. I am facing following issue:

>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.)]

I am able to connect to my DB using SSMS. 1433 port is open on my VM role. What is wrong with my connection?

2022 Update - This answer (as comments point out) provides an explanation and stop gap, but also offers some better recommendations including purchasing and installing a proper cert (thanks to numerous community edits).

Please see also the other highly voted answers in this thread, including the one by @Alex From Jitbit below about a breaking change when migrating from System.Data.Sql to Microsoft.Data.Sql (spoiler: Encrypt is now set to true by default).

Original answer:

You likely don't have a CA signed certificate installed in your SQL VM's trusted root store.

If you have Encrypt=True in the connection string, either set that to off (not recommended), or add the following in the connection string (also not recommended):

TrustServerCertificate=True

SQL Server will create a self-signed certificate if you don't install one for it to use, but it won't be trusted by the caller since it's not CA-signed, unless you tell the connection string to trust any server cert by default.

Long term, I'd recommend leveraging Let's Encrypt to get a CA signed certificate from a known trusted CA for free, and install it on the VM. Don't forget to set it up to automatically refresh. You can read more on this topic in SQL Server books online under the topic of "Encryption Hierarchy", and "Using Encryption Without Validation".

If you're using SQL Management Studio, please goto connection properties and click on "Trust server certificated"

I decided to add another answer, because this post pops-up as the first Google result for this error.

If you're getting this error after January 2022, possibly after migrating from System.Data.SqlClient to Microsoft.Data.SqlClient or just updating Microsoft.Data.SqlClient to version 4.0.0 or later, it's because MS has introduced a breaking change::

> https://docs.microsoft.com/en-us/sql/connect/ado-net/introduction-microsoft-data-sqlclient-namespace?view=sql-server-ver15#breaking-changes-in-40 > > ## Breaking changes in 4.0 > > ### Changed Encrypt connection string property to be true by default. > The default value of the Encrypt connection setting has been changed from false to true. With the growing use of cloud databases and the need to ensure those connections are secure, it's time for this backwards-compatibility-breaking change. > ### Ensure connections fail when encryption is required > In scenarios where client encryption libraries were disabled or unavailable, it was possible for unencrypted connections to be made when Encrypt was set to true or the server required encryption.

Rick Strahl has posted a detailed explanation on his blog

The change was made in this SqlClient pull-request in August 2021, where there is additional discussion about the change.

The quick-fix is to add Encrypt=False to your connection-strings.

If you're seeing this error message when attempting to connect using SSMS, add TrustServerCertificate=True to the Additional Connection Parameters.

While the general answer was in itself correct, I found it did not go far enough for my SQL Server Import and Export Wizard orientated issue. Assuming you have a valid (and automatic) Windows Security based login:

ConnectionString

Data Source=localhost; 
Initial Catalog=<YOUR DATABASE HERE>; 
Integrated Security=True; 
Encrypt=True; 
TrustServerCertificate=True; 
User Instance=False

That can either be your complete ConnectionString (all on one line), or you can apply those values individually to their fields.

If You are trying to access it through Data Connections in Visual Studio 2015, and getting the above Error, Then Go to Advanced and set TrustServerCertificate=True for error to go away.

I got this Issue while importing Excel data into SQLDatabase through SSMS. The solution is to set TrustServerCertificate = True in the security section

For those who don't like the TrustServerCertificate=True answer, if you have sufficient access you can export the SQL Server certificate and install where you're trying to connect from. This probably doesn't work for a SQL Server self-generated certificate but if you used something like New-SelfSignedCertificate you can use MMC to export the certificate, then MMC on the client to import it.

On SQL Server:

• In MMC add the certificate Snap-In
• Browse to Certificates > Personal > Certificate
• Select the new certificate, right-click, and select All Tasks > Manage Private Keys (this step and the following is part of making the key work with SQL server)
• Add the identity running SQL Server (look the identity up in Services if in doubt) with READ permission.
• Select the new certificate, right-click, and select All Tasks > Export...
• Use default settings and save as a file.

On the client:

• Use MMS with the same snap-in choices and in Certificates > Trusted Root Certification Authorities right-click Certificates and select All Tasks > Import...
• Import the previously exported file

(I was doing everything on the same server and still had issues with SSMS complaining until I restarted the SQL instance. Then I could connect encrypted without the Trust... checkbox checked)

Got hit by the same issue while accessing SQLServer from IIS. Adding TrustServerCertificate=True did not help.

Could see a comment in MS docs: Make sure the SQLServer service account has access to the TLS Certificate you are using. (NT Service\MSSQLSERVER)

Open personal store and right click on the certificate -> manage private keys -> Add the SQL service account and give full control.

Restart the SQL service. It worked.

I ran into this error trying to run the profiler, even though my connection had Trust server certificate checked and I added TrustServerCertificate=True in the Advanced Section. I changed to an instance of SSMS running as administrator and the profiler started with no problem. (I previously had found that when my connections even to local took a long time to connect, running as administrator helped).

The same can be achieved from ssms client itself. Just open the ssms, insert the server name and then from options under heading connection properties make sure Trust server certificate is checked.

I was getting the same error when trying to connect to MS SQL Server instance hosted on Google Cloud Platform using SSMS with unchecked Trust server certificate under the connection properties tab. I managed to trust the certificate by importing the GCP's provided certificate's authority to my local computer's list of Trusted Root Certification Authorities.

Read full description and resolution here.

Well in my case the Database was bad. When I re created a new database name the error got resolved. It's an error coming from SQL Server database. Try re creating a new database.

If you use Version 18 and access via pyodbc, it is "TrustServerCertificate=yes", you need to add to the connection

If you have created an ODBC connection to the server (using ODBC Driver 18 for SQL server) in ODBC settings (32 or 64), configure the connection and press Next 3 times. In the final screen, there is a "Trust server certificate" checkbox in the middle. Set it to checked. That will do the trick. Adding "TrustServerCertificate=True" to the connectionstring as suggested in other answers did not work for me.

If you are using any connection attributes mentioned in the answers, the values accepted are yes/no , if true/false doesn't seem to work.

TrustServerCertificate - Accepts the strings "yes" and "no" as values. The default value is "no", which means that the server certificate will be validated.

Using ODBC 18.0 - hope it helps.

Connection String Attributes