A colleague asked for help with the following problem:
He has an ASP.NET MVC website that talks to an ASP.NET Web API backend. On development everything works as expected but on the acceptance environment, he suddenly start to get TLS errors when the httpclient invokes a call to the backend:
The request was aborted: Could not create SSL/TLS secure channel.
Let’s take you through the journey that brought us to our final solution.
Part 2 – The unexpected .NET Framework update(again).
As mentioned in Part 1, the problem started to appear after a rollout of .NET Framework 4.6. Now what made it even stranger is that we didn’t saw the issue on our production environment. So why didn’t it work on our acceptance environment and did it work on our production environment?
Turned out that on our production enviroment another .NET Framework update was executed and that the behavior of the HttpClient changed (again):
From the documentation:
Default operating system support for TLS protocols*
The TLS stack, which is used by System.Net.Security.SslStream and up-stack components such as HTTP, FTP, and SMTP, allows developers to use the default TLS protocols supported by the operating system. Developers need no longer hard-code a TLS version.
This explained why it worked on production where the HttpClient no longer used TLS1.2 by default but falls back to the OS default.
But wait, we are still using an older procotol, can’t we change this? This is a question we’ll answer in our third and final post…