Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
Is this still ongoing and consistent?
Please show the IP resolved for acme-v01.api.letsencrypt.org.
It seems to be working fine from where I'm sitting; at least to IP 23.32.132.37.
if the ACME endpoint also shares an IP address on Akamai with a service that the Russian government is trying to block Internet users from accessing. (This is a different symptom than the person in that thread reported, though.)
[root@web ~]# traceroute acme-v01.api.letsencrypt.org
traceroute to acme-v01.api.letsencrypt.org (2.23.157.115), 30 hops max, 60 byte packets
1 80.250.215.61 (80.250.215.61) 0.187 ms 0.263 ms 0.217 ms
2 10.129.0.15 (10.129.0.15) 1.097 ms 1.008 ms 1.193 ms
3 176.74.8.80 (176.74.8.80) 17.594 ms 17.520 ms 17.516 ms
4 10.128.0.1 (10.128.0.1) 2.321 ms 2.341 ms 2.345 ms
5 mskn06.msk112.transtelecom.net (217.150.45.178) 3.085 ms 3.113 ms 3.198 ms
6 transtelecom-ic-303467-s-b3.c.telia.net (213.248.99.222) 23.792 ms 21.535 ms 22.970 ms
7 s-b3-link.telia.net (213.248.99.221) 23.265 ms 21.702 ms 22.960 ms
8 2.23.157.115 (2.23.157.115) 22.703 ms 22.664 ms 21.310 ms
Note that the IP addresses that I offered in the other thread were for ocsp.int-x3.letsencrypt.org rather than acme-v01.api.letsencrypt.org, although both are hosted by Akamai. (CDN IP addresses intended for use with one hosted service won't necessarily work for other services hosted by the same CDN, although they might.) A few IP addresses that I can see for acme-v01.api.letsencrypt.org from the United States are
but if I change the ip-address on the same machine from another subnet everything works fine. The route is the same. (see the attachment)changeIP.txt (4.1 KB)
It seems that one subnet is blocked from accessing 23.77.91.5:443 while the other is not.
This does not appear to be a certificate issue nor a renewal configuration issue.
It seems more like a firewall/network related issue - either at your end or somewhere along the path; hard to say and even harder to troubleshoot when you not anywhere in that path.
Sorry…
But maybe someone else here can help troubleshoot this.
all thanks, the problem was solved. On our node equipment was exposed mtu 1496. Somewhere on the road there was no support for fragmentation, probably in my side.