Detent PointCurrent SQL Server client drivers (Microsoft.Data.SqlClient and recent ODBC/OLE DB drivers) encrypt the connection by default and validate the server’s certificate against a trusted chain. Most SQL Server instances still run on a self-signed certificate that Windows generated automatically and no client trusts. The result is a login-time failure, commonly surfaced as something like “the certificate chain was issued by an authority that is not trusted” during the SSL handshake, even though the instance and login are otherwise fine.
Nothing about the certificate changed. What changed is that the client now checks it, where it used to accept whatever the server handed over. The self-signed cert was always this weak; it just wasn’t being examined before this driver update.
Setting TrustServerCertificate=true on the connection string tells the client to skip certificate chain validation and encrypt anyway. The error disappears because the client stopped checking who signed the certificate, not because the server now has one worth trusting. Encryption in transit still happens; what’s gone is the guarantee that the server on the other end of that encrypted channel is actually the one you meant to connect to, which is the exact property that matters if someone can position themselves between the client and the server (a man-in-the-middle).
For a throwaway local dev connection, that trade is usually fine. On anything a customer or auditor would ask about, it’s worth fixing properly instead.
The real fix is binding a certificate to the instance that traces back to an authority the client already trusts, internal CA or public CA, instead of the auto-generated self-signed one. That’s a registry-level bind for the SQL Server network library, a service restart to pick it up, and ideally a check afterward that the instance actually serves the certificate you just bound instead of trusting that the bind command said it worked.
Done by hand, that sequence has a couple of places to get wrong that won’t show up until a client actually tries to connect: a bind that silently didn’t apply, or a restart against the wrong instance name. SqlCertForge runs the same steps and then checks the served certificate afterward, so a bad bind gets caught instead of discovered later.
SQL Server Reporting Services and Power BI Report Server hit the same self-signed-certificate wall on their own HTTPS endpoint, independent of the database engine’s own binding. SqlCertForge handles both: test_rs_https_endpoint and test_sql_cert_binding are free, read-only checks that tell you what’s bound today on either surface, no license required.