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

Question

We are unable to connect to an HTTPS server using WebRequest because of this error message:

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

We know that the server doesn't have a valid HTTPS certificate with the path used, but to bypass this issue, we use the following code that we've taken from another StackOverflow post:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

The problem is that server never validates the certificate and fails with the above error. Does anyone have any idea of what I should do?

---

I should mention that a colleague and I performed tests a few weeks ago and it was working fine with something similar to what I wrote above. The only "major difference" we've found is that I'm using Windows 7 and he was using Windows XP. Does that change something?

Amine

Check this also #1601243 – Lin

After some modification on my code, we've tried it back onto a Windows XP and it works preaty fine ... but still not in Windows 7. Heum !?! :o( – Niphablepsia

I had similar exception - see: #8595184 – Priestly

It's 2018 and this question has been viewed 308,056 times but still there is no proper fix for this!! I get this issue randomly and none of the fixes mentioned here or in any other threads have solved my issue. – Borneol

@NigelFds The error The request was aborted: Could not create SSL/TLS secure channel is a very generic one. It basically says, "the SSL/TLS/HTTPS connection initialization failed for one of many possible reasons". So if you get it regularly in a specific situation, your best option is to ask a specific question giving specific details about that situation. And checking the Event Viewer for more information. And/or enable some .NET client-side debugging to get more details (is the server cert not trusted? is there a cipher mismatch? SSL/TLS protocol version mismatch? etc). – Bribe

@MarnixKlooster I have already checked all of that, It can't be an issue with the certificate as if i retry it , it works. And I doubt I'd be able to ask this question on SO without someone coming and marking it as duplicate or something . – Borneol

I tried all the above and none of them work. But this helps me: "Ultimately the problem was the order of the ServicePointManager and the Webrequest.Create. Reversing those lines, so the ServicePointManager is defined before the Webrequest.Create fixed the issue. I still don't know why adding the ServicePointManager after the Create fixed our original issue when our server moved to TLS 1.2, but we're not going to worry about that now." Original post: #52297365 – Subinfeudation

I had the same problem on windows 7, the problem is reproducible on internet explorer 11 going to a site that it has a certificate only supports tls2 protocol (i.e no ss3, no tls and tls 1.1, just only tls2). I had realize that windows 7 O.S was not up to date and I couldn't do a massive update due problems of connectivity so I started an investigation. After waste two days I got the solution. It seems to be that installing MS14-066 ( Windows6.1-KB2992611-x64 ) it enable some additionals cipher that it doesn't comes with windows 7 at begining. – Chyle

I have this same error with Visual Studio 2017 (15.9.3) on windows 10. – Lashley

@NigelFds are you connecting with a server that uses a wildcard SSL server certificate and Server Name Indication? – Holp

@Holp my application connects to many different APIs and almost all have this issue from time to time ... I feel the issue lies in .Net framework – Borneol

@NigelFds to clarify: your target .NET Framework is 4.5.2 ? – Holp

@Holp yes it is – Borneol

I'm fighting this issue maybe for the 4th time. The same code base I'm running works fine in production and also in the dev environment of some of my fellow devs. Last time around, I was instructed to add a registry value Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.7.02046\SchUseStrongCrypto [DWORD] = 1. And it worked for a while. I started working in a different project for a time and now I'm back to this project and the request fails again, even with this registry key fix. Very annoying. – Rillings

@NigelFds Using 4.5.2 is almost surely a large part of the problem. The runtime determines the security protocol defaults, and 4.5.x only has SSL 3.0 and TLS 1.0 enabled, meaning if your app calls an API that has TLS 1.0 disabled, it will fail. Try a higher .NET Framework, preferably 4.7 or higher. Please see my answer for more details, especially if your app is an ASP.NET site. – Huckaback

Same problems here, this issue happened randomly, not sure if it is related to network. Using .net framework 4.7.2 so it shouldn't relate to tls1.2 – Raskin

learn.microsoft.com/en-us/dotnet/framework/network-programming/… – Dardar

I've seen this issue from time to time over the years, but now I'm dealing with it again, but it's inconsistent. Old code base, .NET Web Forms, first time the page is loaded, I get the error. If I refresh the page, everything functions as it should. I've specified to connect with TLS 1.2 - I can't seem to figure out why this consistently throws an error on the first page load but not subsequent page loads. – Libel

Answer 1

