95

I have an issue with a C# PayTrace Gateway. The below code was working fine until yesterday when I believe they turned off SSL3 due to the Poodle Exploit. When running the code below we got the following message. The remote server has forcefully closed the connection. After doing some research on the problem we determined that because our IIS Server 7.5 was configured to still use SSL3, C# defaulted to SSL3, which PayTrace would forcibly close the connection. We then removed SSL3 from the server. Which then lead to the following error:

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

My guess is that there are additional SSL algorithm we need to install on the server now that SSL 3 is removed. Our IT staff claims that TLS 1.1 and TLS 1.2 are working and that ASP.NET should be now defaulting to those. But I feel like there still must be something else we need to install on the server, I have no knowledge of SSL Algorithms so I have no idea where to begin.

var postUrl = new StringBuilder();

//Initialize url with configuration and parameter values...
postUrl.AppendFormat("UN~{0}|", this.MerchantLoginID);
postUrl.AppendFormat("PSWD~{0}|", this.MerchantTransactionKey);
postUrl.Append("TERMS~Y|METHOD~ProcessTranx|TRANXTYPE~Sale|"); 
postUrl.AppendFormat("CC~{0}|", cardNumber);
postUrl.AppendFormat("EXPMNTH~{0}|", expirationMonth.PadLeft(2, '0'));
postUrl.AppendFormat("EXPYR~{0}|", expirationYear);
postUrl.AppendFormat("AMOUNT~{0}|", transactionAmount);
postUrl.AppendFormat("BADDRESS~{0}|", this.AddressLine1);
postUrl.AppendFormat("BADDRESS2~{0}|", this.AddressLine2);
postUrl.AppendFormat("BCITY~{0}|", this.City);
postUrl.AppendFormat("BSTATE~{0}|", this.State);
postUrl.AppendFormat("BZIP~{0}|", this.Zip);
postUrl.AppendFormat("SADDRESS~{0}|", this.AddressLine1);
postUrl.AppendFormat("SADDRESS2~{0}|", this.AddressLine2);
postUrl.AppendFormat("SCITY~{0}|", this.City);
postUrl.AppendFormat("SSTATE~{0}|", this.State);
postUrl.AppendFormat("SZIP~{0}|", this.Zip);
if (!String.IsNullOrEmpty(this.Country))
{
    postUrl.AppendFormat("BCOUNTRY~{0}|", this.Country);
}
if (!String.IsNullOrEmpty(this.Description))
{
    postUrl.AppendFormat("DESCRIPTION~{0}|", this.Description);
}
if (!String.IsNullOrEmpty(this.InvoiceNumber))
{
    postUrl.AppendFormat("INVOICE~{0}|", this.InvoiceNumber);
}
if (this.IsTestMode)
{
    postUrl.AppendFormat("TEST~Y|");
}

//postUrl.Append();

WebClient wClient = new WebClient();
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
String sRequest = "PARMLIST=" + Url.Encode(postUrl.ToString());
wClient.Headers.Add("Content-Type", "application/x-www-form-urlencoded");
string sResponse = "";
sResponse = wClient.UploadString(PayTraceUrl, sRequest);

Also, just an FYI, this issue is also happening when we connect to First Data E4 gateway so it's not just a PayTrace thing. My guess is that as more gateways turn off access to SSL3 we'll continue to run into issues with other gateways until this can be resolved on the server. Also, I did find a few suggestions online, some suggested placing the following code right before making the outbound request:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

Unfortunately that did not work either, same error. Which is why I'm thinking something additional needs to be installed on the IIS7.5 server. I'm just not sure what.

TroySteven
  • 4,885
  • 4
  • 32
  • 50

16 Answers16

131

There are several other posts about this now and they all point to enabling TLS 1.2. Anything less is unsafe.

You can do this in .NET 3.5 with a patch.
You can do this in .NET 4.0 and 4.5 with a single line of code

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; // .NET 4.5
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; // .NET 4.0

In .NET 4.6, it automatically uses TLS 1.2.

See here for more details: .NET support for TLS.

Marcos Dimitrio
  • 6,651
  • 5
  • 38
  • 62
