"Keyword Not Supported" and Certificate Trust Errors

Q: Why does my connection string throw "Keyword not supported"?

A library mismatch, not a typo. System.Data.SqlClient (the old provider) and Microsoft.Data.SqlClient (the actively developed successor) don't recognize the same keywords. Newer keywords like TrustServerCertificate exist in Microsoft.Data.SqlClient but throw this error if that same string reaches a System.Data.SqlClient.SqlConnection instead — check which package the exception actually came from rather than stripping the keyword out.

Q: Why does my connection suddenly fail with a certificate trust error after a NuGet update?

Starting with Microsoft.Data.SqlClient 4.0, Encrypt defaults to true (mandatory) — earlier versions defaulted it to false. A connection string with no Encrypt keyword behaved identically for years, then started failing once a NuGet update pulled in 4.0+, because encryption and certificate validation are now attempted by default.

Two different exceptions, thrown at two different points in the connection process, that both start showing up around the same time in a codebase: a "Keyword not supported" ArgumentException before a connection is even attempted, and "The certificate chain was issued by an authority that is not trusted" once one is. Both trace back to the same cause.

reference guide Microsoft.Data.SqlClient SQL Server

// "keyword not supported" — a library mismatch, not a typo

│

System.Data.SqlClient (the old, in-box provider) and Microsoft.Data.SqlClient (the actively developed successor) don't recognize the same connection-string keywords. A handful of newer keywords — TrustServerCertificate, Column Encryption Setting, Attestation Protocol, Enclave Attestation Url among them — exist in Microsoft.Data.SqlClient but throw Keyword not supported: '…' if that exact same connection string reaches a System.Data.SqlClient.SqlConnection instead. This happens more often than it sounds: a connection string built with one provider's SqlConnectionStringBuilder and handed to code still referencing the other, a partially completed migration between the two packages, or a copy-pasted connection string from a newer tutorial landing in an older project.

the same connection string, two providers

the code

var conn = new System.Data.SqlClient.SqlConnection("Server=myserver;Database=Sales;TrustServerCertificate=True;");

what happens

System.ArgumentException: Keyword not supported: 'trustservercertificate'.

the fix

var conn = new Microsoft.Data.SqlClient.SqlConnection("Server=myserver;Database=Sales;TrustServerCertificate=True;");

The fix isn't to remove the keyword — it's to check which package the exception actually came from. Microsoft.Data.SqlClient has been the Microsoft-recommended provider since System.Data.SqlClient was put into maintenance-only mode; if a project still references the old package anywhere, that's almost always the real fix, not stripping keywords out of the connection string.

// the certificate error — a default that changed under you

│

Starting with Microsoft.Data.SqlClient 4.0, the Encrypt setting defaults to true (mandatory) — earlier versions, and the old System.Data.SqlClient, defaulted it to false. A connection string with no Encrypt keyword at all behaved identically for years, then started failing the moment a NuGet update pulled in 4.0 or later, because encryption is now attempted by default and the client validates the server's certificate as part of that.

Most SQL Server instances outside of Azure use a self-signed certificate, which fails validation by design — that's what "the certificate chain was issued by an authority that is not trusted" means. It isn't a sign anything is actually broken on the server; it's the new default doing exactly what it's supposed to do against a certificate nothing has told the client to trust.

the same connection string, before and after 4.0

the code — unchanged across the upgrade

var conn = new SqlConnection("Server=myserver;Database=Sales;User Id=app;Password=***;");

what happens on Microsoft.Data.SqlClient 4.0+

System.Data.SqlClient.SqlException: A connection was successfully established with the server, but then an error occurred during the login process. The certificate chain was issued by an authority that is not trusted.

the fix

var conn = new SqlConnection("Server=myserver;Database=Sales;User Id=app;Password=***;TrustServerCertificate=True;");

the three real options, in order of preference

Install a real, CA-trusted certificate on the SQL Server instanceThe only option that gets you encryption and certificate validation, as intended. Azure SQL Database already has one — this only applies to self-hosted SQL Server.

Encrypt=True;TrustServerCertificate=TrueKeeps the connection encrypted, skips validating who signed the certificate. Reasonable for internal networks and local dev where you control both ends.

Encrypt=FalseTurns encryption off entirely, reverting to the old default. Fine for a local database on localhost; avoid it for anything crossing a real network.

// build it correctly the first time

│

The Connection String Builder sets Encrypt and TrustServerCertificate explicitly and flags the combinations that commonly cause exactly these two errors, so the string it produces doesn't depend on whichever default happens to ship in whatever package version gets restored next.

// frequently asked questions

Why does my connection string throw "Keyword not supported"?

A library mismatch, not a typo. System.Data.SqlClient (the old provider) and Microsoft.Data.SqlClient (the actively developed successor) don't recognize the same keywords. Newer keywords like TrustServerCertificate exist in Microsoft.Data.SqlClient but throw this error if that same string reaches a System.Data.SqlClient.SqlConnection instead — check which package the exception actually came from rather than stripping the keyword out.

Why does my connection suddenly fail with a certificate trust error after a NuGet update?

Starting with Microsoft.Data.SqlClient 4.0, Encrypt defaults to true (mandatory) — earlier versions defaulted it to false. A connection string with no Encrypt keyword behaved identically for years, then started failing once a NuGet update pulled in 4.0+, because encryption and certificate validation are now attempted by default.

What does "certificate chain was issued by an authority that is not trusted" mean?

Most SQL Server instances outside of Azure use a self-signed certificate, which fails validation by design. It isn't a sign anything is broken on the server — it's the Encrypt=true default doing exactly what it's supposed to do against a certificate nothing has told the client to trust.

How do I fix a SQL Server certificate trust error?

Three options in order of preference: install a real, CA-trusted certificate on the SQL Server instance (the only option that gets you both encryption and validation); use Encrypt=True;TrustServerCertificate=True to stay encrypted while skipping certificate validation, reasonable for internal networks and local dev; or set Encrypt=False to revert to the old behavior entirely, fine for localhost only.