Certify the Web Cannot create secure channel error

Help
1

We have the same thing happening on all of our Windows server Standard 2016/IIS 10.0.14393.0 VMs that use CertifyTheWeb as an ACME client. We also have a Windows Datacenter 2022 VM with IIS 10.0.20348.1 and CertifyTheWeb and it is working fine. Differences are the OS version, the webserver version, 2022 has TLS 1.3 support with 2 cipher suites that 2016 does not have, and the IP is in a different range (different server location). We confirmed port 80 is open and accessible on all servers. Running a curl to the API url does not result in an error.

The error in the client is:

2025-05-29 14:39:01.075 -04:00 [INF] Requested identifiers to include on certificate: (redacted)
2025-05-29 14:39:01.975 -04:00 [ERR] Exception not handled: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

  • at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)*
  • at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)*

The errors started yesterday (5/28) around 6pm east coast US time.

We have 700+ LE SSLs that have been working fine using this software. No configuration changes have been made to the servers or software (including updates to the OS). CertifyTheWeb is the latest version.

Thanks

1 Like
2

Hello @ICND, welcome to the Let's Encrypt community. :slightly_smiling_face:

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:

Had you opened this thread in the Help section, you would have been provided with a questionnaire. In any case, all the answers to this questionnaire are required:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Thank you for assisting us in helping YOU!

3

I moved your post into its own thread. Maybe it will have same reason as that other thread but it is usually best if everyone has their own thread.

And, your symptom is different in that your curl worked but their request failed with a closed connect. This points to different underlying causes.

1 Like
4

Thanks @MikeMcQ! :slight_smile:

1 Like
5

My post was a reply to the original poster and no questionnaire was offered.

I ran this command: I am using a GUI client not running any commands manually. This is for the renewal of exisitng LE SSLs and for the issuance of new LE SSLs.

It produced this output: 2025-05-29 14:39:01.075 -04:00 [INF] Requested identifiers to include on certificate: (redacted)
2025-05-29 14:39:01.975 -04:00 [ERR] Exception not handled: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

  • at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)*
  • at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)*

My web server is (include version): IIS 10.0.14393.0

The operating system my web server runs on is (include version): Windows server Standard 2016

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): Yes administrator command line access

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): CertifyTheWeb 6.1.5.0

3 Likes
6

No worries, I didn't ask for one. Personally I'm not really sure where to go with this. May need to wait for @webprofusion the principal for Certify the Web. Shouldn't be too many more hours before their workday starts.

Let's Encrypt hasn't announced any recent changes regarding minimum cipher requirements or TLS levels to connect to the API URL. Maybe it is related to the older system you are running. I just don't know enough to help sort that.

1 Like
7

No, but from looking at Certificate Transparency logs it looks like they switched from RSA to ECDSA keys last week. I would expect Windows 2016 to be able to handle that fine. But it certainly looks like a recent change on the Let's Encrypt side.

Their API Announcements usually are much more around their validation connections, they don't do much announcing of changes to the API endpoint, sometimes not even even when I've or others have asked about it. Though sometimes they have.

The fact that the post this was split off of was also Windows Server 2016, and also started having problems connecting to the API at about the same time, is… awfully suspicious.

4 Likes
8

I agree very suspicious. One difference is this person said a curl worked whereas the other one's curl got a closed connect.

I know on some Windows systems the curl maps onto Powershell invoke-webrequest. So, maybe one of them does and one does not? I don't know Windows TLS well enough to step in on that. Your thoughts?

2 Likes
9

I also don't know enough about Windows TLS. But yes, "curl" can mean many different things on Windows depending on version and what one has installed. And it wouldn't shock me if some versions of that didn't use the same TLS library as win-acme or Certify the Web did, sure.

My brief web searching has turned up the list of out-of-the-box enabled cipher suites for Windows 2016 (linked from this page, which indicates it's the same as Windows 10 1607), which sure looks like it should work with what the API serves, having TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 right at the top of both lists. It may be a common "hardening" technique to change the list of enabled cipher suites, and it wouldn't shock me if there's some common configuration that assumed an RSA-only world (kind of like the cases we found on Windows when DST Root X3 expired that didn't allow for auto-updates of the trust store and so people had problems switching to ISRG Root X1). But now I'm just speculating.

3 Likes
10

Hmm, we did replace the webserver VMs last week, which got new certs. And of course certbot defaults to ECDSA now.

So that's definitely a change, though I'm surprised to hear of an issue

4 Likes
11

I would think that changing the API endpoint from RSA to ECDSA is big enough that it should have an API Announcement and be in staging for a bit for people to be able to test. I'm not surprised that something would have an issue with it. Though I wouldn't have guessed Windows 2016 as being one of the platforms that would.

5 Likes
12

That was it.

I fired up nartac iis crypto 4 and added these 2 cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Rebooted the test server and all SSLs renew normally now.

Thank you very much for that info on the cipher suite change. I had wondered about that and searched for info on it but did not find anything. My google-fu must have been weak today.

6 Likes
13

I'm not familiar with "nartac" (I haven't administrated Windows servers in a very long time), is that something you've used to disable allowed cipher suites from what Windows has as a default, and now you've just re-enabled them? I'm trying to understand how likely this is to affect other people.

2 Likes
14

Doing a little more research, it looks like it's "best practices" configuration includes both RSA and ECDSA, so hopefully this won't be a widespread problem.

1 Like
15

Yep - nice little GUI for setting crypto on Windows servers.

When I choose the best practices template in ours (the latest version 4) it does not include those two for some reason. I have to check the boxes for them manually.

I have read about a few people having this issue since last night so we must not have been the only ones.

Thanks again.

3 Likes
16

What's wrong with supporting both ECDSA and RSA?

Using sslscan it seems acme-v02.api.letsencrypt.org currently only supports ECDSA:

Preferred TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Accepted  TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Preferred TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256     Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384     Curve 25519 DHE 253

(From the TLSv1.2 suits that is, not sure how to interpret the TLSv1.3 ciphers..)

2 Likes
17

Hi, just to confirm - older versions of Windows Server, especially those upgraded in place from Server 2008 etc occasionally do not support (automatically) ECDSA cipher suites with TLS1.2. So yes, you do need to have an RSA leaf available to talk to those ones.

For Certify The Web we pay cloudflare $10 a month for a "universal certificate" (serving RSA or EC depending what the client can use) so those older clients can still talk to our API, but obviously we don't control CA ACME APIs.

Registry changes or IISCrypto can be used to enable TLS 1.2 support (if not yet enabled) and related intersecting cipher suites.

4 Likes