Certbot renewals and DANE

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?

With regards,
Paul van der Vlis

That’s strange, I can see in the certbot current code (0.35):

os.environ["RENEWED_DOMAINS"] = " ".join(domains)
os.environ["RENEWED_LINEAGE"] = lineage_path
_run_hook("deploy-hook", command)

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 see this lines in certbot/hooks.py, but I do not see environment variables in my bash script.

What I do now to test is: “printenv | mailto -s test paul@vandervlis.nl”. I get environment variables like LANG and PWD, but no certbot variables.

ah, this is in hooks.py:

os.environ["RENEWED_DOMAINS"] = " ".join(domains)
os.environ["RENEWED_LINEAGE"] = lineage_path
logger.info("Running deploy-hook command: %s", command)
_run_hook(command)

So maybe a little different…

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.

@mnordhoff My script is in /etc/letsencrypt/renewal-hooks/pre/ Is this depricated? What would be better?

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.

certbot-auto renew --force-renewal --renew-hook /etc/letsencrypt/renewal-hooks/deploy/myscript

after that, just running
certbot-auto renew --force-renewal
is sufficient as the renewal-hook is saved in the renewal config file.

as said by @mnordhoff if you put your scripts in the pre or post directories they will run automatically but no env variable is set.

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.

Well, time to monitor the forum and mount an industrial action against deprecation of the action then !

that’s always the case, the renewal config file registers the parameters for the last command used that is NOT a renewal.

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.

Is the --deploy-hook deprecated too? How do you know this?

Yes I have misinterpreted a bit @mnordhoff’s post. Yet with modern software about every feature is threatened, so it may be only a matter of time :-/

A couple of useful links on DANE key rotation:

https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

And a link to a more general DANE resources page:

This works :wink: (but I need to type 20 characters otherwise this system does not post)

1 Like

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.

I use DANE for the pubkeys, not for the certs.