SSL Certificate Chain Not Trusted When Connecting to SQL Server from .NET App

Question

SSL Certificate Chain Not Trusted When Connecting to SQL Server from .NET App

blom buffin 80

I’m developing a .NET application that connects to a SQL Server database over SSL, but I’m running into a trust issue with the certificate chain. The app is built with .NET 8 on Windows 11, and the SQL Server is on-premises (SQL Server 2019) with a self-signed certificate installed for encryption. The connection works without SSL, but when I enable “Encrypt=True;TrustServerCertificate=False” in the connection string, it fails.

Here’s the C# code snippet I’m using for the connection:

using System.Data.SqlClient;
string connectionString = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;Encrypt=True;TrustServerCertificate=False;";
try
{
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        connection.Open();
        Console.WriteLine("Connection successful!");
    }
}
catch (Exception ex)
{
    Console.WriteLine("Connection failed: " + ex.Message);
}

Then: Connection failed: 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.)

0 comments

3 answers

Your answer

Answer 1

Thank you, Vergil-V, for that enlightening and timely response.

I had an epiphany this morning upon waking and it is this:

I should not need a certificate to communicate with an instance of SQL that "I" installed on "my" own computer for "my" own personal use, while using the only account that exists on said computer, which is also the administrator account.

Thank you, but no thanks. I will recommend to my boss that we investigate other SQL options and avoid the Microsoft alternative. At first, I thought it would be wise to use Microsoft products on a Microsoft platform, but this lesson has taught me that just because it is the same brand does not imply higher (or better) compatibility. We will find our solution elsewhere.

Best regards,

Answer 2

bug meister 10

Dear sirs,

When I get to Option 3, Step 5 "Find the self-signed cert used for SQL Server encryption", there is no certificate there to export. Nothing.

Details:

Today's Date: 26-Jan-2026

OS: Windows 11 (updated as of 16-Jan-2026)

SQL: M/S Sql Server Express v. 17

Studio: SSMS v. 22.2.1

Error message: Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : SSL Provider: The certificate chain was issued by an authority that is not trusted.

Anonymous

2026-01-27T05:53:01.53+00:00
Hi @bug meister

Thank you for reaching out and for providing the details of your situation.

Based on your description, it appears that your SQL Server is currently using the built-in self-signed fallback certificate. While this certificate can be sufficient for basic or internal SQL Server operations, it is generally not recommended for broader use or for applications that require a higher level of trust and security.

For improved security and compatibility, it is recommended to either use a certificate issued by a trusted Certificate Authority or create a new self-signed certificate that is explicitly configured for SQL Server usage.

Below is an example PowerShell script you can use to create a new self-signed certificate:

# Define parameters $certificateParams = @{ Type = "SSLServerAuthentication" Subject = "CN=$env:COMPUTERNAME" DnsName = @("$($env:COMPUTERNAME)", $([System.Net.Dns]::GetHostEntry('').HostName), 'localhost') KeyAlgorithm = "RSA" KeyLength = 2048 HashAlgorithm = "SHA256" TextExtension = "2.5.29.37={text}1.3.6.1.5.5.7.3.1" NotAfter = (Get-Date).AddMonths(36) KeySpec = "KeyExchange" Provider = "Microsoft RSA SChannel Cryptographic Provider" CertStoreLocation = "cert:\LocalMachine\My" } # Call the cmdlet New-SelfSignedCertificate @certificateParams

For additional guidance, you may find the following Microsoft documentation helpful: Encrypt Connections by Importing a Certificate - SQL Server | Microsoft Learn

If you are looking for more detailed or environment specific advice, I would recommend creating a separate discussion thread. This allows other users who work closely with SQL Server environments to share their experiences and insights. As a forum moderator, I do not currently have access to a dedicated testing environment.

I hope this provides some additional clarity.

Answer 3

Hi @blom buffin
Thank you for reaching out to the Microsoft Q&A forum!
The error "The certificate chain was issued by an authority that is not trusted" typically occurs when the client machine doesn't trust the self-signed certificate used by SQL Server. By default, SQL Server 2019 uses a self-signed certificate if no trusted Certificate Authority (CA) certificate is installed.

When connecting with encryption enabled and TrustServerCertificate set to False, the .NET 8 SQL client attempts to validate the certificate chain. Since the self-signed certificate isn't issued by a recognized CA, validation fails and the connection is refused. This is expected behavior in newer client drivers to enforce stricter security.

That said, from my perspective view, in order to resolve and mitigate this issue, you can follow the instruction below:

Option 1: Use TrustServerCertificate=True in the connection string

This option bypasses validation and trusts the certificate as-is, avoiding the error.

string connectionString = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;Encrypt=True;TrustServerCertificate=True;"

Note: This reduces security, as it could expose you to man-in-the-middle attacks in untrusted environments. Avoid in production.

Option 2: Use a certificate signed by a trusted CA
Get a certificate from a trusted CA and install it on the SQL Server. This will avoid trust chain issues.

Option 3 (optional): Install the self-signed certificate's root in Trusted Root Certification Authorities store on the client machine.

**Step 1: Export the Certificate from SQL Server **

On the SQL Server machine (where SQL Server 2019 is installed), open Microsoft Management Console (MMC) by pressing Win+R, typing mmc, and hitting Enter.
In MMC, go to File > Add/Remove Snap-in.
Select Certificates > Add > Computer account > Local computer > Finish > OK.
Expand Certificates (Local Computer) > Personal > Certificates.
Find the self-signed cert used for SQL Server encryption (it should match the one configured in SQL Server Configuration Manager under SQL Server Network Configuration > Protocols for [Instance] > Properties > Certificate tab).
Right-click the cert > All Tasks > Export.
In the wizard: Next > No, do not export the private key > Next > DER encoded binary X.509 (.CER) > Next > Choose a file name/location (e.g., sqlservercert.cer) > Next > Finish.
Transfer this .cer file to your Windows 11 development machine.

Step 2: Import the Certificate on the Client Machine

Run this Powershell cmdlet:

Import-Certificate -FilePath "C:\path\to\sqlservercert.cer" -CertStoreLocation Cert:\LocalMachine\Root

Step 3: Verify and Test

Restart your .NET app (or the process) to ensure it picks up the cert store changes.
Run your code again with the original connection string TrustServerCertificate=False. It should now connect successfully.

This aligns with recent updates in SQL client drivers that default to requiring encryption and certificate validation, unlike older versions which did not validate certificates if encryption was enabled. However, I would like to recommend you try the option 1 and 2 first to see if the issue can be resolved.

All of the methods I’ve shared are based on my own research and testing within my environment. While I hope they’re helpful, I want to be transparent that I can’t guarantee they’ll work exactly the same in your setup, as results may vary depending on different configurations and system environments.

For reference, you may consult the following resource:

I sincerely hope this information partially clarifies your situation and assists you in planning your solution. Please know that while our initial response might not resolve the issue right away, your input is incredibly valuable. With a bit more detail, we’ll work together to find the best solution for you.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

blom buffin 80 Reputation points

2025-09-29T14:49:34.4466667+00:00

Thanks for detail answer, I will try the option 1 first
blom buffin 80 Reputation points

2025-09-29T14:51:35.3033333+00:00

Thank you so much for your efford in collecting the documentation, its very helpful
Anonymous

2025-09-29T14:55:58.1733333+00:00

Hi @blom buffin,

Thank you so much for your kind words! I'm really glad to hear that the documentation was helpful and that you're planning to try Option 1 first. If you run into any issues or have further questions along the way, feel free to reach out. I'm here to help!

Wishing you the best with your next steps!