Microsoft SQL Server, Error: 10054 on Linux RHEL (CentOS 8)
The Problem
After installing SQL Server 2019 on a Linux RHEL (CentOS 8) virtual machine, I was unable to reliably connect to the server, even when I was able to connect the connection would be lost after it was alive for ~1 minute.
One of the following error messages would be thrown by the server:
An error occurred while receiving data: '10054 (An existing connection was forcibly closed by the remote host.)'.
OR
A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
The problem seemed to be a TLS versioning mismatch. SQL Server uses OpenSSL 1.0.0 on RHEL, but CentOS 8 has OpenSSL 1.1.1 installed on a fresh installation. This causes incompatibility in the support for SHA-1 signatures, which SQL Server requires.
This is a known issue with SQL Server on Debian, but nobody at the time of writing this seemed to have a solution for this issue on CentOS 8.
The Solution
This issue can be solved in two ways:
- An easy workaround, which downgrades the crypto-policy of CentOS to support deprecated cypher methods. Because this lowers the security of your OS I can't recommend applying this solution in a production environment.
- Upgrading the security certificate of SQL Server, which takes more time but can be considered as a production-ready solution.
Option 1: Downgrading the security policy of CentOS
To downgrade the security policy of CentOS 8 to support deprecated algorithms we can use the built-in command in the OS:
update-crypto-policies --set LEGACY
After executing this command you'll have to reboot the system to apply the changes.
Because of this change, SQL Server will be able to use the SHA-1 algorithm once again and the error will be gone.
If you ever want to revert the crypto-policy back to its original state you can run:
update-crypto-policies --set DEFAULT
Option 2: Upgrading the SQL Server security certificate
Microsoft has quite good documentation on how to create a secure certificate and update the security protocol of SQL Server. Disclaimer: Only use a self-signed certificate in non-production environments in all other scenarios you should use a CA certificate to improve the security of your server.