Paul
  • 2,330
  • 2
  • 19
  • 18
  • 12
    @NRW put it wherever your application starts. This is a global value - put it in Global.asax in the Application_Start() event. – Paul May 25 '17 at 19:06
  • 8
    FWIW, even on 4.6.1, I had to include this line `ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12` – eat-sleep-code Jun 27 '17 at 19:39
  • 3
    I added the line mentioned above, but still get the same error. I added it in the Global.asax as the first line of the code inside Application_Start(). – messed-up Apr 09 '18 at 15:24
  • 2
    Problem with my app was that one of the database servers was not up to date with the update. So, connecting to database failed from the app server. – messed-up Apr 09 '18 at 15:46
  • @NRW, in the service I put it in void Main() (which I had to add). On the web site side, it works in Global.asax.cs as mentioned by messed-up. – Tom Cerul Oct 03 '18 at 13:28
  • Changed Answer to this one as it most accurately answers the question. – TroySteven Jan 28 '19 at 21:04
  • 1
    Does that mean if I upgrade the project to .Net 4.7 from 4.5, there is no coding change required? Just redeployment? – Xiao Han Feb 08 '19 at 16:45
  • 1
    FYI I have experienced some projects still require the explicit TLS declaration. It may be prudent to put it back if you experience any problems. – Paul Mar 06 '19 at 14:03
27

In my case, even though Target Framework of Project was 4.7.1, I was still getting same Error, Solution was to change httpRuntime in web.config under system.web to 4.7.1!

pk_code
  • 2,608
  • 1
  • 29
  • 33
  • Yes, I've learned that changing the versions to 4.6.X and higher auto-negotiates to the highest version of TLS. TLS 1.2 or TLS 1.3 if you have it installed. So no code change is required which is nice if you are able to easily upgrade. – TroySteven Nov 26 '18 at 22:01
  • Your suggestion solved my issue.. thank you! – MarwaAhmad Mar 24 '22 at 12:29
19

In a previous answer, it was suggested to use this line of code for .Net 4.5:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; // .NET 4.5

I would encourage you to OR that value in to whatever the existing values are like this:

ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12; // .NET 4.5

If you look at the list of values, you notice that they are a power of two. This way, in the future when things shift to TLS 2.0 for example, your code will still work.

  • Would that enable you to continue using unsafe protocols as well? – Paul Aug 28 '18 at 13:21
  • 1
    @Paul yes. I would reccomend upgrading to .net 4.6.2, which case you do not need this line - it will decide the correct TLS version for you. – Almenon Oct 26 '18 at 02:16
  • 1
    Somewhat pedantic, but `SecurityProtocolType.Tls12` is defined as the constant `3072` which is **not** a power of two. For some reason, all the values in that enum are values such that two consecutive bits are set (192, 768, 3072). – Nick Jan 30 '20 at 19:01
  • You might also want to remove the older versions. See this article for a code example. https://www.ryadel.com/en/asp-net-client-server-cannot-comunicate-because-they-possess-common-algorithm-how-to-fix-c-sharp/ – Johan Bergens Aug 24 '22 at 10:03
11

My app is running in .net 4.7.2. Simplest solution was to add this to the config:

  <system.web>
    <httpRuntime targetFramework="4.7.2"/>
  </system.web>
suttonb1
  • 193
  • 2
  • 8
9

There are two possible scenario, in my case I used 2nd point.

  1. If you are facing this issue in production environment and you can easily deploy new code to the production then you can use of below solution.

    You can add below line of code before making api call,

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; // .NET 4.5

  2. If you cannot deploy new code and you want to resolve with the same code which is present in the production, then this issue can be done by changing some configuration setting file. You can add either of one in your config file.

<runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false"/>
  </runtime>

or

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
</runtime>
Sagar Borole
  • 371
  • 4
  • 8
7

This was resolved. It turns out our IT Staff was correct. Both TLS 1.1 and TLS 1.2 were installed on the server. However, the issue was that our sites are running as ASP.NET 4.0 and you have to have ASP.NET 4.5 to run TLS 1.1 or TLS 1.2. So, to resolve the issue, our IT Staff had to re-enable TLS 1.0 to allow a connection with PayTrace.

