Deploy hook not being run

Basically my deploy hook is not running and I can’t work out why, only that I’ve pinned it down to that.

My domain is:

I ran this command: certbot -renew (well a crontab did)

It produced this output: Don’t know, I wans’t there, but I have a relevant log file in /var/log/letsencrypt, It’s large though, it has lots of content on a renewal, but alas no mention of a deploy hook being run.

My web server is (include version):

$ apache2 -v
Server version: Apache/2.4.25 (Raspbian)
Server built:   2019-04-02T19:05:13

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

$ cat /etc/*-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION="9 (stretch)"

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

$ certbot --version
certbot 0.10.2

now the documentation here:

states clearly:

If you want your hook to run only after a successful renewal, use --deploy-hook in a command


You can also specify hooks by placing files in subdirectories of Certbot’s configuration directory. Assuming your configuration directory is /etc/letsencrypt, any executable files found in /etc/letsencrypt/renewal-hooks/pre, /etc/letsencrypt/renewal-hooks/deploy, and /etc/letsencrypt/renewal-hooks/post will be run as pre, deploy, and post hooks respectively when any certificate is renewed with the renew subcommand. These hooks are run in alphabetical order and are not run for other subcommands.

And check this out:

$ ll  /etc/letsencrypt/renewal-hooks/deploy
total 8
-rwxr-xr-x 1 root   root    154 May  2 06:26 ncp
-rwxr-xr-x 2 cirrus cirrus 2663 Jun 16  2018

But every time my cert renews (which it does successfully ever 90 days) no problems there, this script fails to run, but if I log on and run it manually all comes good.

For what it’s worth, all this scrip does is publish the certifcates to my gateway which is an OpenWRT router running lightttpd which (sadly) can forward pretty much anything as needed to LAN servers behind it, but no SSL handshakes and it wants to have the SSL certs itself.

The problem is categorically NOT in that script. It is executable. It is in the folder the docs ask me to put it in. Renewals happen reliablly, but this script is not run. Running manually works fine. I can use this to test it:

and basically this is my nextcloudpi server and when my nextcloud clients start griping that the cert is expired I can check that link and yep they are expired, I can ssh to the server and the certs are there and valid and not expired. I can run that script and check the URL above again and all is good.

Basically the script is not being run. But why not? It’s executable and in the folder the docs ask me to put it in. I expected to find some clue in the log file, but the end of a renewal log looks like:

2019-04-09 14:53:25, new private key to /etc/letsencrypt/archive/
2019-04-09 14:53:25, certificate to /etc/letsencrypt/archive/
2019-04-09 14:53:25, chain to /etc/letsencrypt/archive/
2019-04-09 14:53:25, full chain to /etc/letsencrypt/archive/
2019-04-09 14:53:25, new config /etc/letsencrypt/renewal/
2019-04-09 14:53:25,310:DEBUG:certbot.renewal:no renewal failures

No mention whatsoever of a deploy hook script.

This bamboozles me I admit. It’s taken me many 90 day cycles to diagnose it definitively to this.

Hi @thumbone

you use the current documentation.

But your certbot

may be from 2016 / 2017. I have no idea if that old certbot supports deploy-hook.

So first step: Update your certbot.

OK, odd, but fixable.

$ certbot --version
certbot 0.28.0

Now I have to wait 90 days to see if it worked.

Typically Certbot renews certificates after 60 days. So there is enough time to fix errors.

You can do certbot renew --force-renew to force it to happen immediately (although this isn’t a perfect simulation of what would happen from cron because cron may set environment variables like PATH differently, and I/O will work differently when running under cron).


Thanks for that. Easy to test in-context, just by adding --force-renew to the crontab entry and waiting till it runs again (in about an hour or two). I just did that and wait with bated breath.

1 Like

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