hooks for starting web server only to get auth/cert #137

New Issue

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

adam commented

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

Originally created by @arekm on GitHub (Aug 14, 2016).

Assume you want to create certificates for some other service, like jabber server. web server is turned off by default there and needs to be started only for letsencrypt auth.

So some hooks for that would be nice. Right now I'm doing it in a bit hacky way:

case "$1" in
deploy_cert)
[...]
        cat "$FULLCHAINCERT" "$PRIVKEY" > /etc/openssl/jabber.example.com.pem
        /sbin/service ejabberd reload
       /sbin/service lighttpd stop
        ;;
clean_challenge)
        /sbin/service lighttpd stop
        ;;
deploy_challenge)
        /sbin/service lighttpd start
        ;;

clean_challenge is not always called AFAIK and deploy_cert is called even if certificate did not change, so these hooks are not best for such job.

Originally created by @arekm on GitHub (Aug 14, 2016). Assume you want to create certificates for some other service, like jabber server. web server is turned off by default there and needs to be started _only_ for letsencrypt auth. So some hooks for that would be nice. Right now I'm doing it in a bit hacky way: ``` case "$1" in deploy_cert) [...] cat "$FULLCHAINCERT" "$PRIVKEY" > /etc/openssl/jabber.example.com.pem /sbin/service ejabberd reload /sbin/service lighttpd stop ;; clean_challenge) /sbin/service lighttpd stop ;; deploy_challenge) /sbin/service lighttpd start ;; ``` clean_challenge is not always called AFAIK and deploy_cert is called even if certificate did not change, so these hooks are not best for such job.

adam closed this issue

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

adam commented

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

@Robby- commented on GitHub (Sep 3, 2016):

I'm making preparations to do something very similar, but with nginx instead.

According to the documentation in docs/examples/hook.sh, or at least what I make out of it, the clean_challenge hook only gets called when there is something to clean. This can explain what you are experiencing when you say that it is not always called.

For deploy_cert my understanding is that it only gets called when a new certificate has been produced/retrieved. If deploy_cert always gets called for you, then that sounds like either a bug inside the letsencrypt.sh script itself (or an error in the documentation), or something is wrong in your setup, although the snippet you pasted looks good.

For me, in another setup that I have (also an nginx webserver, but one that is always running and needs certificates for itself) the deploy_cert hook only gets called as described in the documentation (when a new certificate has been produced/retrieved).

Anyhow, as I said, I'm making preparations (writing a hook script) to do something very similar, and as it is not ready yet I have yet to test it out against the LE staging server. What I'm going to do is start the nginx server in deploy_challenge, and then in deploy_cert I'm stopping the nginx server and copying the new certificates to where they need to be. Provided the documentation is correct (and my understanding of it is also correct) I should have no problems with this, and also not need any of the other hooks, only the two hooks I mentioned.

Edit: I have tested it and it is working as expected. I am however thinking of using clean_challenge to stop the webserver instead of doing it in deploy_cert, since clean_challenge seems to be the better choice as it is always supposed to be called, whether the challenge validation is successful or not.

@Robby- commented on GitHub (Sep 3, 2016): I'm making preparations to do something very similar, but with nginx instead. According to the documentation in `docs/examples/hook.sh`, or at least what I make out of it, the `clean_challenge` hook only gets called when there is something to clean. This can explain what you are experiencing when you say that it is not always called. For `deploy_cert` my understanding is that it only gets called when a new certificate has been produced/retrieved. If `deploy_cert` always gets called for you, then that sounds like either a bug inside the letsencrypt.sh script itself (or an error in the documentation), or something is wrong in your setup, although the snippet you pasted looks good. For me, in another setup that I have (also an nginx webserver, but one that is always running and needs certificates for itself) the `deploy_cert` hook only gets called as described in the documentation (when a new certificate has been produced/retrieved). Anyhow, as I said, I'm making preparations (writing a hook script) to do something very similar, and as it is not ready yet I have yet to test it out against the LE staging server. What I'm going to do is start the nginx server in `deploy_challenge`, and then in `deploy_cert` I'm stopping the nginx server and copying the new certificates to where they need to be. Provided the documentation is correct (and my understanding of it is also correct) I should have no problems with this, and also not need any of the other hooks, only the two hooks I mentioned. **Edit:** I have tested it and it is working as expected. I am however thinking of using `clean_challenge` to stop the webserver instead of doing it in `deploy_cert`, since `clean_challenge` seems to be the better choice as it is always supposed to be called, whether the challenge validation is successful or not.

adam commented

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

@rpv-tomsk commented on GitHub (Dec 19, 2016):

I.e. there is need in two hooks:

