After move to dotnet core 2.2 on Linux, connecting to our Azure SQL database often throws pre-login handshake error

Question

Last week we migrated our production environment from .NET Framework 4.6.2 to .NET Core 2.2. Everything works as expected except we now often get the following error when we connect to the database:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31 - Encryption(ssl/tls) handshake failed)
   at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling)
   at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
   at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)
   at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.Open()

Our production environment used to run on a Windows 32 bit App Service plan in Azure. In this environment we almost never had any issues with pre-login handshakes.

Now suddenly after we've moved to Linux 64 bit containers, these errors start to pop up a few times a day.

I've searched the internet for a solution, but I cannot find it. Does anyone have an idea of what we should do?

This is our connection string:

Server=tcp:{server_url},1433;Data Source={server_url};Initial Catalog={database};Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Max Pool Size=500;

EDIT: Just to be clear: most of the connections to the SQL database succeed. We have many users on our server. However, the amount of unsuccessful connections has increased significantly.

Answer 1

Finally I found out what was going on. We were leaking connections in another piece of code (and to another server). The responses were not disposed correctly. Since the allowed amount of open connections was smaller in Linux, we ran into this problem more quickly.

It's too bad the exception message is so ambiguous, but I can understand that it's difficult to raise a less ambiguous exception.

Anyway, for people looking for an answer to the same problem: do a "netstat -an" on your server when you run into this issue and check whether you're not looking connections.