Certbot renew failing due to missing --manual-public-ip-logging-ok

Help
1

My domain is:auditor.noojee.com.au

I ran this command:
certbot renew --agree-tos --deploy-hook=/home/bin/certbot_hooks/deploy_hook --work-dir=/etc/letsencrypt/work --config-dir=/etc/letsencrypt/config --logs-dir=/etc/letsencrypt/logs

It produced this output:
Saving debug log to /etc/letsencrypt/logs/letsencrypt.log

Processing /etc/letsencrypt/config/renewal/auditor.noojee.com.au.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for auditor.noojee.com.au
Cleaning up challenges
Encountered exception during recovery:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 70, in handle_authorizations
resps = self.auth.perform(achalls)
File "/usr/lib/python3/dist-packages/certbot/plugins/manual.py", line 112, in perform
self._verify_ip_logging_ok()
File "/usr/lib/python3/dist-packages/certbot/plugins/manual.py", line 133, in _verify_ip_logging_ok
if display.yesno(msg, cli_flag=cli_flag, force_interactive=True):
File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 536, in yesno
self._interaction_fail(message, cli_flag)
File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 466, in _interaction_fail
raise errors.MissingCommandlineFlag(msg)
certbot.errors.MissingCommandlineFlag: Missing command line flag or config entry for this setting:
NOTE: The IP of this machine will be publicly logged as having requested this certificate. If you're running certbot in manual mode on a machine that is not your server, please ensure you're okay with that.

Are you OK with your IP being logged?

