Most “the site died after deploy” tickets we open on Windows hosts are not ANCM, not the app pool identity, and not a bad Web Deploy package. They are a SqlException about the certificate chain or SSL Provider error 0 that appeared the moment someone bumped Microsoft.Data.SqlClient—or swapped System.Data.SqlClient for it—and pushed.

Newer Microsoft.Data.SqlClient builds default Encrypt to on. Old connection strings that never mentioned Encrypt inherited the previous “off unless you asked” behavior. The driver did not break. Your silent default did.

#What fails on IIS-hosted apps

ASP.NET Core and EF Core 10 apps on IIS talk to SQL Server through the app pool worker. Traffic often stays on one box or a private network. SQL is commonly installed with a self-signed cert, a hostname that does not match the Server= value, or Force Encryption left inconsistent with what the client now demands. Monday morning the site throws; Friday’s package diff looks harmless.

We also see the opposite mess: someone pastes TrustServerCertificate=True into every environment to “make it work,” ships that string to production, and never revisits TLS. That is not a fix. It is a permanent disable of the check the driver just started enforcing.

#Set Encrypt on purpose

Put Encrypt in the connection string explicitly so the next NuGet bump cannot surprise you. Prefer a real server certificate whose CN/SAN matches the host name you connect with. If you must connect by a name that differs from the cert, use HostNameInCertificate instead of turning validation off. Reserve TrustServerCertificate=True for short-lived local debugging only.

json
{
  "ConnectionStrings": {
    "AppDb": "Server=sql.internal,1433;Database=AppDb;User ID=app_user;Password=***;Encrypt=True;HostNameInCertificate=sql.internal;Application Name=MySite"
  }
}

If the path truly never leaves a locked-down host and you are accepting cleartext on purpose, set Encrypt=False in the string and document why. Do not leave Encrypt omitted. Omitted is how last quarter’s working site becomes this quarter’s outage after a routine package update.

Before the deploy window, exercise the exact connection string under the app pool identity against the same SQL endpoint the site uses. A console smoke test on your laptop with a different driver default proves nothing about w3wp on the server.