Renewal Script Not Renewing

Greetings. I set up LetsEncrypt on my server… about 60 days ago. Everything was running well. My own php renewal shell script runs twice a day. It runs the following to renew all certs:
exec(‘certbot renew --deploy-hook “apachectl graceful”’);

For the past 10 days, I’ve had several domains that had less than 30 days left to expiration. I am 100% sure that my script was running twice a day. Yet nothing was being renewed. My script was being run via launchd (not cron). It is running as root, though I added a debug log so I can verify that next time the script runs.

… but here’s the thing. If I run my script manually through the terminal, it runs and renews all the certs! So why would the exec( ) call above run different when my script is run via the terminal versus being called by launchd? The only thing I can think of is that launchd is not actually running my script as root. I’ll know the answer to that soon enough. But I suspect I’m not the first person to run in to this problem.

Edit: To be clear, because all my certs are new, this renewal script has never worked as this past week is the first time it would have done any actual renewing.

I have a lead from a mac irc chat. The problem may very well be that certbot is not in root’s path when my script is being ran by launchd. So I might just need to specify the full path to certbot in my php script. You can also specify the working path in the launchd plist but I’d rather leave that simpler and just have the full path in the exec( ) call.

I’ll know tonight if that’s what the problem is. And I’ll know in 3 days if it’s fixed, when my next cert expires.

Update: Captured stderr from my script, and it couldn’t find certbot. So it does seem that putting the full path in my script is the solution. I’ll know in 3 days time, when my next cert will have less than 30 days left. If it renews, then now I know, launchd scripts need full paths (or a working directory explicitly set in the xml config, but using full paths is easier)

1 Like

Fixing one problem revealed another. Still not sure if my script is working because it was unable to renew my current sub-30 day certificate. However I don’t understand why.

It is giving me this as the output from the renew call:

Missing command line flag or config entry for this setting:
Select the webroot for

But the thing is, I am not. This is the end of the command I created this certificate with:

-w /webfolder/macfixer/rss -d -d -d -d -d

It doesn’t seem to like the last one for some reason. It was happy with this command when I created the cert. It is currently working fine. What is the deal with that. Is certbot renew implementing some kind of “four subdomains per webroot” limit that it does not implement when you’re creating? There are a bunch of other domains and webroots in this specific certificate, but only the very last one is having a problem.

Edit: Well I found the domains-per-cert limit and it is 100. I have 13, so that’s not the problem.

Ok I found the --dry-run command and let it rip. It gave me the same error as before, and an extremely similar error for another domain. Where the last-specified sudbomain complains that a webroot wasn’t specified. When not only was it specified, but it MUST be specified because it’s the last domain in a list of many, so it should use whatever the most previous defined webroot is, right?

Also I just changed one of the webroots on this second cert, so I just ran the certbot certonly command and it had no errors. Then immediately afterwards, ran certbot renew --dry-run and it choked.

Here is the command I created the (second problem domain’s) cert with:

certbot certonly --cert-name --webroot -w /webfolder/whatsmyip/www/random-website-machine/random-machine-subdomain/ -d -w /webfolder/whatsmyip/www -d -d -w /webfolder/whatsmyip/pixels -d -w /webfolder/whatsmyip/m -d -w /webfolder/whatsmyip/touch -d -w /webfolder/whatsmyip/t -d -d -w /webfolder/whatsmyip/xxx -d

Cert was created fine, then gives this error on attempt to renew:

Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: Missing command line flag or config entry for this setting:
Select the webroot for
Choices: [‘Enter a new webroot’, ‘/webfolder/whatsmyip/m’, ‘/webfolder/whatsmyip/pixels’, ‘/webfolder/whatsmyip/t’, ‘/webfolder/whatsmyip/www’, ‘/webfolder/whatsmyip/touch’, ‘/webfolder/whatsmyip/www/random-website-machine/random-machine-subdomain’]

What do you make of this?

Could you paste the contents of /etc/letsencrypt/renewal/ here?

Sure here you go:

# renew_before_expiry = 30 days
version = 0.33.1
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/
# Options used in the renewal process
account = 6287d661c4bf637abe987eab0f24578a
authenticator = webroot
webroot_path = /webfolder/whatsmyip/www/random-website-machine/random-machine-subdomain, /webfolder/whatsmyip/www, /webfolder/whatsmyip/pixels, /webfolder/whatsmyip/m, /webfolder/whatsmyip/touch, /webfolder/whatsmyip/t, /webfolder/whatsmyip/xxx
server =
[[webroot_map]] = /webfolder/whatsmyip/www/random-website-machine/random-machine-subdomain = /webfolder/whatsmyip/www = /webfolder/whatsmyip/www = /webfolder/whatsmyip/pixels = /webfolder/whatsmyip/m = /webfolder/whatsmyip/touch = /webfolder/whatsmyip/t = /webfolder/whatsmyip/t is not in the webroot_map section, though the webroot path for it is in the webroot_path list. What is that about?

Not a clue, perhaps a bug in certbot. You might want to try to add it to the webroot_map manually, seeing the many examples in it already, I’m sure you’ll figure out how to do that :stuck_out_tongue:

Before I start manually editing config files, I’d like to fully understand what [[webroot_map]] actually is. Is it supposed to list every individual host contained in the cert? Or just every unique webroot with the first host for that webroot? Or some other option? On the first cert that won’t renew, none of the subdomains in the last defined reboot, all 5 of them, are not in it’s .conf file at all.

Editing .conf file seems like a sketchy way to try to solve this problem, no? Will certbot overwrite my changes ever?

As far as I understand it, looking at one of my own renewal configuration files, it lists all of the hostnames in the cert with the used webroot as the value. If a few hostnames have the same webroot, you’ll notice those identical webroots will be used multiple times: = /path/to/A = /path/to/A = /path/to/B

Sure, it’s a sketchy way. But if you ran the command like you did, with the webroot path and hostname, and it didn’t end up in the renewal config, I don’t know another way to add it. I’m not a certbot developer, so not really a clue on how to debug this.
Further more, if adding it to the renewal configuration file doesn’t fix your problem, we need to look somewhere else.

Perhaps if you run certbot again with all the -w and -d bits, but it shouldn’t change it with just a renew.

Please show:
certbot certificates

1 Like

For the two problem certificates, we have:

Certificate Name:
Expiry Date: 2019-05-27 15:15:53+00:00 (VALID: 28 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/


Certificate Name:
Expiry Date: 2019-07-27 07:11:41+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/

In both cases, the subdomains causing the renewal problems are correctly shown in the certificates above. And in real life, they are both working correctly.

Yes, the certificates are fine. Otherwise, certbot wouldn’t be failing: the domains are fetched from the certificate and the issue is with the webroot path not being correct. The latter is in the renewal configuration file (or should be).

Well, I edited my two .conf files manually and now certbot renew --dry-run does pass without errors. I’m kind of bummed that I have to manually edit these config files. That means I’m going to have to remember to edit them any time I change one of my certificates, which will happen periodically.

Also I really wish certbot had a ‘machine readable output’ mode so I could more easily determine what’s going on and if there are any errors from the wrapper script that runs it. Speaking of that script, it should run in a few hours and hopefully things do actually renew.

Ok one of my previously broken certs did renew after correcting the .conf file.

It might make sense to have certbot automatically do a --dry-run renewal test as soon as it creates a certificate to make sure it didn’t mess up it’s own config files. I’m going to have to make a note to do that myself from now on.

If this is a bug in certbot (perhaps there’s an unintended “limit” on how much hostnames are saved in the webroot_map?), it would be wise to file a bug report on GitHub:

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