Unable to connect to ACME server

Help
1

A simple Windows ACMEv2 client (WACS)
Software version 2.1.18.1119 (release, pluggable, standalone, 64-bit)
Connecting to https://acme-v02.api.letsencrypt.org/...
Initial connection failed, retrying with TLS 1.2 forced
Unable to connect to ACME server
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.)

Can you please check for my ip 95.177.163.118.
Let me know the status of my ip address becuase thought this ip address I am unable to connect the server.

2

IP blocks are very rare and this is not likely the cause of your problem. We should try some debugging of your comms setup first.

What kind and version of Windows are you running?

Can you show output of this (should work on modern Win systems)

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

and also show these. No need to show all output. Just the error message or the HTTP response and the "server:" response header value

curl -I https://cloudflare.com
curl -I https://google.com
3 Likes
3

I use Windows Server 2019 and ACMEv2 Client. I use these services from long time but getting this issue now.

C:\Users\Administrator>curl -Ivv https://acme-v02.api.letsencrypt.org/directory

  • Trying 172.65.32.248:443...
  • connect to 172.65.32.248 port 443 failed: Timed out
  • Failed to connect to acme-v02.api.letsencrypt.org port 443 after 21063 ms: Couldn't connect to server
  • Closing connection
    curl: (28) Failed to connect to acme-v02.api.letsencrypt.org port 443 after 21063 ms: Couldn't connect to server

C:\Users\Administrator>curl -I https://cloudflare.com
HTTP/1.1 301 Moved Permanently
Date: Sun, 19 May 2024 16:15:29 GMT
Content-Type: text/html
Content-Length: 167
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Sun, 19 May 2024 17:15:29 GMT
Location: https://www.cloudflare.com/
Set-Cookie: __cf_bm=dA1dim94M2gaz1XhxYIrbnFwvz8QaLoWZmubacY5_mo-1716135329-1.0.1.1-eTFr7y2T6YnGZn2dsYKlBjrzy4pzmEimkb3.rDYXtAFF9DIEEO5fSIVTc5ONEmyltVvt.A2Bkik7OwJ18BIPZA; path=/; expires=Sun, 19-May-24 16:45:29 GMT; domain=.cloudflare.com; HttpOnly; Secure; SameSite=None
Report-To: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=UC%2FcxQldtpE2zAjH3whgXroDOp09DgooIynJbr8sbjlLNWmQC%2BrjJe7Arflg5u5WQmpk47XUahk7gQQdjy%2FRkEkoVcVdDppUdMzg1iB%2F2Hc9Z35NN%2B%2F2ZXpH0g96S%2F67"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Strict-Transport-Security: max-age=15780000; includeSubDomains
Server: cloudflare
CF-RAY: 886562ce7ba011c0-MRS
alt-svc: h3=":443"; ma=86400

C:\Users\Administrator>curl -I https://google.com
HTTP/1.1 301 Moved Permanently
Location: https://www.google.com/
Content-Type: text/html; charset=UTF-8
Content-Security-Policy-Report-Only: object-src 'none';base-uri 'self';script-src 'nonce-Tn2Dj6KGo609TfQoPWv7Gg' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
Date: Sun, 19 May 2024 16:16:16 GMT
Expires: Tue, 18 Jun 2024 16:16:16 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 220
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

4

A timeout is not caused by a Let's Encrypt IP block.

Have you changed any firewall settings that would affect outbound connections to Let's Encrypt?

What does this show

tracert acme-v02.api.letsencrypt.org
2 Likes
5

Note that the IP addresses of cloudflare.com are (currently) outside of the 172.64.0.0/13 range of the ACME server. A routing issue with a too large range for the actual 172.16.0.0/12 is quite viable methinks.

1 Like
6

I agree. Which is why I requested the tracert. I thought that would be easier to interpret than a netstat command.

Yes, am aware. That and google were just checking if any other outbound connections worked. Just a first pass at eliminating possibilities.

2 Likes
7

I did not changed any firewall settings for outbound that affect it.

C:\Users\Administrator>tracert acme-v02.api.letsencrypt.org

Tracing route to ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248]
over a maximum of 30 hops:

1 * * * Request timed out.
2 <1 ms <1 ms <1 ms 10.235.232.26
3 2 ms 2 ms <1 ms 10.235.232.28
4 <1 ms <1 ms <1 ms 46.49.150.75
5 <1 ms <1 ms <1 ms 10.235.232.18
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

8

That's a very weird traceroute. It goes from 2 private IP address ranges (10.0.0.0/8) to a public IP from "Arabian Internet and Communications Services Company" to again an IP address of the same private IP range?

I'm quite certain it's not a block by Let's Encrypt/Cloudflare, but most likely a routing issue somewhere, perhaps even within your ISP.

1 Like
9

I talked to my server provider for regarding this issue and they said there is no any issue from their side.

10

Even on the browser unable to open this url
https://acme-v02.api.letsencrypt.org/

11

