@JuergenAuer Unfortunately, this is the latest version currently on Ubuntu. It was working fine until recently, so I’m not sure what changed. I checked the threads you linked to, and I also searched ahead of time, and while they seem to have the same error message, they don’t address my issue (I don’t have any of their issues, such as misstyped URL or missing webroot parameter - you can see it in the configuration I posted). Any other ideas?
It is missing from the
webroot_map section. The file should look something like:
# renew_before_expiry = 30 days version = 0.31.0 archive_dir = /etc/letsencrypt/archive/norseacademy.org cert = /etc/letsencrypt/live/norseacademy.org/cert.pem privkey = /etc/letsencrypt/live/norseacademy.org/privkey.pem chain = /etc/letsencrypt/live/norseacademy.org/chain.pem fullchain = /etc/letsencrypt/live/norseacademy.org/fullchain.pem # Options used in the renewal process [renewalparams] account = 90d6840904da248a9a7ae688d0ae3d4e authenticator = webroot webroot_path = /var/www/html, server = https://acme-v02.api.letsencrypt.org/directory [[webroot_map]] norseacademy.org = /var/www/html
Repeated for every hostname in the certificate.
Thanks for that! Is there a reason the webroot needs to repeat twice in the configuration file? (there’s a webroot_path parameter above). If it’s missing, is that the bug in 0.31.0 that @JuergenAuer mentioned in his comment? is there a way to manually update certbot to the latest version that addresses this? I tried search for a way to do that but came up short so far.
I think the problem is once the file has been created (incorrectly), there is no update to correct or modify those .conf files.
[and it would be very difficult to just guess what lines are missing]
@rg305 Understood, but we generate several certificates a month, and it would be good to have a solution that prevented it from needing manual updating of configuration files.
I’m understanding that for now, the only way to address this is to edit all of our configuration files and add those lines?
Or you could delete all the configs and reissue certs - but they will need the --webroot -w /actual/roots defined again.
To that end, you may be able to just call
certbot renew -d specific.domain(s) --webroot -w /web/root
and have certbot update it for you…
[still “manual” - but less manual]
@rg305 I just renewed one of those certiifcates (you need to use certonly instead of renew for a single certificate btw), and it did renew successfully when I specified the webroot, but it didn’t change anything in the configuration. I guess the only way is to edit all of those config files… (I have about 40)
That doesn’t add up.
--certonly part (well part of it) adds up; because certonly means just that.
But any change in the renewal should update the renewal.conf file (on success).
Actually, I just checked one of the other domains, and it does specify the webroot in the format recommended above. This is the configuration file for that one:
# renew_before_expiry = 30 days
version = 0.31.0
archive_dir = /etc/letsencrypt/archive/agogecombatives.com
cert = /etc/letsencrypt/live/agogecombatives.com/cert.pem
privkey = /etc/letsencrypt/live/agogecombatives.com/privkey.pem
chain = /etc/letsencrypt/live/agogecombatives.com/chain.pem
fullchain = /etc/letsencrypt/live/agogecombatives.com/fullchain.pem
# Options used in the renewal process
account = 90d6840904da248a9a7ae688d0ae3d4e
authenticator = webroot
webroot_path = /var/www/html,
server = https://acme-v02.api.letsencrypt.org/directory
agogecombatives.com = /var/www/html
But it’s still not renewing automatically, with same error message as before. Any ideas on how I can get those certificates to work with certbot renew?
I would have to see the error message.
Also, you should verify the root with a “test.file” there ("
/var/www/html") and see if you can reach via:
The error message is the same as the one in the original post -
Attempting to renew cert (agogecombatives.com) from /etc/letsencrypt/renewal/agogecombatives.com.conf produced an unexpected error: Missing command line flag or config entry for this setting: Select the webroot for www.agogecombatives.com: Choices: ['Enter a new webroot', '/var/www/html'] (You can set this with the --webroot-path flag). Skipping.
It can be renewed manually, as I just did with the other domain. For some reason it’s not creating configuration that can be renewed
has no entry for:
Can we have a look at:
[at least any of them that contain:
Yep, that was it! thanks @rg305, adding the entry for the www. domain allowed to renew through the renew command. I wonder why certbot is so inconsistent with creating those configuration files and if the only recourse is to wait for the 0.32 version to be available on ubuntu.
YVW Glad it worked
I can’t say for sure.
But I wouldn’t expect any fix to be retroactive.
Until then, there is the “manual” approach.
The good news there is that is should only require to be done ONCE.
To expedite matters…
You might want to
roots from your config (
And somehow build a single complete list of names and their corresponding webroots.
then just add that whole big list to each and every renewal.conf file.
I don’t know if certbot follows “include” statements…
[mileage may vary]
[may cause lack of sleep, hair loss, or depression]
[don’t take if allergic to any of its’ ingredients]
[see store for details]
Yeah, I’ll build a script to make the changes in bulk. Unfortunately we generate 10-15 new certificates a month, so I’ll need to continue keeping an eye on it.
If you do produce a usable verification script, please post it here (or start a new topic) so that others with a similar problem may benefit from it
The specific bug is that some versions of Certbot, when issuing a certificate, would fail to save the webroot path for hostnames it did not have to validate.
When an ACME account has validated a name within the last 30 days, Let's Encrypt allows it to issue certificates without validating the name again. (This is not a promise, and clients shouldn't rely on it, but it's how it normally works.)
It was fixed in Certbot 0.35.0.
Renewing will not normally break the configuration, because certificates are normally renewed approximately every 60 days, long after the authorizations would have expired, always forcing the names to be validated again.
It comes into play in other circumstances -- adding a new subdomain not long after a certificate was renewed, maintaining multiple certificates with overlapping hostnames, or renewing unusually frequently.
Depending on their workflow, the bug may rarely or never affect people.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.