I finally found the answer (I haven't noted my source but it was from a search);

While the code works in Windows XP, in Windows 7, you must add this at the beginning:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

And now, it works perfectly.

---

ADDENDUM

As mentioned by Robin French; if you are getting this problem while configuring PayPal, please note that they won't support SSL3 starting by December, 3rd 2018. You'll need to use TLS. Here's Paypal page about it.

Amine

This works for the new HttpClient class too. – Area

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; alone might work too. I'm using Windows 8. – Cram

Going down to SecurityProtocolType.Tls12 actually fixed this problem for me. See my answer below. – Foliose

SSLv3 is 18 years old and now susceptible to the POODLE exploit - as @LoneCoder recommends SecurityProtocolType.Tls12 is the suitable replacement for SecurityProtocolType.Ssl3 – Joab

SecurityProtocolType.Tls might actually be a better alternative until an exploit is found for that (not all sites support Tls12 as of writing) – Joab

As a further information, for paypal i also needed to update the soap web reference. +1 – Sometime

PayPal have set a date of June 30 2017 to disable SSL3 and implement TLS1.2. It is already applied in their sandbox environment paypal-knowledge.com/infocenter/… – Contactor

ServicePointManager is a class in the System.Net namespace, and Expect100Continue and SecurityProtocol are static properties of that class. Without a using directive, you can accomplish this by System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12; – Remonstrate

You can send a GET request with your HttpWebRequest to this url: ssllabs.com/ssltest/viewMyClient.html and save the response body to disk, then open this file in a browser. It will tell you the protocol versions you have choosen (SecurityProtocolType has FlagsAttribute attribute) along with many others security details about your web client. – Medamedal

Github API updated to be TLs only on February 22nd 2018 (which made me encounter the error above) : developer.github.com/changes/… – Haggerty

My task scheduler execute every day (not weekend). I get the same error, but sometimes (2 errors in 2 months). When I get the error, later few minutes I try again manually and all is OK. I use WebRequest.Create. I not use ServicePointManager – Glutamate

Do you get the error always (in all requests) or sometimes ? – Pickwickian

See this as well. You don't need to exclusively set it to a single type, you can simply append as well. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12; – Rainfall

This works but it is VERY important that you set the ServicePointManager settings before you perform the web request.. I.E ServicePointManager code should be at the top of your code in order to work. – Wetzell

@PreguntonCojoneroCabrón I get the error sometimes on windows 7, but neveron on windows 10. Your question let me hope that you have an idea or a solution for this case? – Falconet

This change is static and global so you only have to do it once rather than for each request--ideally in a startup class. You can run into weird behavior if you don't. I was seeing this error only for the first request and subsequent requests were okay. It was because the HttpWebRequest was being set up before the above, so the newly initialized HttpWebRequest wasn't wise to the new protocol until a second run. – Longlongan

Expect100Continue can be set for a particular HttpWebRequest instance: _request.ServicePoint.Expect100Continue = false; I think is a better idea than change it globally for every request. – Tote

You don't need to set ServicePointManager.Expect100Continue = true;. It is enabled by default (see here). – Rachmaninoff

You can add this in the constructor of your test and it will fix the issue even if the implementation is in another library. Solved it for me! – Bree

It should be noted that Microsoft strongly advises against doing this. If you are seeing this issue, it is very likely due to using an old version of the .NET framework. I have added an answer going into more detail about this. – Huckaback

I had the same error, and used the solution above, however my code only worked when I run my code in Visual Studio as an administrator. The error message doesn't change when its a permissions issue, so try running it as an admin as well. – Paprika

I battled with this error when developing an MS Access VSTO add-in. DLL code would work if executed via a console app but the exact same command would fail if executed via Access. Turned out the console app used .SystemDefault while for some reason Access would set this to Ssl | Tls, neither of which were supported by the server. – Ella

this worked now but now I keep getting this error. However it works on localhost. – Walford

learn.microsoft.com/en-us/dotnet/framework/network-programming/… – Dardar

you must do this BEFORE the create() – Abstention

For .net framework 4.0 (TLS 1.3) try this way ServicePointManager.SecurityProtocol = (SecurityProtocolType)12288| (SecurityProtocolType)3072 | (SecurityProtocolType)768 | SecurityProtocolType.Tls; – Theological

Answer 2

The solution to this, in .NET 4.5 is

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

If you don’t have .NET 4.5 then use

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Riggs

Doesn't work on Windows Server 2008R2 (and possibly on 2012 as well) – Bulwerlytton

For VB types (since this answer shows up in Google), the equivalent code is ServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType) – Peevish

Answer 3

Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work.

Works:

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

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Fails:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

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

Scouring

Answer 4

Note: Several of the highest voted answers here advise setting ServicePointManager.SecurityProtocol, but Microsoft explicitly advises against doing that. Below, I go into the typical cause of this issue and the best practices for resolving it.

One of the biggest causes of this issue is the active .NET Framework version. The .NET framework runtime version affects which security protocols are enabled by default.

• In ASP.NET sites, the framework runtime version is often specified in web.config. (see below)
• In other apps, the runtime version is usually the version for which the project was built, regardless of whether it is running on a machine with a newer .NET version.

There doesn't seem to be any authoritative documentation on how it specifically works in different versions, but it seems the defaults are determined more or less as follows:

Framework Version	Default Protocols
4.5 and earlier	SSL 3.0, TLS 1.0
4.6.x	TLS 1.0, 1.1, 1.2, 1.3
4.7+	System (OS) Defaults

For the older versions, your mileage may vary somewhat based on which .NET runtimes are installed on the system. For example, there could be a situation where you are using a very old framework and TLS 1.0 is not supported, or using 4.6.x and TLS 1.3 is not supported.

