Certbot-auto renew failed with --manual-auth-hook warning

I did not use the --quiet option.

I have a cert for *.aiki.info and aiki.info, also some other certs that do not need to be renewed yet.

Since auto renew was not working, I tried to run the initial certbot-auto --manual command again, but that created a separate cert “aiki.info-0001” as you can see below. I could move it over the old cert but it seems messy.

My domain is: aiki.info

I ran this command:
./certbot-auto renew

It produced this output:

Processing /etc/letsencrypt/renewal/aiki.info.conf
Cert is due for renewal, auto-renewing...
Could not choose appropriate plugin: 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.',)
Attempting to renew cert (aiki.info) from /etc/letsencrypt/renewal/aiki.info.conf 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.

Processing /etc/letsencrypt/renewal/freetasker.net.conf
Cert not yet due for renewal

Processing /etc/letsencrypt/renewal/aiki.info-0001.conf
Cert not yet due for renewal
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/aiki.info/fullchain.pem (failure)


The following certs are not due for renewal yet:
  /etc/letsencrypt/live/freetasker.net/fullchain.pem expires on 2018-09-01 (skipped)
  /etc/letsencrypt/live/aiki.info-0001/fullchain.pem expires on 2018-09-01 (skipped)
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/aiki.info/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

My web server is (include version):
apache2 2.4.25-3+deb9u4

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

My hosting provider, if applicable, is:
me, VPSs at prgmr.com and crucial.com.au

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

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

My initial command to get the cert was:

./certbot-auto certonly --manual -d *.aiki.info -d aiki.info --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

I am also getting this error message from a manual install this is the command I used initially:

sudo -H certbot certonly --manual --preferred-challenges http -d domain.com -d www.domain.com

I originally tried the “certbot renew” and got no errors, but now one of them is approachng renewal time I am getting this:
“The error was: PluginError(‘An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.’,)”.

I was following instructions from here:


(actually this may not let you in unless you have a liquidweb login)

It does not cover the renewal command.

The particular reason for that is that your original aiki.info certificate covered


while your new certificate covered only


Therefore Certbot concluded that you wanted to manage these certificates separately because they covered different sets of names. If you don't want the new one to continue to be managed on your system, you can delete it with

./certbot-auto delete --cert-name aiki.info-0001

You can also run ./certbot-auto certificates to see a display of which certificates Certbot is currently managing and which names they cover.

As for your (and @brianread108's) underlying question, you can read a lot more about it on the forum at


but the renew command is only intended for completely noninteractive renewals (normally from cron), which is impossible with --manual because it needs to stop and wait for you to do something and confirm when you've done it. So, you have three options:

  • Write a script (or find someone else's script that applies to your situation) and provide it as a --manual-auth-hook (the manual plugin will then run this script during renewals instead of attempting to interact with you).

  • Use a different plugin instead of --manual for your authentication process.

  • Renew the certificate interactively by rerunning the original certonly command, but note that you need to cover exactly the same domain names for Certbot to agree that this should be considered a "renewal" (replacing the existing certificate) and not a "separate certificate" (creating a new certificate name). You can use certbot certificates first if you're not sure what the exact names included in the existing certificate are.

From my experimentation it seems that you cannot automatically renew (i.e. in cron) a cert created using the http protocol - am I correct? Therefore I am guessing that it needs to do the challenge again? and does that involve new files and contents in the .acme challenge directory in the web server (which in my case is remote and only available through ftp access)?

If so I'll have to develop a batch script to do this...

Yes, if you want to deploy challenges to a remote server (relative to where Certbot is running), that's what you'll need to do, using manual auth hooks (via shell scripts or whatever else).

The great majority of Let's Encrypt users have obtained their certificates with the HTTP-01 method and are renewing them automatically. But most of them are running Certbot or another client application directly on the web server, not on a separate machine. In this case, Certbot can use options like --webroot, which supports automated renewal.

We don't happen to have an option for a "remote webroot", but the GetSSL client does, including support for uploading files to the webroot on another machine by FTP.

As @_az said, this would also be an option if you want to continue using Certbot and you want automated renewals.

1 Like

Here’s the bones of my manual auth hook script, which has sucessfully renewed my cert:

HOST="ftp host"
lftp -d ftp://$HOST <<ENDOFPARAMS
user $USER $PW

I ho[pe someone finds it useful. All comments gratefully received. I know it is not good practice to leave a password in a script n plain, but this shows the principle at least.

Thanks, @brianread108. Maybe that will be helpful to @sswam or other people, and maybe Certbot could try at some point to develop remote webroot support like GetSSL's.

I'm more bothered by the ftp:// part, which means that the password is going over the Internet in cleartext. I wish that hosting providers would uniformly switch to FTPS and SFTP, and stop using traditional FTP, which is completely unencrypted.

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