Webroot renewal timeout - works on standalone only

if standalone works obviously its not a firewall or whatever else issue

But standalone no longer works.

it always works

I don't understand why you keep saying they work, when the LE logs show a connection problem:

I renewd today via standalone but i thought the title was clear enough.

I only shut the vhost down as theres really no need to stop anything else. Webroot option dont work

That can't be possible.
It would hit the same firewall problem.
[Apache is not a firewall - stopping it can't stop a firewall problem].

Unless...
What else do you "stop"?

What shows?:
systemctl status firewalld
sudo firewall-cmd --list-all

firewalld is notinstalled
edit

ufw status
Status: active

To Action From


22 ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
22 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
[

edit2
i have fail2ban but theres nothing in http jail only ssh jail

edit3

but again standalone works so my guess is your error is misleading. Its not a firewall issue

edit4

unless theres something with the provider but i doubt that. I dont know

You are going to need to prove that.

I told you i renewd the certificate today . But still it seems hard for you to believe. Don't you have logs ?

Most of the helpers here are unpaid volunteers. We don't have access to system logs.

But, just because once you could renew with standalone does not prove you do not have a firewall blocking certain IP. Let's Encrypt validates from multiple locations each time and the IP addresses often vary from one request to the next. Maybe you just got lucky the IP addresses LE used weren't blocked that one time.

Below is the public log that shows 3 certs from staging and one from production. I don't know how this helps but thought it worth posting anyway. There is also a successful challenge cache involved that can complicate such tests.

And, there was a gap of just over 3 months between the Jun26 expiration and the Oct03 new issuance

And I did say that you couldn't have - LOL.
My "proof" is that LE can't reach your site via HTTP [as denoted many times in this topic].

Now, where is your proof?
[that you did renew using HTTP-01 authentication (with --standalone option)]

Recall: I asked for "proof"
Saying "I told you so" isn't "proof".

What's the output of ss -tlpn src :80 ? (sudo should print more stuff)

Tell us both without and with standalone running.

(I'm not sure it'll work but you can try certbot renew --standalone --dry-run --debug-challenges, then ctrl-Z then fg to pull it back.)

Most of the people on this Community are just volunteers and only have publicly known info (such as certificate transparancy logs or connection attempts) or the info provided by the user.

ss -tlpn src :80
State                       Recv-Q                      Send-Q                                            Local Address:Port                                             Peer Address:Port                      Process
LISTEN                      0                           511                                                           *:80                                                          *:*                          users:(("apache2",pid=2421470,fd=4),("apache2",pid=2420580,fd=4),("apache2",pid=2420579,fd=4),("apache2",pid=2420578,fd=4),("apache2",pid=2419623,fd=4),("apache2",pid=2419622,fd=4),("apache2",pid=2419620,fd=4),("apache2",pid=2419489,fd=4),("apache2",pid=2419471,fd=4),("apache2",pid=2419412,fd=4),("apache2",pid=2419408,fd=4))
Waiting for verification...
^Z
[1]+  Stopped                 /usr/bin/certbot renew --standalone --dry-run
root@localhost:~# ss -tlpn src :80
State                       Recv-Q                      Send-Q                                            Local Address:Port                                             Peer Address:Port                      Process
LISTEN                      3                           5                                                             *:80                                                          *:*                          users:(("certbot",pid=2421797,fd=8))

by the way here what i got after i fg:

/usr/bin/certbot renew --standalone --dry-run
Challenge failed for domain benedicte-pavageau.com
Challenge failed for domain www.benedicte-pavageau.com
http-01 challenge for benedicte-pavageau.com
http-01 challenge for www.benedicte-pavageau.com
Cleaning up challenges
Failed to renew certificate benedicte-pavageau.com with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/benedicte-pavageau.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: benedicte-pavageau.com
   Type:   connection
   Detail: 172.105.247.238: Fetching
   http://benedicte-pavageau.com/.well-known/acme-challenge/1jN3vhYw37tRFrj7g2j4ycVWXaWCmEzCmHRsxdZMU3w:
   Timeout after connect (your server may be slow or overloaded)

   Domain: www.benedicte-pavageau.com
   Type:   connection
   Detail: 2a01:7e01::f03c:93ff:fe31:e388: Fetching
   http://www.benedicte-pavageau.com/.well-known/acme-challenge/4ojkG5t1eI6nJCrHIeK-wuYcc7T5LEihjAO1JehiPfQ:
   Timeout after connect (your server may be slow or overloaded)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

But THEN immediately after when i retried : /usr/bin/certbot renew --standalone --dry-run

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/benedicte-pavageau.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Simulating renewal of an existing certificate for benedicte-pavageau.com and www.benedicte-pavageau.com
Performing the following challenges:
http-01 challenge for benedicte-pavageau.com
http-01 challenge for www.benedicte-pavageau.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/benedicte-pavageau.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/benedicte-pavageau.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

And again, unless there's something with linode servers, but i already installed many of them and renewal always worked

[edit] And there's more, that sounds crazy to me that ip from webroot would be blocked, and not the one from standalone, as we could assume they both from the same range.

And even if not, why the ip would be blocked in the first place ? As i recall, from the beginning i need to use standalone

As a reminder , the cron looks like this

43 1 * * * /etc/init.d/apache2 stop
43 1 * * * /usr/bin/certbot renew --standalone --quiet >> /tmp/error.log 2>&1
45 1 * * * /etc/init.d/apache2 restart

I don't want to shut the server down for two minutes straight

[edit] even if its not facebook

and what i meant when i said errors where misleading is look at these :slight_smile:

 /usr/bin/certbot renew --webroot --webroot-path /usr/share/wordpress --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/osteopathe-brusquant.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Simulating renewal of an existing certificate for osteopathe-brusquant.fr and www.osteopathe-brusquant.fr
Performing the following challenges:
http-01 challenge for osteopathe-brusquant.fr
http-01 challenge for www.osteopathe-brusquant.fr
Using the webroot path /usr/share/wordpress for all unmatched domains.
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/osteopathe-brusquant.fr/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/osteopathe-brusquant.fr/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 /usr/bin/certbot renew  --webroot-path /usr/share/wordpress --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/osteopathe-brusquant.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Simulating renewal of an existing certificate for osteopathe-brusquant.fr and www.osteopathe-brusquant.fr
Performing the following challenges:
http-01 challenge for osteopathe-brusquant.fr
http-01 challenge for www.osteopathe-brusquant.fr
Using the webroot path /usr/share/wordpress for all unmatched domains.
Waiting for verification...
Challenge failed for domain osteopathe-brusquant.fr
http-01 challenge for osteopathe-brusquant.fr
Cleaning up challenges
Failed to renew certificate osteopathe-brusquant.fr with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/osteopathe-brusquant.fr/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: osteopathe-brusquant.fr
   Type:   connection
   Detail: 172.233.248.74: Fetching
   https://osteopathe-brusquant.fr/.well-known/acme-challenge/gBfbjhteJDG83WXfIz2HM4wsvKir9GkKjpGcvI8p8i8:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

although the truth is, there's a parse failure right ?

That is a terrible plan.
Stopping and restarting Apache can be done by certbot using --deploy-hook.
And it will only do so when the cert actually needs to be renewed - not everyday.

That said, I don't see where you stopped Apache and still feel like the renewals shown are based on previously cached authentication - not anything done today.