Microsoft's documentation strongly advises using 4.7+ and the system defaults:

We recommend that you:

• Target .NET Framework 4.7 or later versions on your apps. Target .NET Framework 4.7.1 or later versions on your WCF apps.
• 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.

For ASP.NET sites: check the targetFramework version in your <httpRuntime> element, as this (when present) determines which runtime is actually used by your site:

<httpRuntime targetFramework="4.5" />

Better:

<httpRuntime targetFramework="4.7" />

Huckaback

Answer 5

I had this problem trying to hit https://ct.mob0.com/Styles/Fun.png, which is an image distributed by CloudFlare on its CDN that supports crazy stuff like SPDY and weird redirect SSL certs.

Instead of specifying Ssl3 as in Simons answer I was able to fix it by going down to Tls12 like this:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Foliose

Do you get the error always (in all requests) or sometimes ? – Pickwickian

Answer 6

The problem you're having is that the aspNet user doesn't have access to the certificate. You have to give access using the winhttpcertcfg.exe

An example on how to set this up is at: http://support.microsoft.com/kb/901183

Under step 2 in more information

EDIT: In more recent versions of IIS, this feature is built in to the certificate manager tool - and can be accessed by right clicking on the certificate and using the option for managing private keys. More details here: https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Equerry

I've tried executing winhttpcertcfg.exe ... note that I'm on Windows 7. Can it changes something? – Niphablepsia

I am not sure if it is related, but this post gave me the idea to run VS as admin when making this call from VS and that fixed the issue for me. – Goal

In Windows 7 and later, the certificate must be in the store for the Local Computer rather than Current User in order to "Manage Private Keys" – Diction

Yep, this was my problem. use mmc.exe, add the certificates snap-in (for me I then chose 'local computer'). Right-click certificate, all tasks, manage private keys. Add 'everyone' (for local dev this is easiest - prod obviously needs your explicit IIS website app pool / user) – Nash

Answer 7

After many long hours with this same issue I found that the ASP.NET account the client service was running under didn't have access to the certificate. I fixed it by going into the IIS Application Pool that the web app runs under, going into Advanced Settings, and changing the Identity to the LocalSystem account from NetworkService.

A better solution is to get the certificate working with the default NetworkService account but this works for quick functional testing.

Viscometer

What if my application is console application that too developed in .net Core (FW 5.0) ?? – Scotney

Answer 8

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. The most common is an invalid or expired server certificate, and you took care of that by providing your own server certificate validation hook, but is not necessarily the only reason. The server may require mutual authentication, it may be configured with a suites of ciphers not supported by your client, it may have a time drift too big for the handshake to succeed and many more reasons.

The best solution is to use the SChannel troubleshooting tools set. SChannel is the SSPI provider responsible for SSL and TLS and your client will use it for the handshake. Take a look at TLS/SSL Tools and Settings.

Also see How to enable Schannel event logging.

Picket

Where is the path for Schannel event logging in Windows 7-8-10 ? – Pickwickian

troubleshoot TLS/SSL programatically in C# ? – Glutamate

@PreguntonCojoneroCabrón This is the path: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, set EventLogging to 1. Find those logs from Event Viewer by filtering them based on source as Schannel. – Exodontist

Answer 9

The approach with setting

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Seems to be okay, because Tls1.2 is latest version of secure protocol. But I decided to look deeper and answer do we really need to hardcode it.

Specs: Windows Server 2012R2 x64.

From the internet there is told that .NetFramework 4.6+ must use Tls1.2 by default. But when I updated my project to 4.6 nothing happened. I have found some info that tells I need manually do some changes to enable Tls1.2 by default

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

But proposed windows update doesnt work for R2 version

But what helped me is adding 2 values to registry. You can use next PS script so they will be added automatically

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

That is kind of what I was looking for. But still I cant answer on question why NetFramework 4.6+ doesn't set this ...Protocol value automatically?

Coaptation

do you need to restart the server after making those changes? – Seadog

@Seadog If you are talking about the machine - no, just restarting the application/host should be enough – Coaptation

Adding the registry keys helped in my case. Additional info from learn.microsoft.com/en-us/dotnet/framework/network-programming/… "A value of 1 causes your app to use strong cryptography. The strong cryptography uses more secure network protocols (TLS 1.2, TLS 1.1, and TLS 1.0) and blocks protocols that are not secure. A value of 0 disables strong cryptography." Restarting my app was enough. – Gabbie

@Gabbie thank you, I will update the answer – Coaptation

If your project is an ASP.NET site, then what usually matters is the framework version specified in the web.config and not the version that the .csproj targets. I elaborate on this in my answer. – Huckaback

Answer 10

Another possible cause of the The request was aborted: Could not create SSL/TLS secure channel error is a mismatch between your client PC's configured cipher_suites values, and the values that the server is configured as being willing and able to accept. In this case, when your client sends the list of cipher_suites values that it is able to accept in its initial SSL handshaking/negotiation "Client Hello" message, the server sees that none of the provided values are acceptable, and may return an "Alert" response instead of proceeding to the "Server Hello" step of the SSL handshake.