(You can set this with the --manual-public-ip-logging-ok flag)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/error_handler.py", line 124, in _call_registered
self.funcs-1
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 243, in _cleanup_challenges
self.auth.cleanup(achalls)
File "/usr/lib/python3/dist-packages/certbot/plugins/manual.py", line 177, in cleanup
env = self.env.pop(achall)
KeyError: KeyAuthorizationAnnotatedChallenge(challb=ChallengeBody(chall=HTTP01(token=b'\xed\x9d\x92}\xaf1!m\xf6a\x0b\x97;R\xf5\x8b"\xfe%\t5\xeb\xa1l\xb8\xde\x92\xa4y\xc1\xce\xa8'), uri='https://acme-v02.api.letsencrypt.org/acme/chall-v3/42873660190/b7UEsQ', _url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/42873660190/b7UEsQ', status=Status(pending), validated=None, error=None), domain='auditor.noojee.com.au', account_key=JWKRSA(key=<ComparableRSAKey(<cryptography.hazmat.backends.openssl.rsa._RSAPrivateKey object at 0x7fd0ff538760>)>))
Attempting to renew cert (auditor.noojee.com.au) from /etc/letsencrypt/config/renewal/auditor.noojee.com.au.conf produced an unexpected error: Missing command line flag or config entry for this setting:
NOTE: The IP of this machine will be publicly logged as having requested this certificate. If you're running certbot in manual mode on a machine that is not your server, please ensure you're okay with that.

Are you OK with your IP being logged?

(You can set this with the --manual-public-ip-logging-ok flag). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/config/live/auditor.noojee.com.au/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/config/live/auditor.noojee.com.au/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version):
nginx - but not relavent.

The operating system my web server runs on is (include version):
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

My hosting provider, if applicable, is: self hosted.

I can login to a root shell on my machine (yes or no, or I don't know):
yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot --version
certbot 0.40.0

The renewal file is:

renew_before_expiry = 30 days

version = 0.40.0
archive_dir = /etc/letsencrypt/config/archive/auditor.noojee.com.au
cert = /etc/letsencrypt/config/live/auditor.noojee.com.au/cert.pem
privkey = /etc/letsencrypt/config/live/auditor.noojee.com.au/privkey.pem
chain = /etc/letsencrypt/config/live/auditor.noojee.com.au/chain.pem
fullchain = /etc/letsencrypt/config/live/auditor.noojee.com.au/fullchain.pem

Options used in the renewal process

[renewalparams]
account = XXXXXXXXXXXXXXXXX
pref_challs = http-01,
config_dir = /etc/letsencrypt/config
work_dir = /etc/letsencrypt/work
logs_dir = /etc/letsencrypt/logs
authenticator = manual
manual_auth_hook = /home/bin/certbot_hooks/auth_hook
manual_cleanup_hook = /home/bin/certbot_hooks/cleanup_hook
server = https://acme-v02.api.letsencrypt.org/directory

I've previously managed to do renewals without issue so I'm confused why this problem has just started to occur?

Should I just be adding the --manual-public-ip-logging-ok flag to certbot renew and certbot certonly?

The original certbot only command was:

'certbot certonly '
' --manual '
' --preferred-challenges=dns '
' -m $emailaddress '
' -d $hostname.$domain '
' --agree-tos '
' --non-interactive '
' --manual-auth-hook="$auth_hook_path" '
' --manual-cleanup-hook="$cleanup_hook_path" '
' --work-dir=$workDir '
' --config-dir=$configDir '
' --logs-dir=$logDir ';

Adding the flag to the renewal does result in a sucessful renewal but I don't understand why this has just started happening?

I should also note that the flag appears to have been deprecated:

So I'm quite confused as to what the correct action is.

2

If adding:

To:

"overcomes" the error message...
This is a first (for me).

But I do see the error making reference to failing that specific check, so your claim seems valid.

I would not expect any patch/modification to certbot 0.40.0 though.
So your best bet is to upgrade that first.
[which should clear the error message completely]
Also, once you have successfully issued a cert with such parameters, they become part of the renewals - you don't have to restate them every time (unless you are trying to change them).
As shown in the renewal.conf file above:

Those settings were already going to happen on their own.

1 Like
3

As far as I'm aware 0.40.0 is the latest version available from apt for ubuntu:

apt-get install --only-upgrade certbot
Building dependency tree       
Reading state information... Done
certbot is already the newest version (0.40.0-1ubuntu0.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I made note in an edit that it appears the flag has been deprecated. Is this correct?

I was aware that you don't need to specify all of the arguments, but certbot doesn't leave me with a lot of confidence and the documentation isn't great. So it seemed safer to include them (they are run from a script).

4

That is true, but Ubuntu comes with snap and that can install version the latest version.
Please follow this guide to replace it: Certbot - Ubuntufocal Other (eff.org)

I see that now.
Yes, it probably has been.

The "script" should really only need to say "certbot renew".
[which should already be added to cron OR other job system]

Again, your problem should go away with an update to certbot.

1 Like
5

I'm using certbot in a docker container and as I understand it you can't run snap in a docker container so
I'm stuck on 0.40.0.

Its seems rather problematic that they aren't updating the apt package given how much docker is used.

FYI: we run a custom docker container that contains nginx and certbot. Scripts within the container manage the certificate allocation and renewals.

6

The probably explanation that comes to mind, is that you have, or had, multiple Certbot versions present.

In Certbot 0.40.0, issuing a certificate with --manual will result in this being present in the renewal .conf file:

 manual_public_ip_logging_ok = True

For that flag to be missing from your renewal .conf file, something out of the ordinary would have to have happened:

  1. Somebody modified the file and removed that line? Seems unlikely.
  2. Alternatively, somebody ran Certbot 1.10 or newer against your /etc/letsencrypt renewal data, which resulted in the deprecated option being stripped from the renewal file. Then when you later tried to renew with older Certbot 0.40.0, it complained about that option being missing. Renewing with that option on the CLI then probably re-added the option to the .conf file.
2 Likes
8

hmm...
What about?:
certbot/certbot - Docker Image | Docker Hub
Isn't that using version 1.21.0?
"There are also Docker images for each of Certbot’s DNS plugins available at Docker which ..."

I guess there is also... using another ACME client - like: acme.sh

1 Like
9

The problem with that is that we have a single docker container that integrates a number of components so running a separate docker container for certbot won't really work.

I guess I could copy the docker settings out of that container but I really don't understand why they aren't maintaining the apt repo version.

10

It comes down to the packaging policy of the distro that you're basing your Docker image off. For example, if you chose Debian (and its derivatives), only security fixes get backported and otherwise everything stays the same version for the entire lifetime of the distro. (This is speaking generally; there's exceptions).

If you based your Docker image off a "less stable" distro like Fedora or CentOS with EPEL8 or whatever, you'd see newer versions of Certbot.

The first party options to install Certbot (snapd, pip, the official Docker images, the Windows exe) will always be up-to-date.

2 Likes
11

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