Cron issuing certbot -q renew, and fails

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: certbot renew

It produced this output:
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(‘An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.’,). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)
1 renew failure(s), 0 parse failure(s)

My web server is (include version): Apache 2.4

The operating system my web server runs on is (include version): Debian 9

My hosting provider, if applicable, is: n/a

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): 0.28.0

I have two files in, probably created when I first installed the certificate. BTW, this is the target url af a deteque rpz, and the certificate served for a (failed) attempt to redirect rpz’ed https traffic to a fixed page.

Question: should I change the cron script or the config file? And how?

Additional question: is it possible to run certbot not as root? How do I switch to making it belonging to a user? (Since this certificate doesn’t work anyway, I can as well start it over from scratch. )


1 Like

At some point you may have renewed your cert using --manual.
If so, this will now make unattended renewals impossible.

Please show file:

and please also show the output of:
certbot certificates

1 Like

I never renewed it. I installed certbot and got the certificate on September 28. The Apache plugin failed, I don’t remember how, but I appreciated that it didn’t try to alter my messy Apache configs. Then I found --manual and used it.

If unattended renewals are impossible, I think I can just remove the cron script. However, I don’t understand what difference does it make how I use the certificate as far as authentication is concerned.

Interactive certbot renew --manual fails as well. What is an “authentication script”?

# renew_before_expiry = 30 days
version = 0.28.0
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
server =
account = 1b87617690092d2c093cb1047886b597
manual_public_ip_logging_ok = True
authenticator = manual
letsencrypt# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name:
    Expiry Date: 2019-12-17 14:48:16+00:00 (VALID: 27 days)
    Certificate Path: /etc/letsencrypt/live/
    Private Key Path: /etc/letsencrypt/live/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Thank you for your support.

1 Like

They are possible.
They just are not possible via:

“manual” means you must enter information manually to complete the renewal.
Unattended renewals means you are not there to enter anything and it runs by itself.
See how they are opposed?

We have 27 days to figure out how to get this system renewing all by itself.
I think we can do it in a lot less time than that - LOL

Let’s review the constraints:

  1. You said --apache plugin failed [so let’s stay away from that - for now].
  2. You want unattended [as everyone else].

Let’s try --webroot instead.
Please show the DocumentRoot folder for the ServerName port 80 virtual host config.file.

And just to be sure Apache is not playing tricks on us, please show the output of:
apachectl -S

letsencrypt# certbot renew --webroot
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Input the webroot for Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/ (failure)

I guess certbot didn’t recognize it was running interactively. Good. I found I can set the webroot in and get the same.

Ok, I realized it is trying to write a new challenge in the web root on each renewal. This works, in cli.ini:
webroot-map = { “”: “/full/path/to/web/root” }
So it seems to be solved for the time being, except that maintaining a map in cli.ini is somewhat less convenient than configuring the web root path for each domain, in case I need more certificates.

Thank you for putting me on the right track.

1 Like

You can configure it in /etc/letsencrypt/renewal/, it should just be called webroot_path there. This is preferable to cli.ini because it’s appropriately specific to an individual certificate.

1 Like

Thank you.
I was going to do that when I was warned that the file changed. A diff showed:
— 2019-11-21 11:14:01.000000000 +0100
+++ 2019-11-20 11:20:21.000000000 +0100
@@ -10,5 +10,6 @@
server =
-manual_public_ip_logging_ok = True
authenticator = webroot
+[[webroot_map]] = /full/path/to/web/root

Now I comment out the setting from cli.ini. Then I’ll wait until the certificate expires again to see what happens.

1 Like

webroot_map is fine too. It’s a form that correctly handles certificates with more than one name on them (where the webroot for each name could potentially be different).

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