To investigate this possibility, you can download Microsoft Message Analyzer, and use it to run a trace on the SSL negotiation that occurs when you try and fail to establish an HTTPS connection to the server (in your C# app).

If you are able to make a successful HTTPS connection from another environment (e.g. the Windows XP machine that you mentioned -- or possibly by hitting the HTTPS URL in a non-Microsoft browser that doesn't use the OS's cipher suite settings, such as Chrome or Firefox), run another Message Analyzer trace in that environment to capture what happens when the SSL negotiation succeeds.

Hopefully, you'll see some difference between the two Client Hello messages that will allow you to pinpoint exactly what about the failing SSL negotiation is causing it to fail. Then you should be able to make configuration changes to Windows that will allow it to succeed. IISCrypto is a great tool to use for this (even for client PCs, despite the "IIS" name).

The following two Windows registry keys govern the cipher_suites values that your PC will use:

• HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
• HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Here's a full writeup of how I investigated and solved an instance of this variety of the Could not create SSL/TLS secure channel problem: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Individuality

In my case, this answer is helpful. Also, since I suspected my client PC missed some cipher suites, I took a shortcut and installed this Windows Update directly to try my luck (support.microsoft.com/en-hk/help/3161639, needs Windows reboot) before really starting the Message Analyzer search, and turned out I was lucky and it solved my problem, saving myself a search. – Ethbun

Note that when you test a HTTPS link in browsers such as Firefox, even if you get a different cipher than the ones provided by any given Windows Update, the Windows Update is still worth to be tried, because installing new ciphers will affect the cipher negotiation between the client PC and server, thus increasing the hope of finding a match. – Ethbun

To the point answer for my problem. Two things that helped me to find the changes to make. 1. Cipher Suites supported by the web server: ssllabs.com/ssltest 2. Cipher Suites that different Windows versions support: learn.microsoft.com/en-us/windows/win32/secauthn/… – Resale

Answer 11

Something the original answer didn't have. I added some more code to make it bullet proof.

ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Amoroso

I would not recommend the added SSL3 protocol. – Unloosen

SSL3 has a severe security issue called 'Poodle'. – Unloosen

@PeterdeBruijn Tls and Tls11 are obsoletes ? – Glutamate

@Glutamate - yes. As of June 2018 the PCI (Payment Card Industries) will not allow protocols lower than TLS1.2. (This was originally slated for 06/2017 but was postponed for a year) – Walley

There are five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, and TLS v1.2: github.com/ssllabs/research/wiki/… SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes Only valid option will be ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12? – Glutamate

Answer 12

Try adding the below line before calling an HTTPS URL (for .NET Framework 4.5):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Feather

Answer 13

The top-voted answer will probably be enough for most people. However, in some circumstances, you could continue getting a "Could not create SSL/TLS secure channel" error even after forcing TLS 1.2. If so, you may want to consult this helpful article for additional troubleshooting steps. To summarize: independent of the TLS/SSL version issue, the client and server must agree on a "cipher suite." During the "handshake" phase of the SSL connection, the client will list its supported cipher-suites for the server to check against its own list. But on some Windows machines, certain common cipher-suites may have been disabled (seemingly due to well-intentioned attempts to limit attack surface), decreasing the possibility of the client & server agreeing on a cipher suite. If they cannot agree, then you may see "fatal alert code 40" in the event viewer and "Could not create SSL/TLS secure channel" in your .NET program.

The aforementioned article explains how to list all of a machine's potentially-supported cipher suites and enable additional cipher suites through the Windows Registry. To help check which cipher suites are enabled on the client, try visiting this diagnostic page in MSIE. (Using System.Net tracing may give more definitive results.) To check which cipher suites are supported by the server, try this online tool (assuming that the server is Internet-accessible). It should go without saying that Registry edits must be done with caution, especially where networking is involved. (Is your machine a remote-hosted VM? If you were to break networking, would the VM be accessible at all?)

In my company's case, we enabled several additional "ECDHE_ECDSA" suites via Registry edit, to fix an immediate problem and guard against future problems. But if you cannot (or will not) edit the Registry, then numerous workarounds (not necessarily pretty) come to mind. For example: your .NET program could delegate its SSL traffic to a separate Python program (which may itself work, for the same reason that Chrome requests may succeed where MSIE requests fail on an affected machine).

Maupin

Answer 14

"The request was aborted: Could not create SSL/TLS secure channel" exception can occur if the server is returning an HTTP 401 Unauthorized response to the HTTP request.

You can determine if this is happening by turning on trace-level System.Net logging for your client application, as described in this answer.

Once that logging configuration is in place, run the application and reproduce the error, then look in the logging output for a line like this:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

In my situation, I was failing to set a particular cookie that the server was expecting, leading to the server responding to the request with the 401 error, which in turn led to the "Could not create SSL/TLS secure channel" exception.

Individuality

My task scheduler execute every day (not weekend). I get the same error, but sometimes (2 errors in 2 months). When I get the error, later few minutes I try again manually and all is OK. – Glutamate

Answer 15

This one is working for me in MVC webclient

public string DownloadSite(string RefinedLink)
{
    try
    {
        Uri address = new Uri(RefinedLink);

        ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

        System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

        using (WebClient webClient = new WebClient())
        {
            var stream = webClient.OpenRead(address);
            using (StreamReader sr = new StreamReader(stream))
            {
                var page = sr.ReadToEnd();

                return page;
            }
        }

    }
    catch (Exception e)
    {
        log.Error("DownloadSite - error Lin = " + RefinedLink, e);
        return null;
    }
}

Corrade

Would override ServerCertificateValidationCallback introduce new security hole? – Lasalle

Answer 16

Another possibility is improper certificate importation on the box. Make sure to select encircled check box. Initially I didn't do it, so code was either timing out or throwing same exception as private key could not be located.

Nomi

A client kept having to re-install the cert in order to use a client program. Over and over again they would have to re-install the cert before using the program. I'm hoping this answer fixes that issue. – Treble

Answer 17

Doing this helped me:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Gardener

Answer 18

I had this problem because my web.config had:

<httpRuntime targetFramework="4.5.2" />

and not:

<httpRuntime targetFramework="4.6.1" />

Defenestration

That fixed my issue. In the client app in webconfig file I had httpRuntime setup as 4.5. Changed it to 4.7.2. I had earlier upgrade from 4.5 to 4.7.2 but not sure why it was not updated. Anyway it helped me. – Glialentn

Answer 19

In my case, the service account running the application did not have permission to access the private key. Once I gave this permission, the error went away

1. mmc
2. certificates
3. Expand to personal
4. select cert
5. right click
6. All tasks
7. Manage private keys
8. Add the service account user

Dusky

Can you please expand on the answer with full process by adding screenshots and such? What do you add in step 8? – Exodontist

Answer 20

As you can tell there are plenty of reasons this might happen. Thought I would add the cause I encountered ...

If you set the value of WebRequest.Timeout to 0, this is the exception that is thrown. Below is the code I had... (Except instead of a hard-coded 0 for the timeout value, I had a parameter which was inadvertently set to 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Armandoarmature

Wow! Thanks for mentioning this. Couldn't believe this in the first place and tried tons of different things first. Then, finally, set the timeout to 10sec and the exception disappeared! This is the solution for me. (y) – Mullet

Answer 21

The root of this exception in my case was that at some point in code the following was being called:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

This is really bad. Not only is it instructing .NET to use an insecure protocol, but this impacts every new WebClient (and similar) request made afterward within your appdomain. (Note that incoming web requests are unaffected in your ASP.NET app, but new WebClient requests, such as to talk to an external web service, are).

In my case, it was not actually needed, so I could just delete the statement and all my other web requests started working fine again. Based on my reading elsewhere, I learned a few things:

• This is a global setting in your appdomain, and if you have concurrent activity, you can't reliably set it to one value, do your action, and then set it back. Another action may take place during that small window and be impacted.
• The correct setting is to leave it default. This allows .NET to continue to use whatever is the most secure default value as time goes on and you upgrade frameworks. Setting it to TLS12 (which is the most secure as of this writing) will work now but in 5 years may start causing mysterious problems.
• If you really need to set a value, you should consider doing it in a separate specialized application or appdomain and find a way to talk between it and your main pool. Because it's a single global value, trying to manage it within a busy app pool will only lead to trouble. This answer: https://mcmap.net/q/64526/-set-the-securityprotocol-ssl3-or-tls-on-the-net-httpwebrequest-per-request provides a possible solution by way of a custom proxy. (Note I have not personally implemented it.)

Fleta

Contrary to your general rule of thumb, I'll add that there is an exception when you MUST set it to TLS 1.2, rather than letting the default run. If you are on a framework older than .NET 4.6, and you disable insecure protocols on your server (SSL or TLS 1.0/1.1), then you cannot issue requests unless you force the program into TLS 1.2. – Kopaz

Answer 22

If you are running your code from Visual Studio, try running Visual Studio as administrator. Fixed the issue for me.

Gulley

That probably means that you didn't have access to the certificate, or perhaps its private key, in the user account you were running in. – Protectorate

Answer 23

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

In our case, we where using a software vendor so we didn't have access to modify the .NET code. Apparently .NET 4 won't use TLS v 1.2 unless there is a change.

The fix for us was adding the SchUseStrongCrypto key to the registry. You can copy/paste the below code into a text file with the .reg extension and execute it. It served as our "patch" to the problem.

Windows Registry Editor Version 5.00

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

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

Cymene

Here PS for quick edit: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord – Doughy

Here PS for quick edit2: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord – Doughy

This ended up being our problem and solution as well. Our apps running .NET Framework v4.8 on Windows 2012 servers would get the SSL error whenever making HTTPS requests to other Windows 2016 servers within our datacenter. Applying these registry edits to the 2012 hosts solved the problem for us. Here is a helpful article about it: Enabling Strong Cryptography - JohnLouros.com – Cembalo

Answer 24

none of this answer not working for me , the google chrome and postman work and handshake the server but ie and .net not working. in google chrome in security tab > connection show that encrypted and authenticated using ECDHE_RSA with P-256 and AES_256_GCM cipher suite to handshake with the server.

i install IIS Crypto and in cipher suites list on windows server 2012 R2 ican't find ECDHE_RSA with P-256 and AES_256_GCM cipher suite. then i update windows to the last version but the problem not solve. finally after searches i understood that windows server 2012 R2 not support GSM correctly and update my server to windows server 2016 and my problem solved.

Valentia

Answer 25

I have struggled with this problem all day.

When I created a new project with .NET 4.5 I finally got it to work.

But if I downgraded to 4.0 I got the same problem again, and it was irreversable for that project (even when i tried to upgrade to 4.5 again).

Strange no other error message but "The request was aborted: Could not create SSL/TLS secure channel." came up for this error

Herriott

The reason that this worked may have been because different .NET versions support different SSL/TLS protocol versions. More info: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support – Individuality

I think this article helps to explain why upgrading solved the problem for you. johnlouros.com/blog/… – Cembalo

Answer 26

In case that the client is a windows machine, a possible reason could be that the tls or ssl protocol required by the service is not activated.

This can be set in:

Control Panel -> Network and Internet -> Internet Options -> Advanced

Scroll settings down to "Security" and choose between

• Use SSL 2.0
• Use SSL 3.0
• Use TLS 1.0
• Use TLS 1.1
• Use TLS 1.2

Osteoplastic

any issue in ticking all of them ? – Borneol

no issues, as far as I know... except that ssl are not any more recommended... they are not considered secure enough. – Osteoplastic

how-to do it programatically in powershell ? – Glutamate

This is something that affects older versions of Windows, Do some research, find out what security options are currently in use. As of today see this link: tecadmin.net/enable-tls-on-windows-server-and-iis – Herd

Answer 27

Another possibility is that the code being executed doesn't have the required permissions.

In my case, I got this error when using Visual Studio debugger to test a call to a web service. Visual Studio wasn't running as Administrator, which caused this exception.

Jennette

Answer 28

I was having this same issue and found this answer worked properly for me. The key is 3072. This link provides the details on the '3072' fix.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

Billow

This solution works even if you're using the ancient 4.0 .NET framework. – Onto

Answer 29

None of the answers worked for me.

This is what worked:

Instead of initializing my X509Certifiacte2 like this:

   var certificate = new X509Certificate2(bytes, pass);

I did it like this:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Notice the X509KeyStorageFlags.Exportable !!

I didn't change the rest of the code (the WebRequest itself):

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

In fact I'm not even sure that the first two lines are necessary...

Laveen

In my case this problem occurred ONLY when hosting the process in IIS (i.e. the webapp making a call elsewhere). - This fixed it! Thanks for sharing! – Heterolysis

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; using this line worked for me. – Compete

Answer 30

We had the same problem in a client Windows Server 2012R2. The error 40 means that the client and the server does not agree with the cipher suite to use. In most cases, the server requires a cipher suite that the client does not recognize.

If you cannot modify server settings, the solution is to add those "missing" cipher suites to the client this way:

1. First, go to SSLLabs SSL Labs
2. Enter the url of the site/api you are having problem to connect
3. Wait a few minutes until the test is completed
4. Go to 'Cipher Suites' section and read very carefully TLS 1.3 / TLS 1.2
5. There you will find the Cipher Suites accepted by the server
6. Now in your windows server, go to Regedit
7. Open the Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL
8. There you will find 2 folders: 00010002 -->TLS 1.2 and 00010003 --> TLS 1.3
9. Now, edit the Functions key, and add the suites required by the server
10. In our case, we needed to Add TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to 00010002 folder

Fairminded

Answer 31

This fixed for me, add Network Service to permissions. Right click on the certificate > All Tasks > Manage Private Keys... > Add... > Add "Network Service".

Grassy

Can you please expand on the answer with screenshots? – Exodontist

Answer 32

Most answers above mention session algorithms or key exchange algorithms.

In my case both were OK and the problem was in server's certificate hash algorithm, that was not enabled on client's PC.

I figured it out adding a section to my application's config.

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
        <source name="System.Net">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
        <source name="System.Net.Sockets">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
        <source name="System.Net.Cache">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
    </sources>
    <sharedListeners>
        <add
            name="System.Net"
            type="System.Diagnostics.TextWriterTraceListener"
            initializeData="System.Net.trace.log"
        />
    </sharedListeners>
    <switches>
        <add name="System.Net" value="Verbose" />
        <add name="System.Net.Sockets" value="Verbose" />
        <add name="System.Net.Cache" value="Verbose" />
    </switches>
</system.diagnostics>

And then error in log led me to this solution

Loadstar

Answer 33

I know it's late answer but I faced the same issue when I try to call API (hosted on win server 2016) from win server 2012 R2 (client)

After a lot of investigation the issue was related to handshake issue on operating system level specifically the list of ciphers from client is not supported by the host server.

I got to know the issue when I used Wireshark to trace the connection and I found out that the sent cipher is not supported.

Window server 2012 R2 has limited support to new ciphers which might cause TLS/SSL handshake.

the starting point was when I saw this error "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40" in event viewer (Event Viewer >> Custom Views >> Administrative Events))

Melano

Answer 34

The issue for me was that I was trying to deploy on IIS as a web service, I installed the certificate on the server, but the user that runs IIS didn't have the correct permissions on the certificate.

How to give ASP.NET access to a private key in a certificate in the certificate store?

Tolerance

Yep, ditto. To fix it, I did what Nick Gotch's answer said: changed the app pool identity to LocalSystem. This solved it for me. – Contango

Answer 35

This question can have many answers since it's about a generic error message. We ran into this issue on some of our servers, but not our development machines. After pulling out most of our hair, we found it was a Microsoft bug.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Essentially, MS assumes you want weaker encryption, but the OS is patched to only allow TLS 1.2, so you receive the dreaded "The request was aborted: Could not create SSL/TLS secure channel."

There are three fixes.

1. Patch the OS with the proper update: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2. Add a setting to your app.config/web.config file (as mentioned in the above link):

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

3. Add a registry setting that was already mentioned in another answer.

All of these are mentioned in the knowledge base article I posted.

Munson

Also, make sure you are only setting ServicePointManager.SecurityProtocol once in your app. We discovered a second call in our app (which is rather complex with optional assemblies being loaded at runtime) that was setting it to SSL3, which then threw the same error message. – Munson

Answer incomplete. 2) Which setting?. – Scalariform

