Is my server being blocked


#1

I am using the Certify application on Windows server 2016 to manage my certificates and have been renewing successfully for over a year with this

Recently I have found the application cannot communicate with the Lets Encrypt servers and gets the error “A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 184.87.187.237:443”

I have tried pinging 184.87.187.237 from my server and connecting to https://184.87.187.237 from a browser and both timeout.

I can access 184.87.187.237 from my office with no problems.

If my server IP has been blocked, how do I find out why and how do i resolve it?
I have put a ticket in with my hosting company to see if it is with their network, but my second server with them does not have this problem.

My server IP is 5.77.55.55


#3

Try also:
nslookup acme-v02.api.letsencrypt.org 8.8.8.8
nslookup acme-v02.api.letsencrypt.org 4.2.2.2
nslookup acme-v02.api.letsencrypt.org 208.67.222.220
nslookup acme-v02.api.letsencrypt.org 1.0.0.1

I get these IPs:
23.41.8.92
69.192.173.164
104.94.252.237

If you can https:// connect to any one of those IPs, you can “temporarily” override the DNS resolution (via /etc/hosts file entry) and force your connection to that “working” IP - while you wait for the problem to get fixed.


#7

Hi,

I do not believe let’s encrypt API endpoints blocked you (from akamai) since it would return an error page .

https://community.akamai.com/customers/s/article/Why-is-Akamai-blocking-me?language=en_US

Please do the following steps (from the troubled machine) to test your connection to akamai (as akamai provides the cdn for let’s encrypt API servers) and let’s encrypt.

  1. nslookup -q=txt whoami.ds.akahelp.net
    gives your DNS, IP, and ECS.
  2. curl http://whatismyip.akamai.com/ (or visit the website in your browser)
  3. nslookup acme-v02.api.letsencrypt.org
  4. tracert acme-v02.api.letsencrypt.org

Thank you


#9

I think the “redundancy” lacks “redundancy”; We need redundant redundancy! - LOL

If we connect to a single name that only returns a single (nearby) IP, that puts all eggs into that one basket for those nearby users.
When that basket is deemed “operational”, then too bad for those that can’t connect to it - “it must be their problem”. [that is the feeling the customer may be having]
I think we can do better than that; a lot better.

Maybe resolving the one name to multiple IPs or using multiple names that can inherently resolve to nearest IP and also any other IP (not the nearest IP) should greatly decrease any such failures.

And, since no private key information is ever sent to/from LE, maybe including the use of (multiple) global CDNs can ensure everyone gets connected. Unless I’m missing something a one-way MITM proxy doesn’t break/degrade the validation process.


#10

Especially when an IP is in the Akamai CDN blacklist (instead of the normal customer blacklist)… Although it’s rare, it might happen.


#11

Is it possible that you have firewall software on that machine that is blocking outbound connections? Are you able to successfully make requests to other HTTPS URLs from that machine?


#12

Sorry for not getting back earlier - it was overnight in the UK. Trace routes seem odd: From the problem server:

1 <1 ms <1 ms <1 ms 5.77.55.3
2 <1 ms <1 ms <1 ms 77.111.217.2
3 16 ms <1 ms <1 ms 77.111.212.96
4 <1 ms <1 ms <1 ms 77.111.212.93
5 3 ms 3 ms 3 ms 77.111.212.12
6 3 ms 3 ms 3 ms 77.111.212.78
7 6 ms 6 ms 5 ms mx01-xe0.0.2-thn.lon.nodefour.net [109.234.203.246]
8 7 ms 7 ms 7 ms 195.66.226.81
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.

and from a working server:

1 <1 ms <1 ms <1 ms 109.203.125.2
2 <1 ms <1 ms <1 ms 77.111.217.2
3 <1 ms <1 ms <1 ms 77.111.212.96
4 <1 ms <1 ms 1 ms 77.111.212.93
5 4 ms 3 ms 3 ms 77.111.212.12
6 3 ms 4 ms 3 ms 77.111.212.78
7 5 ms 5 ms 5 ms mx01-xe0.0.2-thn.lon.nodefour.net [109.234.203.246]
8 5 ms 6 ms 6 ms 77.111.212.45
9 6 ms 5 ms 6 ms e1-6-2.a00.londen03.uk.ra.gin.ntt.net [213.130.48.181]
10 6 ms 6 ms 6 ms ae-2.r02.londen03.uk.bb.gin.ntt.net [129.250.4.131]
11 5 ms 6 ms 9 ms ae-0.vodafone.londen03.uk.bb.gin.ntt.net [129.250.66.46]
12 8 ms 7 ms 6 ms ae2-xcr1.ltw.cw.net [195.2.24.129]
13 7 ms 7 ms 7 ms ae5-xcr1.slo.cw.net [195.2.24.33]
14 14 ms 15 ms 15 ms akamai-sl-gw.slo.cw.net [195.89.104.54]
15 9 ms 11 ms 9 ms a23-36-209-29.deploy.static.akamaitechnologies.com [23.36.209.29]

Trace complete.

so the blocking seems to be occurring after mx01-xe0.0.2-thn.lon.nodefour.net [109.234.203.246] which appears in both traceroutes.

I am going to escalate this with my hosting company to see it it is within the data centre.