"Missing command line flag or config entry..." Error

Help
#1

My domains are: stelvio.z.dk and dev.stelvio.z.dk

When I run certbot renew --dry-run all my certs are primed to renew – except the two for these domains which fail with a “Missing command line flag or config entry for this setting” error.

I have run certbot delete on these and tried generating new certs, but they still fail on the renewal dry run.

I am running Certbot under…

Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-8-cloud-amd64
Architecture: x86-64

My Certbot client version is 0.31.0.

I read there was a bug in this version that could account for this, but I when I apt-upgrade Certbot it insists I’m on the latest version.

I know the reason these are failing is due to a lack of any paths being written below [[webroot_map]]. All my other cert .conf files have these except for these two.

I could manually edit them and probably fix this for now, but I can’t help wanting to know why it’s failing, and would feel better knowing all the automated aspects worked as I prepare to cron the cert renewal.

So I hope it’s as simple as deleting the certs, upgrading Certbot and regenerating them. But maybe there is no upgrade, and the answer is manually edit them and then cross your fingers a future update fixes this.

Thanks for any pointers or advice.

#2

Certbot 0.31.0 is the newest version packages for Buster, but it’s not the newest version that exists. This bug was fixed in a later version.

Also, the fix can’t retroactively unbreak your renewal configuration files. You still have to do something about them. Fixed versions just won’t break them again.

If you’re comfortable manually editing the files, that’s the simplest way to resolve it (for now).

What happens is that, after you validate a name, Let’s Encrypt normally allows the validation to be reused for up to 30 days, without making you validate it again.

So, for example, if you run “sudo certbot certonly --webroot -w /example -d example.com” one day, and then run “sudo certbot certonly --webroot -w /example -d example.com -d www.example.com” a couple weeks later, you won’t have to validate example.com again (but you will have to validate www.example.com).

(It can also happen in other situations, of course, like using the --force-renewal to renew your certificates early, or deleting them and issuing new ones.)

The bug is that certain versions of Certbot forget to save the webroot_map settings for names that didn’t have to be validated.

The main workarounds for the bug are “don’t do that” and “don’t use the webroot plugin”.

You could also uninstall the Certbot package – but you probably shouldn’t delete /etc/letsencrypt/ – and install the most recent version of Certbot using certbot-auto. (And configure a systemd timer or cron job to renew your certs.) (certbot-auto is probably going to be discontinued eventually, but it’s good for now.)

#3

Thanks for this. No problem editing these manually. Just couldn’t understand what the cause of the bug was, and further why removing all records of the cert and regenerating them didn’t solve it.

If I understand you correctly…

  1. Manually edit the files to contain the correct paths under [[webroot_map]]. With confidence set certbot renew up as a cron job.

  2. Someday Debian will help me update Certbot to a newer version that will fix the bug, but I shouldn’t encounter the bug again – at least not with the existing certs or their automatic renewals

  3. Profit!

#4

The package already installs a cron job – it’s just that if you remove the package, and switch to certbot-auto, you would need to set up a different one.

You won’t encounter it just with automated renewals*, but you can if you do what triggers it – e.g. adding a new subdomain a few weeks after renewing a certificate.

* Unless you have multiple certificates with partly overlapping names, which you normally shouldn’t.

:smiley:

#5

I maybe mis-remembering this, but isn’t there an option when setting up Certbot (or maybe a flag you set at install) that doesn’t earn you the cron job? When I crontab -e as both myself and root I don’t see one in any case. I really just followed a tutorial and was pasting in snippets…

I honestly didn’t expect any of this to work as well as it has, so I seem to recall not committing fully at the install stage. :slight_smile:

#6

What does systemctl list-units | grep -i certbot say?

#7

crontab -e only shows the user’s personal crontab (even for root). (They’re probably stored on disk somewhere in /var/spool, FYI.) Cron jobs in places like /etc/cron.d aren’t listed.

The Debian package should have installed a cron job at /etc/cron.d/certbot. The job deactivates itself if systemd is in use.

It should also have installed a systemd service and timer named certbot.

Edit: Typo.

#8

0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl -e ‘sleep int(rand(43200))’ && certbot -q renew

Neat! Thank you for the primer. :slight_smile:

#9

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

#10