"Keyword Not Supported" and Certificate Trust Errors

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