IP from webserver blocked?

I am running Plesk Obsidian Web Host Edition 18.0.63 update 4
Public IP: 62.181.75.252

Have been having problems with renewing and creating new certificats for a while now.
Error message:
Could not obtain directory: cURL error 7: Failed to connect to acme-v02.api.letsencrypt.org port 443: Connection timed out (see libcurl - Error Codes) for https://acme-v02.api.letsencrypt.org/directory

I have been in contact with Plesk Support and they confirm that outgoing traffic rules are configured correct.

curl -v https://acme-v02.api.letsencrypt.org gives following output:
root@hosting:~# curl -v https://acme-v02.api.letsencrypt.org

  • Trying 172.65.32.248:443...
  • TCP_NODELAY set
  • Trying 2606:4700:60:0:f53d:5624:85c7:3a2c:443...
  • TCP_NODELAY set
  • Immediate connect fail for 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable
  • Trying 2606:4700:60:0:f53d:5624:85c7:3a2c:443...

Testing the same command from a server using a different public (but same subnet) ip gets no errors.

Can you please assist me?
Are my IP blocked?

Best Regards
Palsted

1 Like

Let's Encrypt almost never blocks IPs directly, and if they did the message you'd get wouldn't be "connection timeout". It's probably some misconfiguration on your system. We sometimes see systems that think that 172.65.x.x is "internal" (since it's near the 172.16.x.x-172.31.x.x block) even though it's a normal public IP. That's for IPv4; your "network unreachable" message probably means that your IPv6 isn't set up right either. Fixing either one would probably allow you to reach Let's Encrypt, though fixing both would be ideal.

If you run a traceroute of some sort to acme-v02.api.letsencrypt.org, you'll probably find it stop working somewhere really near your system, rather then on Let's Encrypt's end.

4 Likes

Thanks for the input!
Running traceroute on the server gives:
1 _gateway (172.16.1.254) 0.278 ms 0.171 ms 0.158 ms
2 static-62-181-96-186.cust.tele2.se (62.181.96.186) 1.960 ms 2.312 ms 2.048 ms
3 nrk310-sn-1.eth-trunk4s1031048.tele2.net (130.244.3.94) 1.044 ms 1.028 ms 0.978 ms
4 nkg140-sn-1.eth-trunk1.tele2.net (91.129.17.215) 3.673 ms 3.650 ms 3.637 ms
5 nrk316-agg-1.bundle-ether6.tele2.net (91.129.17.196) 3.649 ms 3.673 ms 3.625 ms
6 avk-cagg-1.bundle-ether49.tele2.net (91.129.16.156) 3.565 ms 3.652 ms 3.713 ms
7 avk-core-2.bundle-ether7.tele2.net (91.129.12.32) 3.524 ms 3.677 ms 3.682 ms
8 sk1-peer-1.ae2-unit0.tele2.net (91.129.14.114) 5.662 ms sk1-peer-1.ae1-unit0.tele2.net (91.129.14.112) 5.628 ms sk1-peer-1.ae2-unit0.tele2.net (91.129.14.114) 5.610 ms
9 * * *
10 * * *
11 * * *

So the stop is not near any system of mine.
Running traceroute on a server on the same subnet succeeds within 10 hops.

Will try to setup ipv6 and see if that fixes the issue..

/Per

3 Likes

What shows?:
traceroute -T -p 443 acme-v02.api.letsencrypt.org

3 Likes

It might also be worthwhile to compare connecting to (via curl & traceroute and such) the staging environment server acme-staging-v02.api.letsencrypt.org.

(Though I'm always hesitant to prescribe a test when I'm not sure what one would do with that information one way or the other.)

3 Likes

Hi,
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 _gateway (172.16.1.254) 0.308 ms 0.245 ms 0.190 ms
2 static-62-181-96-186.cust.tele2.se (62.181.96.186) 2.167 ms 2.457 ms 2.204 ms
3 nrk310-sn-1.eth-trunk4s1031048.tele2.net (130.244.3.94) 1.215 ms 1.098 ms 1.069 ms
4 nkg140-sn-1.eth-trunk1.tele2.net (91.129.17.215) 3.720 ms 3.723 ms 3.683 ms
5 nrk316-agg-1.bundle-ether6.tele2.net (91.129.17.196) 3.846 ms 3.766 ms 3.819 ms
6 avk-cagg-1.bundle-ether49.tele2.net (91.129.16.156) 3.513 ms 3.477 ms 3.540 ms
7 ssol1-core-2.bundle-ether7.tele2.net (91.129.12.12) 3.638 ms 3.835 ms avk-core-2.bundle-ether7.tele2.net (91.129.12.32) 3.757 ms
8 sk1-peer-1.ae2-unit0.tele2.net (91.129.14.114) 12.857 ms 12.936 ms 12.912 ms
9 * * *
10 * * *
11 * * *

30 * * *

traceroute to acme-staging-v02.api.letsencrypt.org (172.65.46.172), 30 hops max, 60 byte packets
1 _gateway (172.16.1.254) 6.936 ms 6.975 ms 6.871 ms
2 static-62-181-96-186.cust.tele2.se (62.181.96.186) 17.081 ms 17.283 ms 17.420 ms
3 130.244.3.94 (130.244.3.94) 14.893 ms 14.806 ms 14.979 ms
4 nkg140-sn-1.eth-trunk1.tele2.net (91.129.17.215) 18.025 ms 17.933 ms 17.865 ms
5 nrk316-agg-1.bundle-ether6.tele2.net (91.129.17.196) 17.876 ms 17.799 ms 17.715 ms
6 avk-cagg-1.bundle-ether49.tele2.net (91.129.16.156) 17.725 ms 16.602 ms 18.878 ms
7 ssol1-core-2.bundle-ether7.tele2.net (91.129.12.12) 18.698 ms 18.626 ms 18.555 ms
8 sk1-peer-1.ae1-unit0.tele2.net (91.129.14.112) 18.504 ms 19.621 ms 19.567 ms
9 * * *
10 172.65.46.172 (172.65.46.172) 19.027 ms 19.243 ms 19.158 ms

Works like a charm.

Not sure how to proceed with this. Looks like my ISP is have trouble reaching 172.65.32.248 ( acme-v02.api.letsencrypt.org ) but has no problem with acme-staging-v02.api.letsencrypt.org (172.65.46.172).
But than again, using a Ubuntuserver with public ip in the same range as the webserver works fine.

1 Like

Do those command options show anything different for that endpoint or the staging one?

Because by default traceroute uses UDP. The -T in the above uses TCP. And, -p 443 matches the default HTTPS port

You may need to use
sudo traceroute -T -p 443 acme-v02.api.letsencrypt.org

5 Likes

Continuing the discussion from IP from webserver blocked?:

Have now been in contact with my ISP and they confirm that traffic from my end passes through thier nodes without problem. The problem occours later on in the chain but me nor them can se where.

Whould be interesting to se if the host behind http://acme-v02.api.letsencrypt.org could reach my server.

Also, is there an alternative to http://acme-v02.api.letsencrypt.org which I can use to initiate the process och requesting certificates?

Looks like it:

Detail: 62.181.75.252: Invalid response from http://hosting.rsdata.se/.well-known/acme-challenge/1Hzc5Xb45Ol9TNDQ8A6CcAEBQPlp2-8IMZbbSbEWr_k: 404

A 404 response is indeed invalid with regard to the ACME challenge, but the fact the ACME validation server actually got a 404 file not found (which is expected), means that it was successful in setting up a HTTP connection with the 62.181.75.252 IP address.

(Same for the staging environment by the way, above was on the production environment.)

There are other free ACME CAs out there, see e.g. ACME CA Comparison - Posh-ACME for a comparison. Personally not a fan of ZeroSSL and EAB makes it more difficult to use, but BuyPass, a CA from Norway, is a non-nonsense CA with certs with a longer lifetime.

4 Likes

There are several other Certificate Authorities that offer free certificates. BuyPass Go (--server https://api.buypass.com/acme/directory) and ZeroSSL (--server https://acme.zerossl.com/v2/DV90) are probably the easiest for trying things out. (Posh-ACME and AcmeClients.com from the author of Certify the Web offer some comparison charts.)

5 Likes

Is that specifically TCP traffic? As earlier your tests only used UDP.

Yes, this is an unlikely root cause but not impossible.

Still, as both Osiris and Peter suggested the fastest way to a solution is using a different CA like BuyPass

3 Likes

A post was split to a new topic: Connect to LE acme-v02 fails but acme-staging-v02 works

Tanks for your efforts to help me, much appreciated!
I have also been in contact with Cloudflare and got following response:

"172.65.32.248 is part of our anycast ranges, and the traceroute is expected. Can you please detail more on what is the issue client has when trying to reach acme-v02.api.letsencrypt.org?

Additional information, this is what the return path looks like.

128dm7:~$ mtr -zbwrc 10 62.181.75.252
Start: 2024-09-13T19:58:38+0000
HOST: 128dm7 Loss% Snt Last Avg Best Wrst StDev
1. AS13335 _gateway (162.158.180.1) 80.0% 10 1.6 1.8 1.6 1.9 0.2
2. AS1257 sk1-peer-1.ae31-unit0.tele2.net (130.244.200.32) 0.0% 10 1.3 4.0 0.7 13.3 4.1
3. AS1257 avk-core-2.bundle-ether16.tele2.net (91.129.14.113) 0.0% 10 3.9 3.7 3.6 3.9 0.1
4. AS1257 avk-cagg-1.bundle-ether2.tele2.net (91.129.12.33) 0.0% 10 3.7 3.9 3.6 5.0 0.4
5. AS1257 nrk316-agg-1.bundle-ether1.tele2.net (91.129.16.157) 0.0% 10 3.7 3.9 3.7 4.1 0.1
6. AS1257 nkg140-sn-1.eth-trunk2.tele2.net (91.129.17.197) 0.0% 10 3.7 3.7 3.7 3.8 0.0
7. AS1257 nrk310-sn-1.eth-trunk2.tele2.net (91.129.17.214) 0.0% 10 3.9 3.8 3.8 3.9 0.0
8. AS1257 130.244.3.95 0.0% 10 4.7 4.9 3.9 5.7 0.6
9. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0"

Not getting any wiser. All should be working according isp, cloudflare and destination server.

I am running PLESK on this server and Lets Encrypt has a very neat plugin that issues free certificates on the fly from the gui. Sadly there are no alternative that offers the same service.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.