0
votes

I have a .NET WebService call that is set to use TLS1.1 or higher. This works in my local development, but when i move to our development server, I receive the following error:

Could not ExecuteRequest for xxx data - - The request was aborted: Could not create SSL/TLS secure channel.

In the code i have the tls settings:

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13 | SecurityProtocolType.Ssl3;

I've verified on the server the registry settings are correct for enabling TLS1.1, 1.2, etc... by checking: *HKEYLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols[TLS 1.1, TLS 1.2]* I have the DisabledByDefault = 0 and Enabled = 1 for both "Client" and "Server" keys at these locations

In the windows system logs there is an Schannel error: EventID 36887: A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.

I'm not sure where to go from here. I feel like it's probably a simple setting or a registry tweak, but i'm lost now.

thanks in advance for the help

1
You should provide a bit more details on what is trying to connect where when you get this error. Most likely client and server do not have one TLS version that they support. If connection happen to you service on TLS1.1+, perhaps you client is configured to use only TLS1.0?Ilya Chernomordik
the error happens when i invoke the request. the distant end that we're connecting to supports TLS1.1+, and i'm able to make this connection using the same SSL cert that is used from our test server. This service was working until the distant end removed support for TLS1.0. that's why i feel like it's a setting our server and not w/ the WebService code since we explicitly allow 1.1+orlando15767
Although it may not be related, you probably don't want SSL3. SSL3 is older than TLS 1.0. From Microsoft: SSL3 = Specifies the Secure Socket Layer (SSL) 3.0 security protocol. SSL 3.0 has been superseded by the Transport Layer Security (TLS) protocol and is provided for backward compatibility only.Wiz
What OS are you using on each end? It is possible that both OS support TLS 1.1, but the negotiated keys do not meet the requirements on both ends. We had an issue like this a few months back. You may want to check: tls-registry-settings Lowering the minimum key length for Diffie-Hellman to 1024 on Server 2016 resolved the issue in our case. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman] "ServerMinKeyBitLength"=dword:00000400Wiz
@Wiz my OS is Windows Server 2012R2. not sure about the distant end OS, but that shouldn't matter as it should be agnostic of the OS. I lowered the Diffie-Hellman to 1020 and still receiving the same errors as before. Really starting to spin my wheels now. It's acting like tls.1.1+ is being blocked or not enabled.orlando15767

1 Answers

0
votes

If I understand you correctly, you have a code that works on one server, but not the other. In that case it seems that at least you have configured .Net Framework correctly, but as one of the comments suggest you should check that your OS supports it TLS 1.1 (maybe worth checking that you are running on exact same .net framework version as well).

I see that you use win server 2012 and it seems it's not enabled by default in there. Here is a quote from MS docs here:

Earlier versions of Windows, such as Windows 7 or Windows Server 2012, don't enable TLS 1.1 or TLS 1.2 by default for secure communications using WinHTTP. For these earlier versions of Windows, install Update 3140245 to enable the registry value below, which can be set to add TLS 1.1 and TLS 1.2 to the default secure protocols list for WinHTTP.

Try checking the documentation and verify TLS 1.1. is enabled in OS.

P.S. If the server you are trying to connect to supports TLS 1.2, I would not bother with TLS 1.1 at all, and just force all to use TLS 1.2.