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.
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.
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.
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.
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?
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.