Suddenly getting 'Unable to connect to ACME server' today

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: northardenpcn.co.uk

I ran this command: wacs --emailaddress support@REMOVEDTOAVOIDSPAM.co.uk --accepttos --target manual --host www.northardenpcn.co.uk,northardenpcn.co.uk --manualtargetisiis --validation filesystem --validationmode http-01 --webroot PATHREMOVED\Public --keepexisting --installation iis --siteid 18 --installationsiteid 18

It produced this output:
ACME server https://acme-v02.api.letsencrypt.org/
No luck yet, attempting to force TLS 1.2...
Unable to connect to ACME server
IIS version 10.0
Running with administrator credentials
Scheduled task looks healthy
Please report issues at GitHub - win-acme/win-acme: A simple ACME client for Windows (for use with Let's Encrypt et al.)
Running in mode: Unattended
Target generated using plugin Manual: www.northardenpcn.co.uk and 1 alternatives
(Win32Exception): The message received was unexpected or badly formatted.
Wrapped in AuthenticationException: Authentication failed, see inner exception.
Wrapped in HttpRequestException: The SSL connection could not be established, see inner exception.

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

I can login to a root shell on my machine (yes or no, or I don't know): 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): No

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

All working fine until yesterday. One manual cert request failed with the above, then next was fine. Today all fail. Firewall is allowing the traffic out. Could https://acme-v02.api.letsencrypt.org/ be blocking us for some reason?

Thanks

Hello @Damo,

What kind of error message do they get from this command?

curl https://acme-v02.api.letsencrypt.org/directory
1 Like

You might also need to update win-acme to a more recent version; The "No luck yet, attempting to force TLS 1.2..." message was changed in version 2.1.14 which was released in 2021.

3 Likes

Have you recently had changes to your network configuration?

Because HTTP requests on port 80 cannot reach you. See: Let's Debug

And, HTTPS requests connect but with an invalid expired certificate for a different domain name. See: SSL Checker

Now, these are inbound requests to you and you are showing a problem with an outbound connection to the Let's Encrypt API server. But, this looks to me like something changed in your system.

2 Likes

Yet, interestingly I see this with curl

$ curl -Ii http://northardenpcn.co.uk/.well-known/acme-challenge/sometestfile -A "Mozilla/5.0 (compatible; Let's Encrypt v>
HTTP/1.1 404 Not Found
Content-Length: 1245
Content-Type: text/html
Server:
Permissions-Policy: accelerometer=()
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Strict-Transport-Security: max-age=15552000; includeSubdomains
Date: Thu, 29 May 2025 15:05:46 GMT
1 Like

curl : The underlying connection was closed: An unexpected error occurred on a receive.
At line:1 char:1

  • curl https://acme-v02.api.letsencrypt.org/directory
  •   + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], We
     eption
      + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
1 Like

And this is what I see using curl from the cmd.exe prompt with

Edition Windows 10 Pro
Version 2009
Installed on β€Ž7/β€Ž14/β€Ž2020
OS Build 19045.5854
>curl https://acme-v02.api.letsencrypt.org/directory
{
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "profiles": {
      "classic": "https://letsencrypt.org/docs/profiles#classic",
      "shortlived": "https://letsencrypt.org/docs/profiles#shortlived (not yet generally available)",
      "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
    },
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert",
  "s5PW7zj51Sk": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417"
}

I suspect a firewall, or Geo Blocking, TLS mismatch, or routing issue.

The firewall does allow http requests on port 80 but only for acme-protocol. I can see some of those being allowed through today. Not sure what Let's Debug is doing. Is there a way to see what IP address Let's Debug was using so I can see if I can find the logs?

2 Likes

Is this the first time for this domain name using HTTP Challenge? Just curious. The cert history for that domain only shows wildcard certs probably issued through Cloudflare Universal SSL.

Does your firewall have a log of rejections?

It is probably the same source IP as shown by a DNS query of letsdebug.net I don't know if L/D rotates its IP or similar but might be that.

Do you allow inbound ACME challenges from anywhere? "Home" page requests from certain geo locations redirect 301 just fine. See: Check website performance and response : Check host - online website monitoring

Back to the outbound problem

What does this show

curl https://www.cloudflare.com/cdn-cgi/trace
2 Likes

I concur with Mike! :slight_smile:
I definitely believe there is Geo Blocking happening, see here Permanent link to this check report.

See this link for way to handle this issue. Multi-Perspective Validation & Geoblocking FAQ

A post was split to a new topic: Certify the Web Cannot create secure channel error

Hello @ICND, welcome. :slight_smile:

Please open your own new Help topic.

while non-intuitive, 'acme-protocol' in FortiGate only means challenge traffic from LE(or other acme CA)'s validation traffic, not your connection to ACME API

I remember this because when they added new class in firewall menu(default blocking) they errored out on challenge not connecting to acme server

3 Likes

@Damo: Based on our discoveries in this possibly-related issue: Might you have configured your server to limit the enabled cipher suites, either through group policy or through software like "Nartac"? The Let's Encrypt API endpoint recently changed from using RSA to ECDSA, which most systems should support but some over-zealous "hardening" might have disabled ECDSA cipher suites on your server.

I'll also second the previous recommendation to make sure you're on the latest version of win-acme. Or you might want to switch to the newer simple-acme fork. But I don't think that'll help on its own, until you sort out why you can't connect to the Let's Encrypt API. Once you can connect to it, the error message should change if port 80 connectivity inbound to your system is still a problem, as some posters above think might also be a concern.

5 Likes

Just adding on to @petercooperjr comment. This powershell command should show you the TLS Cipher suites you have enabled.

At least, it did on a Windows client machine of mine :slight_smile:

(get-tlsciphersuite).name

Post the output of that if you need help knowing what to do

3 Likes

Hi Mike,
This sounds like it.
Output of that powershell command for us is...
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Thanks

@Bruce5051 @MikeMcQ
Some geoblocking is in place but we've seen and resolved issues with that in the past and not being able reach https://acme-v02.api.letsencrypt.org/ to start the process, even after I unblocked the range for that, was new. I whitelisted the IP for Let's Debug so that reports ok Let's Debug . It was still not getting a connection.
The answer below and in the linked thread about Cipher suites looks the likely culprit, so I'm looking at that now.
Thanks for all the quick replies here btw. Great community!

The default list of ciphers before we removed anything that SSLLabs said was weak was...

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

They all start with TLS, so none is exactly the same as those in the list in the linked post...

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

Also worth saying that enabling TLS1.2 needs to be done for Server Protocols and Client Protocols, if not already done, and you generally need a reboot to actually apply them after settings them.

Keep in mind also you are performing an outgoing https (tcp port 443) call to the Let's Encrypt API. Their HTTP validation is an incoming TCP port 80 connection, and the two are for different parts of the process.

1 Like