ASP.NET C# - The client and server cannot communicate, because they do not possess a common algorithm - How to fix it

If you've stumbled upon this post, it probably means that you're struggling against a nasty issue affecting one or more of your Web Application Projects when you publish it to a IIS-based Web Server. The problem consists of the following ASP.NET error message:

System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm.

Such kind of error message usually occurs when the website is not able to match the cryptographic protocol(s) available to the other endpoint - which can be a client or another server depending on your web application's specific scenario. Nine time out of ten, the issue is related to the fact that one of the two endpoints switched to Transport Layer Security (TLS) 1.2, disabling the previous versions: SSL3, TLS 1.0 and/or TLS 1.1... While the other one is not properly configured to support it.

This problem became increasily popular within these last few weeks because a lot of websites and webservices has actually turned down their SSL3 / TLS 1.0 / TLS 1.1 protocol support to comply with the new guidelines published by the PCI SSC (Payment Card Industry Security Standard Council) scheduled for June 30 2018, together with the initial roll-out of the new PCI Data Security Standard v3.2.1 (PCI-DSS 3.2.1): this is a major update that will affect a lot of secure connections, forcing many webmasters and system administrators to upgrade their system as well.

For additional info regarding the TLS cryptographic protocol, PCI-DSS and other security standards, we strongly suggest you to take a look at the Transport Layer Protection Cheat Sheet written by OWASP (Open Web Application Security Project), the most important organization dedicated to the World-Wide Web security. In this article we'll try to address this "common algorythm" issue and try to have it fixed for most Windows / IIS / ASP.NET platforms.

#1: Setup the SecurityProtocol variable

The first thing you have to do is to add the following line of code within your ASP.NET project:

If your .NET Framework version is 4.5 or below, or in case you don't have the "Tls12" typed value, just use the int value instead, which is 3072:

The best spot to insert this line would be the   Application_Start()  method in your Global.asax (ASP.NET 4.x) or Startup.cs (ASP.NET 5 / .NET Core) file, depending on the ASP.NET version used:

Needless to say, if you're dealing with a server-to-server connection between two web applications, you'll have to setup the same SecurityProtocol value on both the machines / servers / applications - the caller and the receiver.

A safer approach

It's very important to understand that, by adding the above line of code, any other SecurityProtocol will be deactivated and thus become unusable: this means that SSL1, SSL2, SSL3, TLS1.0 and TLS1.1 will cease working, as well as any protocols that might be implemented in the future - such as TLS 1.3, TLS 2.0 and so on. For this very reason, if you are interested in maintaining a forward-compatibility of any sort for your project, it could be wiser to implement that same thing in a slightly different way:

This approach is definitely more conservative, as will still deactivate all the insecure protocols without shutting down anything else that might be supported / made available in the near future.

#2: Install .NET Framework 4.6.2+

If the SecurityProtocol property value is not enough to fix your issue, you might try upgrading the .NET Framework installed on your server: that might be a decisive thing to do if you're still with the 3.5, 4.0 or 4.5 version, because TLS 1.2 is natively supported only starting with the 4.6.2 release (and above): that's why Microsoft suggest to upgrade to the .NET Framework 4.7 in their "Transport Layer Security (TLS) best practices with the .NET Framework".

If you're unable (or not allowed) to upgrade to 4.6.2 or 4.7.x, you can still add TLS 1.2 support by installing the TLS 1.2 hot patches (KB3154518, KB3154519, KB3154520 o KB3156421) and/or the TLS 1.2 ASP.NET extension package, valid for .NET Framework versions from 3.5 SP1 to 4.5.

The bad news about all the above steps is that they will require at least Windows 7 (for Desktop systems) or Windows Server 2008 (for Servers): Windows XP, Windows Vista and Windows Server 2003 are not supported and there's currently no way to enable TLS 1.2 for them - not to mention the fact that they don't support .NET Framework versions higher than 4.6.1.

#3: Set the target Framework in the Web.Config file

If #1 and #2 were not enough to fix your issue, it could be due to the fact that your server hosts multiple versions of the .NET Framework - for example, 3.5, 4.0 and 4.5: if that's the case, you could try to force a specific .NET Framework to run your web application using the Web.Config file in the following way:

The "targetFramework" attribute tells IIS which version of the .NET Framework should be used to run the application: be sure to use a version with TLS 1.2 support, such as the 4.6.2 or (even better) the 4.7.

Again, for the reason explained in the previous paragraph, this workaround won't work on Windows Vista, Windows XP and Windows Server 2003, since versions 4.6.2, 4.7.x and higher can't be installed.

#4: Altering the Windows Registry

If none of the above fixes worked, you can try to activate/deactivate the cryptographic protocols directly from the Windows Registry: there's a good guide explaining how to do that in this StackOverflow answer, which also contains the following great script (we slightly modified to disable everything but TLS 1.2):

Before running it, ensure to enable or disable the cryptographic protocols that you wish to support / block by assigning the value of  dword:00000001  (enable) or  dword:00000000  (disable).

That's it for now: we sincerely hope that this post will help many developers who're struggling against this nasty issue!