Answer 36

In my case, I was running under Visual Studio 2022. Time and time again I was getting this error. Going through the code I saw that it retrieved the certificate just fine. Security was set to TLS1.2, both answers above. For whatever reason, running Visual Studio as Administrator made it work! Maybe someone can explain to me how the code retrieved the certificate from the store just fine. I could see it and all the properties. Why in the name of this world would it not process the request unless I run VS in admin mode???

Wretched

Answer 37

This was happening for me on just one site, and it turns out that it only had the RC4 cipher available. In a prior effort to harden the server, I had disabled the RC4 cipher, once I re-enabled this the issue was solved.

Platina

Do not use links on response, as they may not work on future, point out the most relevant aspects on it inside your answer – Heinous

Answer 38

In my case I had this problem when a Windows service tried to connected to a web service. Looking in Windows events finally I found a error code.

Event ID 36888 (Schannel) is raised:

The following fatal alert was generated: 40. The internal error state is 808.

Finally it was related with a Windows Hotfix. In my case: KB3172605 and KB3177186

The proposed solution in vmware forum was add a registry entry in windows. After adding the following registry all works fine.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]

"ClientMinKeyBitLength"=dword:00000200

Apparently it's related with a missing value in the HTTPS handshake in the client side.

List your Windows HotFix:

