12

There are numerous posts on SO about this and I have scoured them, but still don't have a solution. I am hoping that someone can point me in the right direction.

We have a requirement now to use TLS 1.2 to connect to a remote provider. So I have installed Windows Server 2016 and configured it as needed:

enter image description here enter image description here

I know the remote server is running TLS 1.2 and that it supports the highlighted cipher.

We connect to the remote end point using C# proxy class generated by the WSDL provided by the provider - before they converted their end to TLS (System.Web.Services.Protocols.SoapHttpClientProtocol).

When I connect using the proxy I get an exception with the inner exception being "The client and server cannot communicate, because they do not possess a common algorithm".

I cannot see anywhere that ServicePointManager.SecurityProtocol so I am assuming .NET is picking up TLS 1.2 as it is the only enabled protocol? No idea how it is doing the cipher.

Can someone tell me how I go about attempting to fix this? If possible I don't want to regenerate the WSDL proxy class.

TheEdge
  • 9,291
  • 15
  • 67
  • 135
  • 2
    What version of .NET framework are you running on? How is your app configured? What do you mean by "I cannot see anywhere that ServicePointManager.SecurityProtocol"? This is all crucial for TLS 1.2 support: http://stackoverflow.com/questions/28286086/default-securityprotocol-in-net-4-5/28502562#28502562 – Simon Mourier Mar 01 '17 at 06:31

2 Answers2

30

If your client application was compiled against .NET Framework 4.5.2 or lower, then by default ServicePointManager.SecurityProtocol is initialized to SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls (SSL 3.0 and TLS 1.0 only), so it won't be able to connect to a remote server that requires TLS 1.2.

There are several ways to allow your client application to use TLS 1.2:

  • Recompile your client application against .NET Framework 4.6 or later. (In Visual Studio, open your project's property pages, go to the Application tab, and change the Target Framework.)
  • On the client machine, run RegEdit.exe, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ .NETFramework\v4.0.30319, add a DWORD (32-bit) value named SchUseStrongCrypto, and set it to 1. (This flag causes ServicePointManager.SecurityProtocol to be initialized to Tls | Tls11 | Tls12.)
  • When your client application starts up, turn on TLS 1.2: ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

There's no need to regenerate your proxy class because it's not responsible for negotiating the TLS protocol or cipher.

Michael Liu
  • 52,147
  • 13
  • 117
  • 150
  • Perfect @Michael. I had already changed to compile against 4.6.1, but also then realised that I had to change the httpRuntime targetFramework to be 4.6.1 as the connection was ultimately being made by WebApi which I believe obviates the registry change? Doing the httpRuntime change made the connection TLS 1.2. – TheEdge Mar 08 '17 at 00:13
  • @MichaelLiu i have done all this but still my sslStream fails. is there anything specific for SSLstream i need to update? – Peru Apr 04 '18 at 00:23
  • Is there a way to do this via web/app config file instead? – ullfindsmit Apr 02 '19 at 11:25
  • 1
    @Peru, regarding SslStream, "Applications that are using the `SslStream AuthenticateAsClient(String, X509CertificateCollection, SslProtocols, Boolean)` overload can set the `SslProtocols` value as..." `(SslProtocols)0x00000C00` according to . – Mike Henry Sep 10 '19 at 23:52
  • For me, the line `ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;` was also the solution for my VSTO AddIn (Excel), which wasn't connecting with `Microsoft.Identity.Client` to Azure AD any more. – gridr Jul 29 '22 at 07:17
1

I had this issue removing TLS 1.0 from a website that was connecting to a web service. For me it was a httpRuntime that was stuck on 4.5.1 in web.config of the web service. The service was changed to 4.6.1, changing the version of httpRuntime in the web.config to 4.6.1 fixed the issue. The web site tried to set up TLS to the webservice and only has 1.2 and 1.1 available. The web service only supported 1.0 so that caused the error.