dietpi-letsencrypt hooks not executed

Hello everyone,

I intend to not run an open port 80 in my Fritzbox router (all the time), but I intend to let my Raspberry Pi automatically renew its certificates.
To achieve this, I created a script that can open the port and another one, that closes it. After quite some messing about, this part is successful.

I placed those scripts under /etc/letsencrypt/renewal-hooks/pre, respectively post directories.

Running certbot renew --force-renewal, those scripts are executed (I can see it in the terminal as well as on the routers configuration page, the port is shown open for the time), but if I use dietpi-letsencrypt, they seem not to be executed.
I am not sure if I would see them in the terminal, but definitely the router is not showing open port.

Can anybody point me to where I might be able to adjust the command line used by dietpi-letsencrypt?
For now, I still need to do that work manually…

usually there is nothing special on dietpi-letsencryp as we do nothing else than using certbot. Is your certificate already close to expire? Because a renewal will be triggered only close to expiration date. Means it’s not done on daily basis.

Hey Joulinar,

thank you for your response. No, my certificate wasn’t close to expiry. Hence I used on my manual execution the flag “–force-renewal” and on dietpi-letsencrypt selected option 2 when it prompted me that the certificate is not yet up for renewal. In both cases it attempted to renew it, but the execution of the scripts (visible by the opening and closing of the ports on the router) only happened on certbot.

Can you/anyone else tell me where the config files for dietpi-letsencrypt are located?

dietpi-letsencrypt don’t have config files. It’s nothing else than a wrapper/gui for certbot. I guess you would need to wait short before your certificates are going to expire to see if certbot will automatically invoke your hooks correctly.

dietpi-letsencrypt does not force a renewal, hence it is expected that hooks for the renewal/deployment are not triggered when the certificate is now due for renewal. If it works with certbot --force-renewal, then it will work as well when the cron job triggers an actual auto-renewal.

Thank you Michaelng & Joulinar!

I guess I will wait then - but I would still expect dietpi-letsencrypt to do the same, inclusive executing scripts, when it asks me to renew non expired certificates before they are due. So I will create an additional script that will create a log so I can see what will happen in the background in some months…

Generally I think it is fine to not force a renewal when not required to not cause unnecessary load to client and ACME servers. dietpi-letsencrypt still applies the HTTPS configuration for the webservers. But probably we can add a separate forced renewal option to the menu.

Hey, just wanted to follow up.

So today my router informed me that port had been opened and then closed again, and my dietpi’s certificate has today as issue date - so I can confirm, you were correct and the regular renewal triggered the hooks correctly. Thanks!

The point of the hooks not being executed on forced renewal via dietpi-letsencrypt stands, but are not critical for me, now that I know it works. It just made writing and debugging them harder than necessary.

If I find time and/or someone stumbling over this is interested how to run certified with port 80 normally closed in an automated way, I could write a how to guide or assist…

MichaIng do you know if dietpi-letsencrypt 1 is going to trigger hooks as well? Usually it should force a renewal if certs if I’m not mistaken.

Hooks are only triggered if the certificate is actually renewed, and dietpi-letsencrypt does not do a forced renewal. Note that there is a rate limiting for renewing certificates, so be careful with forced renewal to debug your scripts. It makes much more sense to trust that Certbot does invoke the scripts (it is debugged by their developers and Debian package maintainers, so doesn’t need to be debugged by you) and do debug the scripts only by simply executing them directly and see whether they do what they should.