There can be a number of reasons why apps fail to access the desired url data sources. One that has become more common is a failure to use a matching TLS cipher suite. These kinds of problems can appear to come from out of nowhere. One day the app works and the next day the same app no longer works.

Note that a URL that works in Chrome or other browser may not work in your .NET app if it is relying on Windows to handle the SSL/TLS networking. In cases like this you may also see the URL fail in Internet Explorer.

1 Related Error Messages
2 Potential Solutions
- 2.1 Mismatched Cipher Suites
- 2.2 Certificate is Invalid
- 2.3 App Config
3 TLS 1.2 Support
- 3.1 Recommendations

The request was aborted: Could not create SSL/TLS secure channel.
A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.

Potential Solutions

Mismatched Cipher Suites

This article describes in good detail a situation where the client machine doesn’t have an appropriate cipher suite to connect to the server.
https://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

A cipher suite is a set of cryptographic algorithms. The Microsoft Secure Channel (aka Schannel) security support provider (SSP) implementation of the TLS/SSL protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks: Key exchange, Bulk encryption, Message authentication. Schannel is primarily used for Internet applications that require the use of HTTPS to send or receive data.

This link includes information on which ciphers are supported in each version of Windows.

https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel

Identify Website Cipher Suites

Use this online tool to analyze the host url. It provides certificate details, a complete list of accepted cipher suites and the results of simulated connections from a plethora of browsers and platforms.

https://www.ssllabs.com/ssltest/

To identify which cipher suite was used with a connection in Chrome - open the Dev Tools (F12) and select the Security tab. Example results below:

Identify Available Cipher Suites on Client/App machine

There is an app called IIS Crypto that helps manage cipher suites on Windows Server machines. It is available from https://www.nartac.com/Products/IISCrypto/.

Default location and ordering of Cipher Suites:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\0010002

Location of Cipher Suite ordering that is modified by setting group policy: (overrides above default values)

Computer Configuration\Administrative Templates\Network\SSL Configuration Settings\SSL Cipher Suite Order

To configure the SSL Cipher Suite Order group policy setting (on windows server machines)

At a command prompt, enter gpedit.msc. The Group Policy Object Editor appears.
Expand Computer Configuration, Administrative Templates, Network, and then click SSL Configuration Settings.
Under SSL Configuration Settings, click the SSL Cipher Suite Order setting.
In the SSL Cipher Suite Order pane, scroll to the bottom of the pane.
Follow the instructions labeled How to modify this setting.

It is necessary to restart the computer after modifying this setting for the changes to take effect.

References:

Certificate is Invalid

Check the certificate on the site and make sure it’s valid. If it isn’t you may need to update it.

App Config

You want to allow the app to select the most secure connection available from the OS.

This article describes how to do this with options for different versions of the .Net Framework
Transport Layer Security (TLS) best practices with the .NET Framework

Quick Notes and Samples

For apps using .NET Framework 4.6 - 4.6.2 and not WCF

<configuration>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/></startup>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" />
  </runtime>
</configuration>

For ASP.Net apps:

For ASP.NET applications, inspect the <system.web><httpRuntime targetFramework> element of web.config to verify you're using the intended version of the .NET Framework. Sample config below for .Net 4.6.1

TLS 1.2 Support

As per Microsoft’s documentation, Windows 8.0 and Windows Server 2012 and up do support and enable by default the TLS 1.2 protocol.

https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#support-for-tls-12

Recommendations

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

Consider the following recommendations:

For TLS 1.2, target .NET Framework 4.7 or later versions on your apps, and target .NET Framework 4.7.1 or later versions on your WCF apps. (but 4.6 - 4.6.2 can be configured to work as well)
For TLS 1.3, target .NET Framework 4.8 or later.
Do not specify the TLS version. Configure your code to let the OS decide on the TLS version.
Perform a thorough code audit to verify you're not specifying a TLS or SSL version.

When your app lets the OS choose the TLS version:

It automatically takes advantage of new protocols added in the future, such as TLS 1.3.
The OS blocks protocols that are discovered not to be secure.

Related Error Messages