Can't renew certificate

My domain is: myeasybox.ru

I ran this command: certbot renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/myeasybox.ru.conf


Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Attempting to renew cert (myeasybox.ru) from /etc/letsencrypt/renewal/myeasybox.ru.conf produced an unexpected error: ('Connection aborted.', error(101, 'Network is unreachable')). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/myeasybox.ru/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/myeasybox.ru/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)

My web server is (include version): Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version): CentOS Linux release 7.7.1908 (Core)

My hosting provider, if applicable, is: own server

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): certbot 1.0.0

Also my network provider didn't accept IPv6 protocol. And earlier I was can renew certificate without errors. But now i don't know what happens. I didn't change any server configurations.

I was trying disable firewalld service but it didn't help me.

BTW there is curl to letsencrypt and Google:

[root@i-13550-47103-VM ~]# curl -v acme-v02.api.letsencrypt.org

  • About to connect() to acme-v02.api.letsencrypt.org port 80 (#0)
  • Trying 172.65.32.248...
  • Connection timed out
  • Trying 2606:4700:60:0:f53d:5624:85c7:3a2c...
  • Failed to connect to 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable
  • Failed connect to acme-v02.api.letsencrypt.org:80; Network is unreachable
  • Closing connection 0
    curl: (7) Failed to connect to 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable

[root@i-13550-47103-VM ~]# curl -v google.com

  • About to connect() to google.com port 80 (#0)
  • Trying 173.194.73.113...
  • Connected to google.com (173.194.73.113) port 80 (#0)

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: google.com
Accept: /

< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Mon, 06 Jun 2022 14:59:15 GMT
< Expires: Wed, 06 Jul 2022 14:59:15 GMT
< Cache-Control: public, max-age=2592000
< Server: gws
< Content-Length: 219
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
<

301 Moved

301 Moved

The document has moved here. * Connection #0 to host google.com left intact

Server IP is 195.209.41.37
Maybe it's blocked by Let'sEncrypt?

Maybe...
Maybe not...

Please show:
curl -v google.com

2 Likes

I alredy show it at my topic but I can do it again :wink:

[root@i-13550-47103-VM ~]# curl -v google.com

  • About to connect() to google.com port 80 (#0)
  • Trying 173.194.73.102...
  • Connected to google.com (173.194.73.102) port 80 (#0)

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: google.com
Accept: /

< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Mon, 06 Jun 2022 15:35:19 GMT
< Expires: Wed, 06 Jul 2022 15:35:19 GMT
< Cache-Control: public, max-age=2592000
< Server: gws
< Content-Length: 219
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
<

301 Moved

301 Moved

The document has moved here. * Connection #0 to host google.com left intact
1 Like

Interesting that you're failing to connect to Let's Encrypt over IPv6, but succeeding connecting to Google over IPv4. I would have expected them to just be dual-stacked, though maybe Google is "smart" and tries to not resolve IPv6 addresses for you if it thinks your IPv6 is broken.

How about trying Let's Encrypt over v4, and Google over v6, to compare?

curl -I6v google.com
curl -I4v acme-v02.api.letsencrypt.org

And in general check that your IPv6 connectivity is working.

5 Likes

I think this is curls behaviour. Curl tries to connect to the LE API using IPv4 as wel as IPv6 and fails for both, but for different reasons. I'm not sure how Curl uses IPv4/IPv6 dualstack, but it might be something like "try IPv4 first and if it doesn't respond with success within XX microseconds, try IPv6". Further more, the DNS server of the host might have IPv6 connectivity, even if the host itself doesn't, so using DNS Google shouldn't be aware if the host has a working IPv6 connection or not. The other way around is valid too: a IPv4 only DNS server might provide working AAAA RRs for IPv6 enabled hosts.

5 Likes

Wow, I don't know how I missed that :upside_down_face:

@lestaff

2 Likes

Well, if the attempt to Let's Encrypt is over IPv6, then I think they'd need to check the server's IPv6 address. Though with a "Network is unreachable" message, I suspect it's a connectivity issue on the server's end of things and not Let's Encrypt's.

3 Likes

I'm not sure if a timeout is the result of a block from LEs side.

We could try to do a traceroute:

sudo traceroute -T -p 80 acme-v02.api.letsencrypt.org
sudo traceroute -T -p 443 acme-v02.api.letsencrypt.org
2 Likes

I ask my system engineer. Our network provider don't support ipv6 protocol. Last time I was renew certificates by ipv4 with no problem.

[root@i-13550-47103-VM ~]# curl -I6v google.com

  • About to connect() to google.com port 80 (#0)
  • Trying 2a00:1450:4010:c0e::65...
  • Failed to connect to 2a00:1450:4010:c0e::65: Network is unreachable
  • Trying 2a00:1450:4010:c0e::8b...
  • Failed to connect to 2a00:1450:4010:c0e::8b: Network is unreachable
  • Trying 2a00:1450:4010:c0e::71...
  • Failed to connect to 2a00:1450:4010:c0e::71: Network is unreachable
  • Trying 2a00:1450:4010:c0e::8a...
  • Failed to connect to 2a00:1450:4010:c0e::8a: Network is unreachable
  • couldn't connect to host at google.com:80
  • Closing connection 0
    curl: (7) Failed to connect to 2a00:1450:4010:c0e::65: Network is unreachable

[root@i-13550-47103-VM ~]# curl -I4v acme-v02.api.letsencrypt.org

sudo traceroute -T -p 80 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.1.1 (192.168.1.1) 0.282 ms 0.236 ms 0.204 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

sudo 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 192.168.1.1 (192.168.1.1) 0.196 ms 0.182 ms 0.170 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Hm, that's not a lot to work with.. Usually, one would at least see one hop from their own ISP on hop 2. You're getting timeouts for everything except your own home router.

Might be your router is blocking access, might be your ISP is blocking access, I dunno.

5 Likes

Might be 172.0.0.0/8 routing (blocked)!

6 Likes

This route is using by Organization. It can't be blocked.

Might be an incorrect routing issue then, because the IP range for the RFC1918 private IP space is 172.16.0.0/12.

If for some reason someone incorrectly routed the entire 172.0.0.0/8 range as private IP space, this would lead to errors when trying to connect to IPs within 172.0.0.0/8 but outside 172.16.0.0/12, such as the Cloudflare IP address 172.65.32.248 in this thread.

Please verify correct routing of the above mentioned ranges.

6 Likes

Famous last words...

Please show the output of:
sudo traceroute -T -p 443 google.com

4 Likes

[root@i-13550-47103-VM ~]# sudo traceroute -T -p 443 google.com
traceroute to google.com (74.125.131.138), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.269 ms 0.261 ms 0.326 ms
2 195.209.40.1 (195.209.40.1) 0.693 ms 0.634 ms 0.750 ms
3 195.209.63.118 (195.209.63.118) 0.827 ms 1.260 ms 1.050 ms
4 m9-j2_mg3001o_j1_n71.reconn.ru (195.209.63.102) 0.729 ms slv-j1_mg3021o_j2_ n72.reconn.ru (195.209.62.77) 0.404 ms m9-j2_mg3001o_j1_n71.reconn.ru (195.209. 63.102) 0.687 ms
5 195.209.63.255 (195.209.63.255) 0.703 ms 0.678 ms 0.697 ms
6 142.250.47.108 (142.250.47.108) 1.508 ms 1.431 ms 1.383 ms
7 108.170.250.146 (108.170.250.146) 0.639 ms 209.85.250.231 (209.85.250.231) 0.934 ms 209.85.250.163 (209.85.250.163) 0.640 ms
8 108.170.250.51 (108.170.250.51) 1.037 ms 142.251.237.156 (142.251.237.156) 15.882 ms 108.170.250.34 (108.170.250.34) 1.536 ms
9 172.253.66.116 (172.253.66.116) 19.057 ms 142.251.237.142 (142.251.237.142) 20.232 ms 172.253.65.159 (172.253.65.159) 19.652 ms
10 142.251.237.144 (142.251.237.144) 14.224 ms 74.125.253.109 (74.125.253.109) 15.141 ms 216.239.49.113 (216.239.49.113) 19.726 ms
11 216.239.56.113 (216.239.56.113) 19.950 ms 216.239.46.243 (216.239.46.243) 19.872 ms 216.239.58.65 (216.239.58.65) 19.663 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 lu-in-f138.1e100.net (74.125.131.138) 15.451 ms 15.499 ms *

A post was split to a new topic: Undefined - "same issue"

As you can see, there is no problem with the first few hops [when you are going to an IP 74.x.x.x].
But there is an immediate problem when you are going to IP 172.65.32.248.
That is a firewall blocking that destination OR a misconfigured router [that is incorrectly routing it inwards].

You can have more "fun" seeing which nets are allowed with:
sudo traceroute -T -p 443 -m 4 171.255.255.255
sudo traceroute -T -p 443 -m 4 172.0.0.0
sudo traceroute -T -p 443 -m 4 172.8.0.0
sudo traceroute -T -p 443 -m 4 172.16.0.0
sudo traceroute -T -p 443 -m 4 172.32.0.0
sudo traceroute -T -p 443 -m 4 172.64.0.0
sudo traceroute -T -p 443 -m 4 172.128.0.0
sudo traceroute -T -p 443 -m 4 172.255.255.255
sudo traceroute -T -p 443 -m 4 173.0.0.1

5 Likes

Problem solved. Thank you!
Our network in company was been bad configure and all 172.x.x.x was been locked by firewall for local users. Reconfigure this setting solve this problem.

5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.