So in short, the error message, "the client and server cannot communicate, because they do not possess a common algorithm", was caused because there was no SSL Protocol available on the server to communicate with PayTrace's servers.

UPDATE: Please do not enable TLS 1.0 on your servers, this was a temporary fix and is not longer applicable since there are now better work-arounds that ensure strong security practices. Please see accepted answer for a solution.

miken32
  • 42,008
  • 16
  • 111
  • 154
TroySteven
  • 4,885
  • 4
  • 32
  • 50
  • 10
    But enabling TLS 1.0 is not recommended, and forbidden for PCI compliance. – Keith Oct 28 '16 at 03:13
  • 5
    This is a dangerous change - TLS 1.0 is known to be unsafe for security. – Paul Feb 08 '17 at 22:26
  • 1
    The answer http://stackoverflow.com/a/42124951/117350 fixes the issue by using a newer version of TLS – Anthony Shaw Mar 01 '17 at 15:30
  • 3
    I agree with the above comments, this was a temporary fix until we could get ASP.NET 4.5 installed, I would not recommend doing this, especially since this post was from 3 years ago. – TroySteven Jan 12 '18 at 19:38
6

Enabling TLS 1.0 solved our issues as well (after disabling SSL v3). (Server 2012 R2 with ASP.net 4.0 website processing against PPI pay services). This is the RegEdit script I used to set everything the way I wanted. We only disabled SSL v3 for the Client and not the server as doing that broke other things that we were not ready to deal with yet. After we upgrade the site to .Net 4.5.2 then we will disable TLS 1.0 again.

This script enables all protocols, Server and Client except for SSL v3 for the Client.

Be sure to backup your registry!

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
James Skemp
  • 8,018
  • 9
  • 64
  • 107
Eric Niemiec
  • 97
  • 1
  • 2
  • 11
    But enabling TLS 1.0 is not recommended, and forbidden for PCI compliance. – Keith Oct 28 '16 at 03:13
  • Forbidden or not, if you have old servers that only understand TLS 1.0 and you need to use secure sockets to migrate to newer servers, your only choice is to temporarily enable TLS 1.0 on the new servers. To meet compliance, you'll have to disable it after you've completed the migration. – JamesHoux Oct 06 '21 at 21:23
6

In my case I solved the problem by enabling the last TLS version in the .Net Framework as explained in this article:

https://learn.microsoft.com/dotnet/framework/network-programming/tls

set these registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] " SchUseStrongCrypto"=dword:00000001
PeterFnet
  • 359
  • 4
  • 11
Renzo Ciot
  • 3,746
  • 2
  • 25
  • 29
  • Thanks for sharing this! That's what solved for me too and I believe it's the best approach. I mean, you enable TLS 1.2 on the operating system (SecurityProviders registry keys), for example, and then just tell the .NET framework to use the system defaults and to prefer stronger algorithms. – Victor Lopes Mar 01 '22 at 13:34
  • For my situation it seems like I only needed to set the 'SystemDefaultTlsVersions', as mentioned here - 'NET35-UseSchannelDefaults.reg' & 'NET4X-UseSchannelDefaults.reg': I kept having the 'WcfClientTest' tool give me the same error. – DennisVM-D2i May 21 '23 at 19:07
4

There are a couple of things that you need to check related to this.

