Allow using TLSv1.1 on Arch

I'm a dotnet 7 developer and I need my apps to connect to MS SQL <= 2016 databases (compatibility level 110), where the maximum supported TLS version is 1.1. I don't have control over the database servers so they won't get updated any time soon.

I have multiple installations which were all modified by adding the env var CLR_OPENSSL_VERSION_OVERRIDE=1.1 and they all work fine, except for one.

I have 4 machines:

a bare metal arch (personal machine, few years old, connecting via VPN)
a bare metal windows 11 (that I use the least possible)
an ubuntu VM (which I would like to delete and replace with arch)
an arch VM (few weeks old, which I would like to use as my daily driver when I'm at work)

Both VM's are hosted on the Win11 machine with VMWare Workstation.

They can all connect to the SQL server without problem, except dotnet ef dbcontext scaffold and dotnet run on the arch VM. However on this arch VM I can connect to the databases with Azure Data Studio without any problem.

The error message in dotnet that I get on the arch VM is:

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)

The arch VM can connect to more recent MSSQL servers without problem.

Both arch installs have these packets installed: openssl, openssl-1.0, openssl-1.1. Both arch installs have the env var CLR_OPENSSL_VERSION_OVERRIDE=1.1 exported. Both arch installs have the exact same /etc/ssl/openssl.cnf file, which is the standard file with the line activate = 1 uncommented below [default_sect]. Both arch installs have the same ca-certificates installed and sudo update-ca-trust extract was run. I mounted the / of the bare metal arch into the arch VM and used meld to manually check for differences in each and every folder / file of /etc and the dotfiles in my home directories. I did a dump of all installed packages on both arch machines and diffed them to find any ssl-related package differences, but I did not see anything useful.

I tried comparing outputs of which openssl and openssl version -a on both arch machines => no difference.

I went through the history file of the working arch machine around the time when the problem first appeared on it and I was able to solve it by adding the env var export in /etc/.profile, to try and refresh my mind of any other manipulation I did, but I didn't find anything more.

journalctl only tells me there was a core dump on my dotnet application.

I am able to generate the same error on my other linux installs, and also in the arch VM's azure data studio, by clearing the env var CLR_OPENSSL_VERSION_OVERRIDE.

My dotnet projects use an .env file so I tried adding CLR_OPENSSL_VERSION_OVERRIDE=1.1 to it, unsuccessfully.

I checked multiple times for stupid typo mistakes that are often easily overseen.

I even tried decribing the issue to Chat GPT, but it wasn't helpful.

What am I missing? How can I investigate deeper and/or circumvent this annoyance?

Solution

I solved it be replacing the packages dotnet-host dotnet-runtime dotnet-sdk dotnet-targeting-pack aspnet-runtime with the binary versions (dotnet-host-bin dotnet-runtime-bin dotnet-sdk-bin dotnet-targeting-pack-bin aspnet-runtime-bin)