My domain is: mail.ooo-ferrum.ru
I ran this command: dehydrated -c
It produced this output: #INFO: Using main config file /etc/dehydrated/config #INFO: Using additional config file /etc/dehydrated/conf.d/local.sh
ERROR: Problem connecting to server (get for https://acme-v02.api.letsencrypt.org/directory; curl returned with 35)
EXPECTED value GOT EOF
My web server is (include version): nginx/1.27.0
The operating system my web server runs on is (include version): CentOS Linux release 7.9.2009 (Core)
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): not using sertbot
Closing connection 0
curl: (35) TCP connection reset by pee
i change internet provider and get success.
This is not new installation, this configuration worked fine many years.
my ip address is 80.255.94.182.
maybe you added my ip address in blacklist or any other ideas?
thanks for you advice.
traceroute -T -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 gateway (192.168.51.1) 1.942 ms 1.915 ms 1.904 ms
2 192.168.51.254 (192.168.51.254) 0.139 ms 0.126 ms 0.129 ms
3 pool-80-255-94-181.is74.ru (80.255.94.181) 0.512 ms 0.487 ms 0.556 ms
4 * * *
5 * * *
6 * * *
7 31.173.147.13 (31.173.147.13) 3.588 ms 3.818 ms 3.810 ms
8 * * *
9 178.176.142.103 (178.176.142.103) 41.142 ms 40.705 ms 41.257 ms
10 172.65.32.248 (172.65.32.248) 40.112 ms 41.613 ms 41.502 ms
Doesn't look like anything out of ordinary. It could be a ban, but traffic from your server should've been substantial for that. I'll let other volunteers to poke further or to call for LE staff attention.
My server have two internet conection from diffirent providers.
If I use the main channel dehydrated doesn't work and i receive error, but if i use backup chanel all works fine and i can get renew certificate. I'm not a stupid, I called my main provider first, he tell me all works fine and not have any block or others problems, by the way Your TCP connection reset by remote side, it not in our scope of responsibility. and I am here
What is the role of the site https://api.buypass.com/acme/directory?
it is not available from any internet provider that I have.
But the certificate is renewed normally using only a backup provider
traceroute using ipv4 get success on both chanels, main and backup.
main chanel
traceroute -T -4 -n -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 192.168.51.1 1.267 ms 1.243 ms 1.227 ms
2 192.168.51.254 0.098 ms 0.101 ms 0.081 ms
3 80.255.94.181 0.616 ms 0.606 ms 0.591 ms
4 * * *
5 * * *
6 31.173.147.13 3.320 ms 3.385 ms 3.395 ms
7 * * *
8 178.176.142.103 41.219 ms 40.726 ms 41.775 ms
9 172.65.32.248 42.009 ms 41.737 ms 41.101 ms
Backup chanel
traceroute -T -4 -n -p 443 acme-v02.api.letsencrypt.org
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 192.168.51.1 0.975 ms 0.939 ms 0.916 ms
2 192.168.51.254 0.185 ms 0.186 ms 0.176 ms
3 212.57.162.85 6.620 ms 7.664 ms 6.620 ms
4 * * 87.226.151.94 8.114 ms
5 * * *
6 95.71.2.226 32.152 ms 31.000 ms 30.592 ms
7 * 172.68.8.51 32.754 ms *
8 172.65.32.248 29.400 ms 30.231 ms 31.987 ms
BuyPass is another ACME Certificate Authority. I was checking your connection to it to see if you had problems just with Let's Encrypt or connecting to other similar services. And, your connection to it failed.
What do these show? These are 2 other Certificate Authorities
Often with inconsistent network routing problems they resolve on their own after a short time. The network carriers eventually discover the problem on their own.
Closing connection 0
curl: (7) Failed to connect to 2a03:522:1111:162::162: Network unavailable
not available
I think the error is "NSS error -5961 (PR_CONNECT_RESET_ERROR)"
is not related to routing, it is blocking on the LE side or poorly configured DPI along the traffic path. Or something like that