wmic qfe list

Solution Thread:

https://communities.vmware.com/message/2604912#2604912

Cartload

Answer 39

I had this issue uploading a video to Wistia via a command line app. Our system administrator resolved the issue by enabling additional cipher suites using IIScrypto that was listed in the SSL labs scan for upload.wistia.com

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256

Frowsty

Answer 40

In case you already have this

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

in your code and you or your clients still get this error here what I found that works for my company:

We are seeing more and more error coming from newer versions of Windows OS and I believe the reason for that is that Microsoft is starting to decommission older TLS version in latest windows updates and they are not supported by the Windows OS anymore. It seems this enum above is used during socket handshake where security protocol is negotiated. By having enum set like this you are falsely advertising support of security protocol that is not supported by the OS. When the secure channel is opened and one of non supported protocols were negotiated, between client and server, you end up with the above error. Starting with .net framework 4.7 you should not explicitly set Security protocol and leave with its default value which is actually a set of protocols that are supported by the OS. This way you won't negotiate not supported protocol and won't get the error we are talking about.

Ilona

Answer 41

As long as this is a relatively "live" link I thought I would add a new option. That possibility is that the service is no longer supporting SSL 3.0 due to the problem with the Poodle attack. Check out the Google statement on this. I encountered this problem with several web services at once and realized something had to be going on. I switched to TLS 1.2 and everything is working again.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Concise

