# "Missing command line flag or config entry..." Error **URL:** \ **Category:** Help\ **Created:** [March 7, 2020, 11:17am UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723 "2020-03-07T11:17:44Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![kerns](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kerns](https://community.letsencrypt.org/u/kerns)\ **Post date:** [March 7, 2020, 11:17am UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/1 "2020-03-07T11:17:45Z")
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. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [March 7, 2020, 11:46am UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/2 "2020-03-07T11:46:23Z")
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.) ---
**Author:** ![kerns](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kerns](https://community.letsencrypt.org/u/kerns)\ **Post date:** [March 7, 2020, 1:33pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/3 "2020-03-07T13:33:15Z")
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! ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [March 7, 2020, 1:36pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/4 "2020-03-07T13:36:11Z")
> [@kerns](#): > > With confidence set _certbot renew_ up as a cron job. 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. > [@kerns](#): > > 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 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. > [@kerns](#): > > Profit! 😃 ---
**Author:** ![kerns](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kerns](https://community.letsencrypt.org/u/kerns)\ **Post date:** [March 7, 2020, 1:53pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/5 "2020-03-07T13:53:00Z")
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. 🙂 ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [March 7, 2020, 1:54pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/6 "2020-03-07T13:54:50Z")
What does `systemctl list-units | grep -i certbot` say? ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [March 7, 2020, 2:46pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/7 "2020-03-07T14:46:23Z")
> [@kerns](#): > > When I crontab -e as both myself and root I don’t see one in any case. `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. ---
**Author:** ![kerns](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kerns](https://community.letsencrypt.org/u/kerns)\ **Post date:** [March 7, 2020, 4:29pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/8 "2020-03-07T16:29:07Z")
> 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. 🙂 ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [April 6, 2020, 4:29pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/9 "2020-04-06T16:29:09Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [April 6, 2020, 4:29pm UTC](https://community.letsencrypt.org/t/missing-command-line-flag-or-config-entry-error/115723/10 "2020-04-06T16:29:10Z")