Why does adding httpRuntime targetFramework in Web.config file in a WCF application resolving TLS related connectivity issue?

Question

We have a few ASP.NET and WCF applications that are continuously being migrated to latest .net framework version as it is being released. This migration was working fine until we reached .NET Framework 4.6.2 and since then we started seeing TLS connectivity error like below. When I added <httpRuntime targetFramework="4.6.2" /> under <system.web> in the Web.config file, the error disappeared. So as I understand, this setting is forcing the application to run under .NET Framework 4.6.2 (without this, I believe the application was running under .NET Framework 4.0), which is causing it to use underlying Operating System's default protocol for securing the connection. Please correct my understanding if I am missing something.

System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult) at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar) --- End of inner exception stack trace ---

Novercal

Answer 1

Have a look at this: https://blogs.perficient.com/2016/04/28/tsl-1-2-and-net-support. TLS 1.2 is default for .NET 4.6 and above, supported but not default for 4.5 and not well supported for 4.0 and lower.

Perhaps either one of your application updates, an IIS or OS config change had disabled TLS versions < 1.2 and the client applications were unable to connect.

As for setting <httpRuntime targetFramework="4.6.2" />, we found the same thing. Changing the target framework in the project file and the targetFramework value in the compilation element were not enough. It still retained < .NET 4.6 behaviour for TLS. In fact when changing the target framework, Visual Studio added the httpRuntime element to the web.config in a commented out block.

(The recommended answer here is also helpful: What do the TargetFramework settings mean in web.config in ASP .NET MVC?)

Whippoorwill