The error “SSL Provider: The certificate chain was issued by an untrusted authority” occurs when Excel, Power Query, or an external SQL client establishes an encrypted TLS handshake with Microsoft SQL Server, but the client computer cannot validate the server’s security certificate against its trusted root certification authority store.
Quick Answer
To solve “The certificate chain was issued by an untrusted authority,” append
TrustServerCertificate=True;to your SQL connection string or select Trust server certificate in Power Query. For corporate production systems, export the SQL Server’s root CA certificate and import it into the Windows Trusted Root Certification Authorities store on the client machine.
Why Modern SQL Connections Trigger This Error
Earlier database drivers (such as legacy SQLOLEDB or SQLNCLI) defaulted to unencrypted connections unless explicitly instructed to encrypt. Modern drivers—including ODBC Driver 18 for SQL Server and Microsoft OLE DB Driver 19/20 for SQL Server (MSOLEDBSQL)—flipped this default behavior. They enforce Encrypt=Mandatory (or Encrypt=True) by default.
When SQL Server starts up without a commercially purchased or domain-signed certificate, it automatically generates a self-signed certificate to handle transport encryption. Because a self-signed certificate has no parent chain leading back to a known public or enterprise Root CA in the client’s local Windows Certificate Manager, the client’s cryptographic provider terminates the connection immediately to protect against man-in-the-middle attacks.
To understand overarching connection failure hierarchies, consult Troubleshooting SQL Connection Failures: Fixing ODBC and Provider Errors.
Practical Diagnostic and Resolution Steps
Method 1: Enable TrustServerCertificate in Excel and Power Query
If you are operating on a secure internal intranet, development environment, or private subnet, you can instruct the client driver to accept the server’s certificate without validating the root chain.
In Power Query / Get & Transform Data:
- In Excel, go to Data > Get Data > From Database > From SQL Server Database.
- Enter your Server and Database name.
- If prompted with an encryption warning dialog stating: “We couldn’t authenticate with the credentials provided” or showing an untrusted certificate alert, look for the connection options.
- Click Advanced options or check the box labeled Trust server certificate (or set Encrypt connection to disabled if available).
- Click Connect.
In Existing Workbook Connection Strings:
- Go to Data > Queries & Connections.
- Right-click the broken query > Properties > Definition.
- In the Connection String field, append the following parameter before the final semicolon:
TrustServerCertificate=True; - If the string explicitly declares
Encrypt=Yes;orEncrypt=Mandatory;, leave it intact and simply ensureTrustServerCertificate=True;is present. - Click OK.
In VBA ADODB Code:
Dim conn As Object
Set conn = CreateObject("ADODB.Connection")
' Append TrustServerCertificate=True to bypass certificate validation
conn.ConnectionString = "Provider=MSOLEDBSQL;" & _
"Data Source=sqlprod01.corp.local;" & _
"Initial Catalog=FinancialReports;" & _
"Integrated Security=SSPI;" & _
"Encrypt=True;" & _
"TrustServerCertificate=True;"
conn.Open
Method 2: Import the Certificate to the Windows Certificate Store
For enterprise environments where corporate security policies forbid disabling certificate verification (TrustServerCertificate=False), the server’s root signing certificate must be trusted by the local machine.
- Obtain the public root certificate (
.ceror.crtfile) from your database administrator or export it from the SQL Server machine. - On the client machine, press Windows Key + R, type
certmgr.msc, and press Enter. - Expand the Trusted Root Certification Authorities folder in the left pane.
- Right-click the Certificates subfolder > All Tasks > Import….
- Select the exported certificate file and complete the wizard, placing it into the Trusted Root Certification Authorities store.
- Restart Excel and reconnect. The client will now successfully validate the chain.
Diagnostic Checkpoints: What If the Connection Still Fails?
If adding TrustServerCertificate=True fails or yields a new error message, follow this diagnostic progression:
- Protocol Version Mismatches: If the server is running an older OS version (such as Windows Server 2012) using TLS 1.0/1.1, and the client machine enforces TLS 1.2 or TLS 1.3, the SSL provider will fail during the cryptographic handshake. See How to resolve “Encryption mismatch” between Excel and legacy SQL Server versions..
- Missing or Outdated Driver Libraries: If updating connection string flags causes the driver to stop responding entirely, verify that you are using a modern supported driver rather than a missing legacy component. Refer to Fixing “The provider ‘SQLNCLI11’ is not registered” on 64-bit systems..
- Cloud Database Endpoint Restrictions: When resolving certificate issues against cloud hosts such as Azure SQL, passing the SSL barrier often reveals underlying network or authorization blocks. If your next prompt returns a 403 or network boundary rejection, see Handling “Access to the resource is forbidden” in Azure SQL Database links..