C#: The request was aborted: Could not create SSL/TLS secure channel

Last month we noticed that crawler on which I worked earlier was unable to crawl some of the HTTPS websites. Crawler was built in C# and deployed on several environments running Windows Server 2012 R2. Crawler was running fine on all environments except one where it was unable to connect with few HTTPS websites and it kept raising below exception

The request was aborted: Could not create SSL/TLS secure channel.

Here in this blog post, I will explain how I troubleshot to identify root cause of this exception and its possible solution.

Looking at the exception, it is clear that issue is due to SSL certificate and for some reason, server is unable to connect this particular website with HTTPS. Also as mentioned earlier that we were facing this issue in one environment or server only. Crawler was able to crawl same websites from another environment. So my first guess was that, there must be some server level configurations which is preventing connection to this website. Most probably configuration related to SSL/TLS. For e.g. website is using HTTPS certificate with unsupported or outdated protocol such as SSL 3.0 or it can be some issue with SSL certificate it self (chances of this was almost none as we were able to browse website from browser but still as I was debugging I considered all the possibilities). I fired up Visual Studio to create separate test application and run it on server.

private static bool AllwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors)

{

    return true;

}

static void Main(string[] args)

{

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AllwaysGoodCertificate);

    var httpClient = new HttpClient();

    //other code removed

}

Within test application, I enabled all the protocols, SSL 3.0 to TLS 1.2 and also attached ServerCertificateValidationCallback so that I can examine various parameter passed to callback such as certificate, if there are any SSL policy errors, etc. But in our case, exception was thrown even before it hit ServerCertificateValidationCallback. This gave me further indication that definitely it must be some server level configurations or may be bug which is preventing SSL/TLS connection. To start investigation, I opened Chrome on the server to browse same website and to my surprise it worked like a charm! But soon I realize that Chrome do not use Microsoft Schannel for it’s SSL/TLS implementation. Chrome uses BoringSSL, it’s own fork of OpenSSL, library. .NET framework uses Microsoft Schannel implementation, so to verify against Microsoft Schannel implementation, I fired up Internet Explorer. And as I rightly expected, IE was unable to connect with this website. It shows below error message.

It is asking to enable TLS 1.0 to TLS 1.2 in IE advanced settings and still if this error continue, it is possible that this site uses an unsupported protocol or cipher suite. Now if we look at advanced settings, TLS 1.0, 1.1 & 1.2 is already enabled

And also if we look at SSL certificate overview in Chrome developer tool

It clearly stat that this site is using strong protocol (TLS 1.2) and in previous step, we also verified that TLS 1.2 is enabled in IE settings. At this stage it looks like that SSL protocol is not the real culprit as it is already enabled on server. To further investigate, I again looked at error message (screenshot provided earlier) displayed in IE which read as

…this site uses an unsupported protocol or cipher suite…

Also whenever we tried to open this website from IE, it added system error entry in Event Viewer with Schannel as source.

As per the quoted error message earlier, either it can be unsupported protocol, which do not seem the oblivious case as it is already enabled, or it can be unsupported cipher suite. Here cipher suite caught my attention that this is something we are yet to verify. So In order to find supported cipher suite by website certificate, I analyzed website with SSL Labs online service.

My next step was to find out which all cipher suites are supported by IE or more precisely by Microsoft Schannel Client on this server and compare it with cipher suites supported by website certificate. I came across https://cc.dcsec.uni-hannover.de/ which list out all the cipher suites supported by browser, in our case IE and hence Microsoft Schannel Client.

We can clearly see that cipher suites supported by certificate is either disabled or not supported by Schannel.

While I was figuring out, how to address this, initially I believed that this issue could be due to Microsoft TLS Session Resumption bug as explained in this Cloudflare blog. But later I found, from IT infrastructure team, that security update for this bug is already installed on server. We were unable to identify exact reason that why some cipher suites were disabled only on this server and not on another environment but to address this issue we used IIS Crypto utility which give fine grain control to enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server.