We got a pleasant surprise when one of our clients reported to us that the application was no longer. In this case, it had a .NET DLL that called Azure service. The code was very straightforward; just reference a nuget package provided by Microsoft and call methods on it and it just works™.
Few months ago, we got email announcement that Azure would stop supporting TLS 1.0 and TLS 1.1. We make sure that our web applications and other resources aren’t explicitly using TLS 1.0 and TLS 1.1. This DLL does not have any options or settings that would change the version of TLS being used so we didn’t consider it as impacted.
Then Azure pulled the plug on TLS 1.0/1.1.
Now the customer cannot use the application because apparently that DLL using Microsoft-provided nuget package is using TLS 1.0/1.1. Argh. It turns out that the decision whether to use TLS 1.0/1.1 may come further below than what our code may be doing. In fact, it may be the .NET framework that makes the decision to use TLS 1.0/1.1 even though it’s running on a Windows that already has TLS 1.2 supported.
So how do we get framework to use TLS 1.2. I imagine updating it might do the trick but that’s pretty complicated since we are targeting .NET framework 4.5 so that it can run on a variety of computers. It turns out that to make the framework use TLS 1.2, we need to make some registry changes to tell framework to use the latest version of TLS. Once we executed the registry script, the customer was back in business.
For those in the same boat, here’s the registry script:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001 "SystemDefaultTlsVersions"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001 "SystemDefaultTlsVersions"=dword:00000001
For those needing more details, this is a good reference.
