0

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

orlando15767
  • 145
  • 1
  • 2
  • 15
  • 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 Mar 06 '20 at 19:30
  • 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 Mar 06 '20 at 20:25
  • 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 Mar 06 '20 at 21:25
  • 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](https://docs.microsoft.com/en-us/windows-server/security/tls/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:00000400` – Wiz Mar 06 '20 at 21:34
  • @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 Mar 09 '20 at 15:55
  • just to note: we're using .NET 4.8 – orlando15767 Mar 09 '20 at 18:04
  • My only other suggestion would be a network capture / wireshark. This will at least show how far the TLS negotiation is getting before the error. – Wiz Mar 10 '20 at 14:36

1 Answers1

0

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.

Ilya Chernomordik
  • 27,817
  • 27
  • 121
  • 207
  • I've followed the steps in that doc and others to enable 1.1 and 1.2 It's still failing to connect on 1.1/1.2 – orlando15767 Mar 09 '20 at 16:01
  • sorry to hear that, I can't unfortunately think of what else you can do to fix it. The only advice is to update all the servers involved to a more modern OS/.Net Framework. 2012 is quite old. I know it's not always possible/easy in legacy environments, but it's something you'll need to do sooner or later anyway – Ilya Chernomordik Mar 09 '20 at 17:24
  • Is there a way to possibly revert all registry settings that involve TLS, SSL, Ciphers, etc...? over the course of this server's life, these settings have changed due to implementing STIGs: https://public.cyber.mil/stigs/ (server, IIS) – orlando15767 Mar 09 '20 at 17:28
  • Sorry, don't have enough knowledge about this to say anything meaningful :) – Ilya Chernomordik Mar 09 '20 at 21:39