Could not create SSL/TLS secure channel

J’essai de me connecter sur des sites certifiés par let’s Encrypt à travers un code C#. Pour chacun, j’obtient le résultat
“Could not create SSL/TLS secure channel”

Je peux lire des réponses en Anglais : oui

Mon nom de domaine est : N/A

J’ai exécuté cette commande :
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
var request = (HttpWebRequest)WebRequest.Create(“https://community.letsencrypt.org”);
request.Method = WebRequestMethods.Http.Get;
var response = (HttpWebResponse)request.GetResponse()

Elle a produit cette sortie :Could not create SSL/TLS secure channel

Mon serveur Web est (inclure la version) : N/A

Le système d’exploitation sur lequel mon serveur Web s’exécute est (version incluse) : windows server 2012 r2 datacenter

Mon hébergeur, le cas échéant, est :azure

Je peux me connecter à un shell root sur ma machine (oui ou non, ou je ne sais pas) :oui

J’utilise un panneau de configuration pour gérer mon site (non, ou fournit le nom et la version du panneau de configuration) : N/A

Hi @jlandrei

looks like this isn't longer possible.

Checking Letsencrypt via Ssllabs - SSL Server Test: community.letsencrypt.org (Powered by Qualys SSL Labs)

Only the following Cipher Suites are allowed:

But if I know it correct, Windows 2012 doesn't support one of these GCM suites. Same with the CHACHA20.

That was the reason I've switched to an EC certificate. There was a GCM-support.

Can you try (same command) to connect

https://check-your-website.server-daten.de/

to see, if that works?

1 Like

yes i can fetch this url with my code.
But all other url i tested don’t works even url of this forum itself.
It’s a huge issue for my company because we could lose some customers if we cannot access to their website.
Only websites with letsencrypt do not work properly

So it's correct: Windows 2012 supports GCM EC Cipher suites.

That's a problem of your too old Windows 2012.

Ssllabs warns, if CBC cipher suites are used. So a lot of websites have removed these cipher suites.

And Windows 2012 doesn't support RSA + GCM Cipher.

Additional: A lot of older Cipher suites (weak) are removed, same with Tls.1.0 and 1.1.

It's not a problem of Letsencrypt certificates. It's a configuration mismatch between the modern website and your too old client.

2 Likes

I generally start by running this tool in Best Practises mode, which will give you a generally working set of TLS cipher settings: Nartac Software - IIS Crypto

Also check that you have ISRG Root X1 installed under Computer Certificates > Local Machine > Trusted Root Certification Authorities, otherwise your machine will be unable to establish TLS connections with all sorts of services.

However, my machine is actually telling me that the certificate for community.letsencrypt.org has expired, so that could perhaps be a load balancing problem (or my browser is caching something):

2 Likes

Bonjour.

Nous avons rencontré un problème similaire, je vais poster ce que nous avons trouvé en anglais car cela pourrait servir à d'autres.

So we encountered a similar problem on some win10 clients while most of our customers had no problem. These particular clients were able to browse our website properly with edge / chrome so the IRSG Root X1 certificate was properly installed BUT still our application failed to established a secure connexion to the website api.

Today we found that windows maintained an expired R3 intermediate certificate and after we deleted it everything is back to normal. So i invite you to open the certmgr.mmc go to "certificates > intermediates certification autority > certificate" and verify if an R3 (or E1, X1, X3) expired certificate is listed, as you can see in the picture. If it is expired you can delete it (right clic > delete).

Maybe you're in the same situation and this can help you.

3 Likes

Sorry I forgot to mention this to you, after you install ISRG Root X1 it's a good idea to reboot to clear cached certificate chains.

3 Likes

Isn't that the "R3" intermediate shown though?
I did ask this question recently: Would trusting the "R3" intermediate short-circuit the authentication trust path and overcome the multiple (sometimes cached) versions of "ISRG Root X1"?
In this case, it seems like that did the trick.

Note: I don't like recommending to anyone that they should explicitly trust an intermediate...
But these are trying times!

Here is a post about it (3d ago):

Here is my roundabout question (in less exact wording - LOL):


Which has yet to be answered affirmatively... or proven to do so.

2 Likes

Sadly you can't control what other software are doing on the system, in our case that wasn't us nor our program that thrusted the intermediate.

1 Like

If a PFX file is constructed to include your certificate plus related intermediates, the intermediates will be installed in the certificate store under Intermediate Certification Authorities. Almost all software that creates a PFX (especially ACME tools) will include the intermediates.

3 Likes

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# socket connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue:

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
     SecurityProtocolType.Tls
     SecurityProtocolType.Tls11
     SecurityProtocolType.Ssl3;
 
//createing HttpWebRequest after ServicePointManager settings
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.