Renew fails (standalone)

Help
1

I have a problem with certificate renew using standalone.
When I try to run the renew with --dry-run it fails the challenge (as if the port 80 is closed), but the command to generate the certificate runs fine

sudo certbot certonly --standalone --preferred-challenges http -d myebooklibrary.eu

My domain is:
myebooklibrary.eu

I ran this command:
sudo certbot renew --dry-run

It produced this output:

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
  Domain: myebooklibrary.eu
  Type:   connection
  Detail: xx.xx.xx.xxx: Fetching http://myebooklibrary.eu/.well-known/acme-challenge/JSj3aPODId767soIuWE4P8xFCVSzIpndtdBnT4VkYlQ: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Failed to renew certificate myebooklibrary.eu with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/myebooklibrary.eu/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The operating system my web server runs on is (include version):
Fedora

2

I "fixed" the problem by using the dns challenge and the manual method with --manual-auth-hook
I created one script that adds the TXT record to the dns (using nsupdate) and one that deletes it.

I used a command similar to the one in the doc
certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /path/to/dns/authenticator.sh --manual-cleanup-hook /path/to/dns/cleanup.sh -d secure.example.com

Now the renew works!

3

Using the dns-01 challenge might have fixed your renewal, but you're aware your entire website is down for the public internet? At least from my point of view:

osiris@desktop ~ $ curl -LIv http://myebooklibrary.eu/
*   Trying 93.55.91.247:80...
* connect to 93.55.91.247 port 80 failed: No route to host
* Failed to connect to myebooklibrary.eu port 80: No route to host
* Closing connection 0
curl: (7) Failed to connect to myebooklibrary.eu port 80: No route to host
osiris@desktop ~ $ curl -LIv https://myebooklibrary.eu/
*   Trying 93.55.91.247:443...
^C
osiris@desktop ~ $

(Ctrl-C as it took too long, timeout.)

I can ping the host, but port 80 nor port 443 are working. Firewall perhaps?

1 Like
4

Yes, I know: I'm using ports different from 80 and 443 for the API services I'm hosting

5

Well, the http-01 challenge requires port 80, so if that port was intentionally blocked in the firewall, that would explain the problem with the standalone plugin.

2 Likes
6

The port is open, but I don't have any webserver listening on it.
Thats's why the command
sudo certbot certonly --standalone --preferred-challenges http -d myebooklibrary.eu
correctly create a valid certificate

7

The "No route to host" is a rather strange reply to a port that's simply not in use. Most (if not all) servers would reply with a "Connection refused", unless a firewall says otherwise. At least that's my experience.

Also:

Well, it didn't last time, otherwise you wouldn't have opened this thread :wink:

2 Likes
8

I ran the commands seconds apart:

  • I created the certificate with the command (and it worked)
    sudo certbot certonly --standalone --preferred-challenges http -d myebooklibrary.eu
  • I tested the renew with the command (and it failed saying port 80 can't be reached)
    sudo certbot renew --dry-run
  • I tried to recreate the certificate again with the command and chosing to get a new certificate even if it was still valid...and it worked.
    sudo certbot certonly --standalone --preferred-challenges http -d myebooklibrary.eu

EDIT: I removed the port forwarding rule for port 80 after I fixed the problem with the dns challenge, probably before you did your test (that would explain the 'No route to host').

9

"No route to host" usually means "this IP address is wrong."

3 Likes
10

How can the command
sudo certbot certonly --standalone --preferred-challenges http -d myebooklibrary.eu
work if the ip address is wrong?

11

It can't, and I can't reproduce the "no route to host" error. (It times out, as I would expect if port 80 isn't forwarded or nothing listens on it)

This is because port 80 is needed to do that.

This is because the authorization is still valid and isn't performed again for 30 days (a lot less in the future). Please don't do that again. Rate limits don't like that.

4 Likes
12

I understand that port 80 is needed, what I cannot explain is how port 80 worked for the first certificate creation, then didn't work 10 seconds later (without any change).
Thanks for your help.

1 Like
13

"no route to host" can also be send by firewalls and probably also routers, e.g. if the portmap is incorrect or absent. (It's just a specific ICMP reply.) Personally haven't seen that one, it usually indeed has to do with actual IP address routing.

If at your first trial the port 80 portmap was still present and there was no "no route to host" error at that time, I'm puzzled what was the issue. The ACME "Error getting validation data" error is a "catch-all" error: the ACME server couldn't fit the encountered error into a more meaningfull error. So that non-specific error doesn't help us either.

In any case you've got your certificate using the dns-01 challenge, that's the upside :slight_smile:

2 Likes
14

I'd like to see the renewal config file for that.

3 Likes