0

We Have a MVC Application and a Windows Forms Application that targets following Frameworks

MVC Application

enter image description here

Winforms

enter image description here

recently we disabled the TLS 1.1 and TLS 1.0 on all server and client machines.

After this change both applications stopped working and we noticed MVC application had an incorrect runtime specified in the web.config after the upgrade. So we made the following change the to the MVC app in order to get it to work.

taget framework from 4.5 to

enter image description here

Now the MVC application works as expected but the windows forms client does not

it throws the following exception.

"The underlying connection was closed: An unexpected error occurred on a receive."

according to the following POST we don't have to do anything since the windows application is already running on 4.6.2.

or do we have to hard-code the protocol as mention in one of the answers?

The client and server cannot communicate, because they do not possess a common algorithm - ASP.NET C# IIS TLS - System.ComponentModel.Win32Exception

Appreciate if someone can let us know what needs to be changed in the Windows application for it to work with TLS 1.2. Or though it's says 4.6.2 can it be targeting a different runtime. like the MVC application?

Update:

When we Run the WinForms Application through Visual Studio the and display ServicePointManager.SecurityProtocol it shows it as System.Default.

But when it's deployed the ServicePointManager.SecurityProtocol shows as its using ssl3

  • Are you running this on Windows7, Windows Server 2008 RC? Anyway, to make use of the automatic protocol selection features (OS choice) provided by the Framework, I suggest to target .`NET Framework 4.7+` everywhere. If you use one of the Systems mentioned, you have to explicitly set TLS12, unless you tweak the Registry. Windows 8 and Windows 10 default to TLS 1.2 – Jimi Sep 23 '20 at 00:34
  • 1
    https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-security-via-appcontext-switches – Daniel A. White Sep 23 '20 at 00:34
  • it's running on Windows 2016, it's a sort of a big application upgrade to 4.7 can get tricky, is there a quick fix for this. – Asela Gunwardena Sep 23 '20 at 00:36
  • 2
    What do you get back if you read `ServicePointManager.SecurityProtocol` at run-time? Have you tried to set `ServicePointManager.SecurityProtocol = SecurityProtocolType.SystemDefault`?. IIRC, 4.6 enables all protocols, while 4.7+ use `SystemDefault`. Have you tried to set TLS12 explicitly? Take [IIS Crypto](https://www.nartac.com/Products/IISCrypto/) and verify your machine's settings. See also [SSL Server Test](https://www.ssllabs.com/ssltest/analyze.html) (if it can be reached from *outside*) – Jimi Sep 23 '20 at 00:45
  • 1
    I'd also check (since it's a *big application*), if someone has hard-coded a `SecurityProtocol` version somewhere. – Jimi Sep 23 '20 at 00:57
  • when read the Value we get SystemDefault, and this error happens when the applications are trying to communicate with the STS, and we can talk to the STS with POST man and successfully obtain tokens. – Asela Gunwardena Sep 23 '20 at 01:18
  • I ran into the similar problem with a winforms app, but only when targeting our dotnet 5 webspi in Azure. When running against localhost, it worked fine. I had to add the app.config setting for Switch.System... to make it work. Weird. – Johan Danforth Mar 19 '21 at 07:30

1 Answers1

1

Solved the Issue

Problem was we had the following setting in the .config file of the Windows Application. value="Switch.System.Net.DontEnableSchUseStrongCrypto=true" after setting it to false no changes we required everything worked like Magic.

why it worked in VS but not in production? because, the setting was injected into the app.config by the production build pipeline.

Thanks everyone who commented all these comments helped!