Webroot renewal timeout - works on standalone only

Help
63

No, a parse failure is a corrupt Certbot renewal file. That test shows an intermittent comms problem trying to reach your server using HTTP. That is, webroot worked once but not a second time.

Have you reviewed your LiteSpeed Cache for Wordpress settings? Both of these sites are hosted at linode and use this same caching system. I don't know specifically how this one works but often such cache systems are the first to see the inbound request and only proxy it back to, say, Apache when the item is not in the cache. If LiteSpeed Cache was getting "stuck" that could explain your results.

Have you tried resetting your LiteSpeed Cache? Have you tried asking Linode support about this? There are several ways to setup Wordpress with them. Maybe another option would be more reliable?

As further background, your osteopathe and benedicte domains both have IPv4 and IPv6 addresses. Let's Encrypt tries IPv6 first and may try IPv4 for certain IPv6 failures. So, based on the error message it looks like it did try both and they both failed.

64

osteopathe-brusquant.fr and benedicte-pavageau.com are both hosted in the same way. Same litespeed cache, same wordpress, same linode.

Only benedicte-pavageau.com cannot use webroot for renewal

what i wanted to show is in osteopathe-brusquant.fr case, only theres a timeout when --webroot option is not there along --webroot-path.

65

Test 1 Summary

Test 2 Summary

Oh, I now see the second command omitted --webroot.

But, this doesn't show what you think it does. It shows webroot succeeding and then webroot failing.

The renew command relies on the options in the /etc/letsencrypt/renewal/ folder config file. Any command line options override what is in there. For normal renew you should not do that and rely just on the renewal config file.

In this test, the first command explicitly set --webroot. In the second you only set the --webroot-path.

However, webroot must be the default in your renewal conf file because both tests showed the Authenticator was webroot (see summary above)

We could confirm this by reviewing

/etc/letsencrypt/renewal/osteopathe-brusquant.fr.conf

A better testing method is to do below. Of course, for standalone to work you must stop Apache first. For webroot Apache must remain running. The cron you showed stopping apache first won't work with webroot for this reason.

certbot certonly --webroot -w (path) --dry-run -d (domain)
   or 
certbot certonly --standalone --dry-run -d (domain)

These are better tests so we don't have to infer what is in your renewal conf file. In a properly running system no options are needed with the renew command. It will just use the options in its conf file. The conf file is set to the options used in the last successful cert request.

66

Now what i want to show you is this:
While there's no problem with osteopathe-brusquant.fr as webroot renewal is perfecly working

cat /etc/letsencrypt/renewal/osteopathe-brusquant.fr.conf
# renew_before_expiry = 30 days
version = 1.12.0
archive_dir = /etc/letsencrypt/archive/osteopathe-brusquant.fr
cert = /etc/letsencrypt/live/osteopathe-brusquant.fr/cert.pem
privkey = /etc/letsencrypt/live/osteopathe-brusquant.fr/privkey.pem
chain = /etc/letsencrypt/live/osteopathe-brusquant.fr/chain.pem
fullchain = /etc/letsencrypt/live/osteopathe-brusquant.fr/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = 4e2b6e637f9d1194bc551a9d0a54818c
authenticator = webroot
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]
osteopathe-brusquant.fr = /usr/share/wordpress
www.osteopathe-brusquant.fr = /usr/share/wordpress

The issue is on benedicte-pavageau.com

cat /etc/letsencrypt/renewal/benedicte-pavageau.com.conf
# renew_before_expiry = 30 days
version = 1.12.0
archive_dir = /etc/letsencrypt/archive/benedicte-pavageau.com
cert = /etc/letsencrypt/live/benedicte-pavageau.com/cert.pem
privkey = /etc/letsencrypt/live/benedicte-pavageau.com/privkey.pem
chain = /etc/letsencrypt/live/benedicte-pavageau.com/chain.pem
fullchain = /etc/letsencrypt/live/benedicte-pavageau.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = 1bbea34b5ff906bb812e1a70b793fefb
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]
benedicte-pavageau.com = /usr/share/wordpress
www.benedicte-pavageau.com = /usr/share/wordpress

Where only standalone works

67

It is not. You showed its webroot failing in post #61

That standalone worked once is no proof it always works versus webroot never working

68

It's not working when --webroot option not there but only --webroot-path you forgot

you told its not linked to the --webroot option but i'm still telling you that if you pass the command with --webroot option and --webroot-path it works, while it fails with timeout if you pass only --webroot-path

69

I did not forget. You misunderstand what that means and I already explained that.

I don't think I can provide any further assistance. I wish you good luck.

70

You only describe the situation that explains absolutely nothing to me, and certainly not why there's a timeout when the --webroot option is not added. Thanks for wishing me good luck, i will need it.

71

How are those two [different] sites using the exact same webroot?
[one must be wrong]

72

(WordPress can do SNI internally)

73

You have to change the apache configuration because the challenge can't be redirected through ssl. Nonetheless sometimes it can pass through. Strange

74

What change did you make?

75

RewriteCond %{REQUEST_URI} !/.well-known/acme-challenge/

[Edit] lets encrypt - I have a rewrite in an apache httpd conf file, that breaks certbot. Is there a way to change it so that it doesn't? - Server Fault