I noticed that some of my servers (actually, two) are unable to connect to LE servers, it looks like those ip are banned for some reason, and my hosting provider says the same. Is it possible? If yes, then a) what could be the cause? b) how to unban?
It looks like this (and the same for int-x1, x2 and x4):
pys@zabbix:~/ > curl -v -4 ocsp.int-x3.letsencrypt.org
OSCP-stapling is activated in nginx on theese servers, actually thanks to it I have noticed this strangeness. But the traffic on servers is very-very small, so I think it’s unlikely could be some rate limits on LE side.
So the CDN is at least reachable via another route.
Maybe this ddos-guard.net is the culprit or transtelecom. If you are customer of ddos-guard, you may open a ticket there.
Don’t know if the LE-folks might have some insight here, too.
The hosting provider now says that these IP’s are being blocked by ISP on the basis of a court decision:
23.15.14.24 (because of this url: http://www.fun88.com/en-US/Home)
188.43.76.81 (unknown reason)
188.43.76.66 (unknown reason)
The oscp-servers are resolved to these IP’s (on my server). So, when I set up other IP (88.221.132.150) in my hosts file, the curl started to work. But nginx not, I think it doesn’t use hosts file.
The server and ISP are in the Russian jurisdiction. So it would be great if someone told LE, maybe they will stop using those IP’s.
Changes in /etc/hosts are relevant for most programs (that use the system's default resolver). Nevertheless, there might be some caching in the resolver library, try to restart nginx and check again.
I’ve disabled this directive, but still.
I think I’ll have to build some hacky workaround for this (like own dummy-always-the-same-ip-resolver) or just disable the stapling…
Thank you for help!
Can you escalate this to Akamai? According to post #5, Russian courts have ordered some Akamai IPs blocked for reasons unknown, (partly) affecting ocsp.
If that’s the reason, Akamai might also not want to cooperate by splitting off other services from the particular service targeted by the order, because that would decrease the collateral effects of the order, and so reduce pressures to reverse it. (Wikipedia, for example, dealt with this situation when different governments tried to block all of Wikipedia because of specific content, which sometimes led to pressure to reverse the blocking because people were upset about the collateral effects.) But I don’t know what Akamai’s policy on this situation is and I agree that it would be good for Akamai to be aware of it if they’re not already aware.
Yeah, you may be right. A policy like that might have exceptions, though.
FWIW, Russia apparently has a unified database of blocked resources. The 24/8 IP is in it (since 2016!) but not the other two IPs. Maybe they’re not blocked now, or the list isn’t as unified as it sounds.
@opiumfor, you could try to use some kind of foreign DNS lookup service (including a web-based one or an ISP looking glass server) to look up ocsp.int-x3.letsencrypt.org from another country, and then set an /etc/hosts record to point to the resulting IP address. As this is a CDN-backed service, the CDN (in this case Akamai) is generally willing to connect you to the appropriate service even if you use an IP address that is not the usual or intended one for your country.
As of right now, some IP addresses in the United States for this host are
I believe Akamai will connect you with the appropriate Let’s Encrypt OCSP service if you connect to ocsp.int-x3.letsencrypt.org at any of those IP addresses.
@opiumfor, Akamai’s tests are showing that transtelecom.ru has now unblocked the affected IPs. Could you please test again, and let us know the details if you’re still having trouble? Thanks for your patience!