I try to find a way to automate DANE in Bind9 (self-hosted) after obtaining a new SSL certficate. I use Cerbot 0.28.0 from Debian and the Apache plugin. I’ve tried to use a script in the renewal-hooks, the script is executed when a domain is renewed. But I don’t get certbot-environment variables, like the domain name. What would be a good way to do this?
can you check in your dist-packages directory in the certbot/hooks.py if you don’t have code like this, that should be in def _run_deploy_hook function ?
I don’t think the difference matters, probably the logging has been slightly reshuffled.
However, I have a bad feeling about the code in def execute(…)
I will run a quick check and get back in 10 mns
Even after looking at 0.28 code I can’t see why it would not work, unless it’s one of these Debian patches (I’m looking at Letsencrypt 0.28, not the deb)
Does it happen also if you run the renew manually (outside of cron/system) ?
Those environment variables are only set for deploy hooks (and renew hooks, which are similar to deploy hooks but deprecated). Is it a pre or post hook instead?
@gpatel-fr: I would like to have a way how to test hooks manually, but they are not executed then. I test with:
certbot --no-redirect --force-renew -d acrobatiek.nl -d www.acrobatiek.nl
I don’t know another way then to test when an domain needs a new certificate, and that’s done by cron.
I don’t see any way to test hooks except by running a test environment with the staging server. If you use --dry-run, hooks are not called and if you don’t use it certbot will (rightly) refuse to destroy your valid certificates.
BTW, deprecated don’t mean can’t be used. This deprecation of renew hook is not even in the CHANGELOG, and responsible developers are not supposed to announce removal of features immediately. Since Letsencrypt developers have AFAICT no way to monitor renew hooks usage, it would not be wise to remove such a feature without due warning.
Just a side note:
Because of DNS caching you should publish your TLSA record some time before you start using matching certificate or you can use TLSA 3 1 *, reuse private/public key on renewal and do your own private key rollover from time to time.
“–renew-hook” seems to be new. Yes I know I could use certbot-auto, but I prefer Debian packages.
What I have tried is this: “certbot --force-renewal --no-redirect --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/paul2 -d testabc.vandervlis.nl”. This renews the certificate and execute the deploy-hook script. And I have the needed environment variables then!
I guess I have to run “certbot -q renew --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/paul2” to get something like this from cron.
When I run such a command, the deploy-hook is added to the renew-configfile. But when I run such a command without it, the deploy-hook is removed from the renew-configfile. So I guess it’s the best to always run the command with the --deploy-hook.
Not sure how I want to do this. I guess I want always two TLSA keys. An old one and a new one. When the SSL certificate has to be renewed I remove the old TLSA, and add a new. But not sure, I could also remove the old TLSA after a few days.
Keeping the same secret key for a long time is a good idea, see TOFU (trust on first use). HPKP supports TOFU, as well. PFS is supported separately in the protocol.