Answer 42

For SOAP/WCF users, this error can also occur when the server rejects your WS-Security configuration. The error information the client receives is very vague, but the server administrator will likely be able to determine the reason.

Once example of this is under the UsernameToken Profile, where the message is considered expired by the <wsu:Created> time is not a valid ISO 8601 datetime, either due to bad formatting, not being UTC, or having mismatched server times.

<wsse:UsernameToken wsu:Id="Example-1">
   <wsse:Username> ... </wsse:Username>
   <wsse:Password Type="..."> ... </wsse:Password>
   <wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
   <wsu:Created>2021-01-31T19:00:00.0000000Z</wsu:Created>
</wsse:UsernameToken>

Negative

Answer 43

After days of pulling what hair I have left out, we solved the problem. I tried everything suggested on this post and nothing worked for me. For us, we had a basic .Net Framework 4.8 console app running on a customers Windows VM. The on-premise server we were communicating with required that SSL Certificate Validation was turned off. One of our guys discovered that the server required we were using TLS 1.0 and on the registry settings of the VM, TLS 1.0 was disabled. Once we enabled that, it worked. I also needed to added the following two lines as mentioned many times above:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

Brunel

Nice seeing that even 12 years later, this post continue to live and evolve as everyone is posting their experience. The initial problem sure has changed a lot since, and so the solution. Then I'm happy you found out a way to get it working – Niphablepsia

