When I first started out with WSL I tried to install the Azure CLI. Strangely I kept having TLS handshake errors while trying to install the microsoft package repository private key. As a workaround I used the macOS package manager Brew instead. This solved my immediate problem but over the next few weeks I kept having to perform certain actions in Windows instead of in WSL because on some domains I would have TLS handshake issues and on others I would not. This was getting ridiculous. Eventually I realized I did not have this problem when not connected to my corporate VPN! With this knowledge I started looking for a solution and soon enough I found this GitHub issue. After reading plenty of comments I found the solution here.
The problem is likely that the MTU (maximum single packet size) set by your VPN operator is not the default 1500 of Ethernet, while the default of the WSL network interface is set to 1500. This causes packets from your WSL distro to be larger than the maximum allowed by your VPN. This causes your VPN network adapter to drop/lose/block some of your packets or parts of the packets. This malforms the TLS traffic which causes a failed handshake. Fix the MTU value of the WSL network adapter and your should be good to go. To fix this:
TLDR;
In windows find out what the MTU value is of your VPN network adapter by opening PowerShell as Administrator:
netsh.exe interface ipv4 show interfaces
The result should look a little something like this:
From this list pick your VPN and look at the MTU column to find the MTU value. In my case the MTU is 1400.
Now in your WSL open your ~/.profile or ~/.zprofile (or whichever shell dotfile you prefer in your system) and add the following line:
sudo ip link set dev eth0 mtu 1400
And there you go, no more TLS handshake errors!
Info
If you still have TLS handshake errors or if you’re experiencing other networking issues, try the suggestions in this blog post by Baruch Odem. I did not need this but perhaps it is useful to you.