Before any update operation (to start webserver)
After any update operation (to stop webserver)
Last hook can be used for webserver reload in common HTTPS tasks (as requested in #316).

@rpv-tomsk commented on GitHub (Dec 19, 2016): I.e. there is need in two hooks: - Before any update operation (to start webserver) - After any update operation (to stop webserver) Last hook can be used for webserver reload in common HTTPS tasks (as requested in #316).

adam commented

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

@tkaehn commented on GitHub (Jan 16, 2017):

It would be great to have one hook running directly after starting dehydrated to do some initialization (e.g. starting the web server or enabling firewall rules on systems which do not allow incoming connections on port 80 or outgoing connections on port 80 and 443). Additionally one hook should be run just before exiting dehydrated to clean everything up (regardless of new certificates being deployed or an error occured).

@tkaehn commented on GitHub (Jan 16, 2017): It would be great to have one hook running directly after starting dehydrated to do some initialization (e.g. starting the web server or enabling firewall rules on systems which do not allow incoming connections on port 80 or outgoing connections on port 80 and 443). Additionally one hook should be run just before exiting dehydrated to clean everything up (regardless of new certificates being deployed or an error occured).

adam commented

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

@txr13 commented on GitHub (Jan 16, 2017):

So far, I haven't seen any use case outlined here where the existing hooks would not suffice.

deploy_challenge works for starting a web daemon and/or altering firewall rules.
clean_challenge works for killing the web daemon and/or re-altering firewall rules.
deploy_cert works for writing out the cert (in whatever format is required) and reloading whatever daemon needs to know about the new cert.

If you expect to be doing a lot of challenges and don't want to be continually starting and stopping the daemon, it seems trivial to write a script which does the needful before and after, and simply calls dehydrated in the middle.

@txr13 commented on GitHub (Jan 16, 2017): So far, I haven't seen any use case outlined here where the existing hooks would not suffice. - `deploy_challenge` works for starting a web daemon and/or altering firewall rules. - `clean_challenge` works for killing the web daemon and/or re-altering firewall rules. - `deploy_cert` works for writing out the cert (in whatever format is required) and reloading whatever daemon needs to know about the new cert. If you expect to be doing a lot of challenges and don't want to be continually starting and stopping the daemon, it seems trivial to write a script which does the needful before and after, and simply calls `dehydrated` in the middle.

adam commented

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

@tkaehn commented on GitHub (Jan 17, 2017):

I agree that deploy_cert is sufficient for restarting the daemons. However setting up firewall rules in deploy_ and clean_challenge is not sufficient for systems which normally do not allow outgoing traffic on port 80 and 443.
Having a generic initialization and cleanup hook would solve this problem and might be helpful in other use cases.
Of course using a wrapper script calling dehydrated in the middle is possible, but this feels like a workaround for missing hooks.

@tkaehn commented on GitHub (Jan 17, 2017): I agree that deploy_cert is sufficient for restarting the daemons. However setting up firewall rules in deploy_ and clean_challenge is not sufficient for systems which normally do not allow outgoing traffic on port 80 and 443. Having a generic initialization and cleanup hook would solve this problem and might be helpful in other use cases. Of course using a wrapper script calling dehydrated in the middle is possible, but this feels like a workaround for missing hooks.

adam commented

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

@rpv-tomsk commented on GitHub (Jan 17, 2017):

The same hooks are requested in #331

@rpv-tomsk commented on GitHub (Jan 17, 2017): The same hooks are requested in #331

adam commented

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

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

I don't know what exactly you want, the deploy_challenge and clean_challenge hooks would be the ideal place for starting and stopping a web-server as they are really only called when there is work to do and they are always called in that case, only exception is on errors in the communication with Let's Encrypt, and there is a different hook for that (see request_failure).

What you could also do to maybe spare some start/stop cycles is to just start the server in the deploy_challenge hook if it's not running yet, and just always stop it after dehydrated did its job...

And just to make this clear: For me using a wrapper script is not a workaround, it's more or less the intended usage of this tool, that is one of the reasons why there are so many options on this script, hooks should only be for things that can't easily be solved in a different (clean) way.

@lukas2511 commented on GitHub (Jan 29, 2017): I don't know what exactly you want, the `deploy_challenge` and `clean_challenge` hooks would be the ideal place for starting and stopping a web-server as they are really only called when there is work to do and they are always called in that case, only exception is on errors in the communication with Let's Encrypt, and there is a different hook for that (see `request_failure`). What you could also do to maybe spare some start/stop cycles is to just start the server in the `deploy_challenge` hook if it's not running yet, and just always stop it after dehydrated did its job... And just to make this clear: For me using a wrapper script is not a workaround, it's more or less the intended usage of this tool, that is one of the reasons why there are so many options on this script, hooks should only be for things that can't easily be solved in a different (clean) way.

adam referenced this issue

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

[PR #137] [CLOSED] load config in cleanup function #728

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#137