Whenever there is an error like this thrown related to making a secure connection, try running a script like the one below in Powershell with the name of the machine or the uri (like "www.google.com") to get results back for each of the different protocol types:

 function Test-SocketSslProtocols {
    
    [CmdletBinding()] 
    param(
        [Parameter(Mandatory=$true)][string]$ComputerName,
        [int]$Port = 443,
        [string[]]$ProtocolNames = $null
        )

    #set results list    
    $ProtocolStatusObjArr = [System.Collections.ArrayList]@()


    if($ProtocolNames -eq $null){

        #if parameter $ProtocolNames empty get system list
        $ProtocolNames = [System.Security.Authentication.SslProtocols] | Get-Member -Static -MemberType Property | Where-Object { $_.Name -notin @("Default", "None") } | ForEach-Object { $_.Name }

    }
 
    foreach($ProtocolName in $ProtocolNames){

        #create and connect socket
        #use default port 443 unless defined otherwise
        #if the port specified is not listening it will throw in error
        #ensure listening port is a tls exposed port
        $Socket = New-Object System.Net.Sockets.Socket([System.Net.Sockets.SocketType]::Stream, [System.Net.Sockets.ProtocolType]::Tcp)
        $Socket.Connect($ComputerName, $Port)

        #initialize default obj
        $ProtocolStatusObj = [PSCustomObject]@{
            Computer = $ComputerName
            Port = $Port 
            ProtocolName = $ProtocolName
            IsActive = $false
            KeySize = $null
            SignatureAlgorithm = $null
            Certificate = $null
        }

        try {

            #create netstream
            $NetStream = New-Object System.Net.Sockets.NetworkStream($Socket, $true)

            #wrap stream in security sslstream
            $SslStream = New-Object System.Net.Security.SslStream($NetStream, $true)
            $SslStream.AuthenticateAsClient($ComputerName, $null, $ProtocolName, $false)
         
            $RemoteCertificate = [System.Security.Cryptography.X509Certificates.X509Certificate2]$SslStream.RemoteCertificate
            $ProtocolStatusObj.IsActive = $true
            $ProtocolStatusObj.KeySize = $RemoteCertificate.PublicKey.Key.KeySize
            $ProtocolStatusObj.SignatureAlgorithm = $RemoteCertificate.SignatureAlgorithm.FriendlyName
            $ProtocolStatusObj.Certificate = $RemoteCertificate

        } 
        catch  {

            $ProtocolStatusObj.IsActive = $false
            Write-Error "Failure to connect to machine $ComputerName using protocol: $ProtocolName."
            Write-Error $_

        }   
        finally {
            
            $SslStream.Close()
        
        }

        [void]$ProtocolStatusObjArr.Add($ProtocolStatusObj)

    }

    Write-Output $ProtocolStatusObjArr

}

Test-SocketSslProtocols -ComputerName "www.google.com"

It will try to establish socket connections and return complete objects for each attempt and successful connection.

After seeing what returns, check your computer registry via regedit (put "regedit" in run or look up "Registry Editor"), place

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

in the filepath and ensure that you have the appropriate TLS Protocol enabled for whatever server you're trying to connect to (from the results you had returned from the scripts). Adjust as necessary and then reset your computer (this is required). Try connecting with the powershell script again and see what results you get back. If still unsuccessful, ensure that the algorithms, hashes, and ciphers that need to be enabled are narrowing down what needs to be enabled (IISCrypto is a good application for this and is available for free. It will give you a real time view of what is enabled or disabled in your SChannel registry where all these things are located).

Also keep in mind the Windows version, DotNet version, and updates you have currently installed because despite a lot of TLS options being enabled by default in Windows 10, previous versions required patches to enable the option.

One last thing: TLS is a TWO-WAY street (keep this in mind) with the idea being that the server's having things available is just as important as the client. If the server only offers to connect via TLS 1.2 using certain algorithms then no client will be able to connect with anything else. Also, if the client won't connect with anything else other than a certain protocol or ciphersuite the connection won't work. Browsers are also something that need to be taken into account with this because of their forcing errors on HTTP2 for anything done with less than TLS 1.2 DESPITE there NOT actually being an error (they throw it to try and get people to upgrade but the registry settings do exist to modify this behavior).

  • 1
    Huge thank you for adding this answer to the list! The script is awesome!! – JamesHoux Oct 06 '21 at 19:20
  • It appears this script is not compatible with powershell version 2. :( Trying to upgrade legacy systems is such a pain. – JamesHoux Oct 06 '21 at 19:28
  • Link to a variation on the script that is simpler and works with older versions of powershell: https://www.sysadmins.lv/blog-en/test-web-server-ssltls-protocol-support-with-powershell.aspx – JamesHoux Oct 06 '21 at 21:17
  • I understand James. In the process of working through that myself. What are your server versions? You may be able to view Windows Features and the PowerShell versions enabled and activate the more recent version to work with. –  Jul 24 '22 at 07:10
2

After messing with this for days, my final fix for our issues required two things;

1) We added this line of code to all of our .Net libraries that make out bound api calls to other vendors that had also disabled their SSL v3.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls; // (.Net 4 and below)