Answer 44

If you mention an incorrect Host then also you will get this same error "The request was aborted: Could not create SSL/TLS secure channel."

To solve this I had to give the correct Host. Most of the times the Host is the domain of the URL you are trying to GET. e.g.

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

Host : https://stackoverflow.com

client.Headers.Add(HttpRequestHeader.Host, Host.ToString());

Auric

Answer 45

I was getting this issue in the vb.net windows form.

Tried adding multiple security protocols as mentioned in the above answers.

ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | 
SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | 
SecurityProtocolType.Ssl3;

Nothing was working.

But this is how I resolve

Turn off the Windows Defender firewall as shown in the image below and change the system to the domain network (you can ask your network department to change the system to the domain). After that I used SecurityProtocolType.Tls12 and it works.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Downstream

Answer 46

You can try to install a demo certificate (some ssl providers offers them for free for a month) to be sure if the problem is related to cert validity or not.

Frontal

Installing certificate would work on my computer for sure, but i'm trying to authenticate to an external certificate on a server that I've not any access otherwize than an API access using WebRequest but I must authenticate to the https zone ... – Niphablepsia

so, dowload their certificate and install as trusted on the app machine. – Frontal

Ok... Maybe I'll look a little beginner but, why and how? – Niphablepsia

Answer 47

The default .NET ServicePointManager.SecurityProtocol uses SSLv3 and TLS. If you are accessing an Apache server, there is a config variable called SSLProtocol which defaults to TLSv1.2. You can either set the ServicePointManager.SecurityProtocol to use the appropriate protocol supported by your web server or change your Apache config to allow all protocols like this SSLProtocolall.

Kopaz

NOT use SSLv3 ? – Pickwickian

Answer 48

I ran into the same issue recently. My environment is running under .NET 4.6.1 with VB.NET. That is how I fixed it:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3
ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate)

and the util.ValidateServerCertificate function is:

Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
    Return True
End Function

Dragrope

Answer 49

If you don't want to, can't easily, or can't quickly patch your code, instead, you can force TLS 1.2 usage by your .NET code in the framework.

This isn't my app, but it helped hotfix our older .NET 4.5 app (running on Server 2008r2) to work again with Paypal Payflow Gateway. They must have started forcing connections over to TLS 1.2 on the payflow gateway callbacks between 6/25/18 and 7/8/18.

Details: https://github.com/TheLevelUp/pos-tls-patcher Download: https://github.com/TheLevelUp/pos-tls-patcher/releases

Yenyenisei

Answer 50

I had cert in store and on file. I tried to connect with file and got this error message. When I used the one in the store it worked. My best guess is that some sort of conflict arose as a result of the cert being in store when I wanted to use the one on file. (A different service on the same machine used the cert in store and I had developed a different service using the cert on file. Worked like a charm on dev until test).

Saccharify

Answer 51

I have been getting the same error on a .NET 4.5.2 Winform application on a Windows 2008 Server.

I tried the following fix:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1|SecurityProtocolType.Tls11| SecurityProtocolType.Tls12;

But that didnt work and the number of occurences of the error were still there.

As per one of the answers above, Is it mandatory to override the SchUseStrongCrypto key to the registry. Are there any side effects if i set this key.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Frequentation

Answer 52

These steps worked for me,for Windows Server 2012 R2.

1. First install any pending Windows Updates and Restart Server.
2. Go to SSLLabs https://www.ssllabs.com/ssltest/analyze.html
3. Enter the url of the site/api you are having problem to connect, wait a while until the test is completed
4. Go to 'Cipher Suites' section and read very carefully TLS 1.3 / TLS 1.2. There you will find the Cipher Suites accepted by the server.
5. Download IISCrypto GUI tool from https://www.nartac.com/Products/IISCrypto/Download
6. Enable TLS 1.2, if it is disabled. (using IISCrypto GUI Tool)
7. Enable additional/missing cipher suites you found in point No. 5 (using IISCrypto GUI Tool).
8. Restart Server.

Serology

Answer 53

Delete this option from registry helped me in Windows Server 2012 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangAlgorithms

Circumstantiate