I agree with @Osiris this looks like a routing problem at your ISP

You could compare the tracert for the LE URL and one for

tracert cloudflare.com

Given how the tracert to the Let's Encrypt URL looked I am surprised you could curl to the cloudflare domain earlier. The LE API is behind Cloudflare's CDN.

If you show us the tracert to cloudflare.com maybe we'll see something. But, this looks like some unusual comms routing problem.

2 Likes
12

C:\Users\Administrator>tracert cloudflare.com

Tracing route to cloudflare.com [104.16.133.229]
over a maximum of 30 hops:

1 * * * Request timed out.
2 <1 ms <1 ms <1 ms 10.235.232.27
3 <1 ms <1 ms <1 ms 10.235.232.28
4 1 ms <1 ms <1 ms 46.49.150.75
5 <1 ms <1 ms <1 ms 10.235.232.18
6 1 ms 1 ms <1 ms 212.118.153.5
7 11 ms 11 ms 11 ms 84-235-127-75.saudi.net.sa [84.235.127.75]
8 14 ms 13 ms 12 ms 84-235-127-74.saudi.net.sa [84.235.127.74]
9 * * * Request timed out.
10 * * * Request timed out.
11 16 ms 39 ms 17 ms 10.188.197.166
12 15 ms 15 ms 15 ms 185.1.126.16
13 15 ms 14 ms 14 ms 104.16.133.229

Trace complete.

1 Like
13

This is where it starts to differ. The '212.118.153.5' IP belongs to Saudi Telecom. Looks like the routing between 46.49.150.75 (Arabian Internet & Communications Services) and them has a problem.

For some reason when accessing the Let's Encrypt server the packets do not cross over from one network to the other.

These can be very difficult to resolve. Sometimes they resolve by themselves over a couple days as these network providers find and fix them on their own (or from other customer complaints).

I'm not sure what to suggest other than starting with your ISP or hosting service and show them these two tracert results.

2 Likes
14

Ok, I understand. Now what should I say with my server provider? Because today I asked him and they replied there is no any issue from our side.
So technically what should I ask him?

1 Like
15

Show them the tracert that fails and ask why that happens. It doesn't get beyond that first network provider. Resolving these problems requires advanced comms skills and ability to work with these backbone network providers.

Your first level support at a hosting service is not likely to have that level of expertise. But, they should be able to escalate it internally to someone who does.

Maybe ask them to run the two tracert like you did (to acme-v02.... and to cloudflare.com). See if it fails the same on their machines as on yours.

If you can't resolve this you might try a different ACME Certificate Authority (like Google CA maybe). Maybe your provider's network won't have a problem reaching them. It's always better to have a properly functioning network routing but this might provide at least a temporary solution.

3 Likes
16

Thank you for review my issue. Again I try to talk with my server provider.

3 Likes
17

Good luck! You could also ask the provider to perform its own traceroute test and show you the result—if the problem is with the provider then this test should also fail (and should help to convince the provider that something is wrong).

I thought this point from @Osiris was interesting:

The range 172.16.0.0/12 is a private address space for personal and organizational LANs. The IP address 172.65.32.248 is outside of this range, but is rather close to it (with the private addresses ranging up to 172.31.255.255). If someone misconfigured a router to use a slightly larger version of 172.16.0.0/12 instead of the official one, that router would mistakenly believe that this Cloudflare address was part of an internal network rather than out on the public Internet.

1 Like
18

Yes, but there are multiple networks involved. Finding the right people at the right handoff is the trick.

2 Likes
19

I will discuss with my Server provider and ask them to make trace route. They did and replied that it's not blocking from our side. It is getting failed by any other company between us and Let's Encrypt.

They shared with me details of the trace. Kindly check the issue.
traceroute to ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248), 64 hops max, 52 byte packets

1 172.20.10.1 (172.20.10.1) 32.751 ms 3.122 ms 2.852 ms

2 * * *

3 192.168.1.1 (192.168.1.1) 58.405 ms * *

4 10.239.209.95 (10.239.209.95) 66.396 ms 52.661 ms

10.239.209.96 (10.239.209.96)  47.648 ms

5 * * *

6 * * *

7 * * *

He said his tracer stop at 10.239.209.96
Kindly check is ip with Let's Encrypt

20

The IP range 10.0.0.0/8 is a PRIVATE IP range (as mentioned earlier) and thus not routable on the global, public internet. And therefore there is nothing to check with Let's Encrypt.

Their first hop, 172.20.10.1, is also a private IP address from the private IP range 172.16.0.0/12 which can sometimes give trouble if not configured properly. If they are indeed using the 172.16.0.0/12 range incorrectly, this could lead to routing issues.

Unfortunately I don't know of any other website using IP addresses starting with 172 but NOT in the private IP range, such as the Let's Encrypt API. If I knew more of those public addresses, we could let you test more IP addresses.. Does anyone know of any other websites beyond the private IP range, but starting with 172?

1 Like