Certbot renewal hook priority

The Certbot manual lists four ways to set renewal hooks:

  1. Command line arguments (certbot renew --pre-hook)
  2. Certificate renewal config files (certbot reconfigure --pre-hook)
  3. The global Certbot config file (e.g., /etc/letsencrypt/cli.ini)
  4. The renewal hook directories (/etc/letsencrypt/renewal-hooks/pre)

The renewal hook directory contents are always run for any renewal attemp by default, but how are the other three options prioritized?

Also, are there any addional ways to set renewal hooks apart from these four?

1/2 writes to 4: 3 changes where 4 should be

1 Like

1 and 2 write to the renewal hook directories? That doesn't sound quite right.

sorry I misread: prehook thing blown up 1/2 is that linage specific and written to each files renewalconfig file.

1 Like

Maybe you meant to say that (2) certbot reconfigure --cert-name <cert name> --pre-hook and (1) certbot renew --cert-name <cert name> --pre-hook—if successful—write to /etc/letsencrypt/renewal/<cert name>.conf's pre_hook option?

2 Likes

Certbot's docs don't directly address your question. But, some details are in this section: User Guide — Certbot 3.1.0.dev0 documentation

Mostly though I think you will need to experiment. You could place a hook in each location and see the sequence. I use a hook command like 'echo Hook-For-ItemX' when testing similar cases. Fancier logging techniques inside hook scripts are possible of course.

Personally I am wary about relying on behavior that is not doc'd. My concern is the behavior may change without notice since there is nothing constraining it. In this case I don't think this is a big concern.

Sure, you could create your own "Certbot script" to run pre- and post- Certbot. Then setup a cronjob to run it for automated renew. If this is used for every certbot cert you should then disable the existing systemd timer or cronjob.

/var/myCertbotScript.sh

/var/myPreHook.sh
certbot renew 
/var/myPostHook.sh
3 Likes