2) This is the final and FULL registry changes you will need when you are running ASP.Net 4.0 sites and will need to be slightly changed after you upgrade to ASP.Net 4.5.

After we rebooted the servers - all problems went away after this.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
Nasreddine
  • 36,610
  • 17
  • 75
  • 94
Eric Niemiec
  • 97
  • 1
  • 2
  • 1
    Rather than adding a second answer that is nearly identical to the first, you should just edit your original answer. You should consider updating the previous one and then deleting this one. – David Dec 03 '19 at 20:06
  • You really shouldn't be having TLS security handling be implemented on an in code basis unless you absolutely have to (which you might). If you are making an outbound call you need to make sure the registry key is implemented, and if you have concern about the security inbound (say you want to be able to call a 1.0 server but only want to get calls from a 1.2) then utilize the server and client registry subkeys accordingly. You want to avoid that crap being in code because you are making it a change you have to affect everywhere in code. Deferral to the hosting environment is the best method. –  Jul 24 '22 at 07:14
  • Client will always be understood as the machine making the call with the Server always being the recipient of a calling machine's message. –  Jul 24 '22 at 07:16
2

I fixed this error by upgrading the app from .Net Framework 4.5 to 4.6.2.

TLS-1.2 was correctly installed on the server, and older versions like TLS-1.1 were disabled. However, .Net 4.5 does not support TLS-1.2.

Roland
  • 4,619
  • 7
  • 49
  • 81
1

In previous answers a few registry keys that might not exist are missed. They are SchUseStrongCrypto that must exist to allow to TLS protocols work properly.

After the registry keys have been imported to registry it should not be required to make changes in code like

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

Below there are all registry keys and values that are needed for x64 windows OS. If you have 32bit OS (x86) just remove the last 2 lines. TLS 1.0 will be disabled by the registry script. Restarting OS is required.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
"enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\server]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ssl 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ssl 3.0\client]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ssl 3.0\server]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.0\client]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.0\server]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.1]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.1\client]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.1\server]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.2\client]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.2\server]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Michael T.
  • 79
  • 1
  • 5
1

I had the same error when connecting from Windows Server 2012. I resolved by changing the TLS and SSL settings using the IIS Crypto executable. Specifically, I disabled Server Protocols SSL 3.0 and TLS 1.0. I also disabled Client Protocol SSL 3.0 (I believe this is what did the trick). I used a server that was working correctly as the basis for determining the ideal settings. Screenshot - IIS Crypto Settings

Nate W
  • 11
  • 3
1

There is a Powershell script from Microsoft, to resolve this (it worked for me):

TLS Enforcement

If (-Not (Test-Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319'))
{
    New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SystemDefaultTlsVersions' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWord' -Force | Out-Null

If (-Not (Test-Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'))
{
    New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SystemDefaultTlsVersions' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWord' -Force | Out-Null

If (-Not (Test-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'))
{
    New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWord' -Force | Out-Null

If (-Not (Test-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'))
{
    New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'Enabled' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWord' -Force | Out-Null

Write-Host 'TLS 1.2 has been enabled. You must restart the Windows Server for the changes to take affect.' -ForegroundColor Cyan
1

For me, the Command:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Returns an error:

The term 'ServicePointManager.SecurityProtocol' is not recognized as the name of a cmdlet, function, script file, or operable program.

Whereas THIS command worked:

[Net.ServicePointManager]::SecurityProtocol = 'tls12'
Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
0

After reading this thread, I fixed the issue in Windows 11 using the Register Editor in Administrator mode and going to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\

  • You will find Client and Server folders. Go to "Enabled" file and change the value to "1". After that go to "DisabledbyDefault" file and change to value "0".

Remember: Do the same operation in both folders: CLient and Server.

Primoshenko
  • 140
  • 1
  • 9