Per-application self-registering hooks #118

New Issue

adam · 2025-12-29T00:25:12+01:00

adam commented

2025-12-29 00:25:12 +01:00

Originally created by @saper on GitHub (Jul 2, 2016).

#148 currently proposes another hook for a cleaner deployment. #220 proposes a new challenge protocol.

This idea goes a bit further, maybe good for the next major version.

I think we need two kinds of hooks:

hooks that interface to verify domain ownership, this is what current deploy_challenge and clean_challenge. There are some letsencryptkey.sh hooks on the github already for different DNS providers.
deployment hooks that respond to deploy_cert and unchanged_cert. Every SSL enabled app should have one.
For example, there could have one file that deploys apache certificates or another that installs certs for BIND or sendmail or postfix. One could even write something to trigger chef or puppet or whatever.

Those deployment hooks could be possibly generic and there user could map the domain to the deployment hook "please deploy acme.org cert and keys to Apache and nginx, but acme.net goes to dovecot and sendmail".

This could be implemented by having a way to let the hooks register themselves and say "call me on deploy_cert".

In the future those hooks could even be maintained by the
developers of the applications themselves.

For example, apachectl to could be patched to provide a list of SSL domains currently configured in the httpd.conf and friends via the command similar to "apachectl sslvhosts" and then the Apache hook could just check if the domain is in the apache configuration.

This way letsencrypt.sh could be integrated with the startup scripts - imagine Apache requesting certificates on system startup in a similar way that some systems generate SSH keys on sshd startup. Or when doing configuration reload. One just needs to avoid a chicken-and-egg scenario in case the same Apache is used for both ownership proof and HTTPS.

For this, we probably need just to the possibility to specify multiple hooks, in a directory or otherwise. If we let hooks register themselves, we don't even need multiple hook directives for various kinds of hooks.

Hey, even BIND or nsd plugin could register one hook that implements dns-01 challenge and another one installing SSL keys for the CLI control tool or requesting keys/certificates for DANE or whatever.

Originally created by @saper on GitHub (Jul 2, 2016). #148 currently proposes another hook for a cleaner deployment. #220 proposes a new challenge protocol. This idea goes a bit further, maybe good for the next major version. I think we need two kinds of hooks: - hooks that interface to verify domain ownership, this is what current deploy_challenge and clean_challenge. There are some letsencryptkey.sh hooks on the github already for different DNS providers. - deployment hooks that respond to deploy_cert and unchanged_cert. Every SSL enabled app should have one. For example, there could have one file that deploys apache certificates or another that installs certs for BIND or sendmail or postfix. One could even write something to trigger chef or puppet or whatever. Those deployment hooks could be possibly generic and there user could map the domain to the deployment hook "please deploy acme.org cert and keys to Apache and nginx, but acme.net goes to dovecot and sendmail". This could be implemented by having a way to let the hooks register themselves and say "call me on deploy_cert". In the future those hooks could even be maintained by the developers of the applications themselves. For example, apachectl to could be patched to provide a list of SSL domains currently configured in the httpd.conf and friends via the command similar to "apachectl sslvhosts" and then the Apache hook could just check if the domain is in the apache configuration. This way letsencrypt.sh could be integrated with the startup scripts - imagine Apache requesting certificates on system startup in a similar way that some systems generate SSH keys on sshd startup. Or when doing configuration reload. One just needs to avoid a chicken-and-egg scenario in case the same Apache is used for both ownership proof and HTTPS. For this, we probably need just to the possibility to specify multiple hooks, in a directory or otherwise. If we let hooks register themselves, we don't even need multiple hook directives for various kinds of hooks. Hey, even BIND or nsd plugin could register one hook that implements dns-01 challenge and another one installing SSL keys for the CLI control tool or requesting keys/certificates for DANE or whatever.

adam closed this issue

2025-12-29 00:25:13 +01:00

adam commented

2025-12-29 00:25:14 +01:00

@lukas2511 commented on GitHub (Jan 29, 2017):

I'm not really sure how this should work, but as an alternative there now are per-certificate configuration files and you can set different hook scripts for some domains, this should open up a lot more flexibility in what can be done with those hooks, everything else should easily be done based on that change.

@lukas2511 commented on GitHub (Jan 29, 2017): I'm not really sure how this should work, but as an alternative there now are per-certificate configuration files and you can set different hook scripts for some domains, this should open up a lot more flexibility in what can be done with those hooks, everything else should easily be done based on that change.

adam referenced this issue

2025-12-29 01:28:40 +01:00

[PR #118] [MERGED] Added LOCKFILE to config.sh.example #723

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#118