Checking certificate status after running dehydrated -c #205

New Issue

2025-12-29T01:18:54+01:00

adam commented

2025-12-29 01:18:54 +01:00

Originally created by @mavrekh on GitHub (Mar 23, 2017).

Hi,

I have dehydrated running as a cron process with the -c option and I need the process to send out an email whenever a new certificate is successfully obtained: i.e. no "Valid till ... Skipping renew" message, but also no 500 errors from letsencrypt, no issues writing to the .well-known dir, etc. What is the best way the check whether a new certificate has been obtained after running dehydrated? I guess one way would be to grep through the output and look for something like "Done!", but I'd like something more failsafe.

Thanks!

Misha

Originally created by @mavrekh on GitHub (Mar 23, 2017). Hi, I have dehydrated running as a cron process with the -c option and I need the process to send out an email whenever a new certificate is successfully obtained: i.e. no "Valid till ... Skipping renew" message, but also no 500 errors from letsencrypt, no issues writing to the .well-known dir, etc. What is the best way the check whether a new certificate has been obtained after running dehydrated? I guess one way would be to grep through the output and look for something like "Done!", but I'd like something more failsafe. Thanks! Misha

adam closed this issue

2025-12-29 01:18:54 +01:00

adam commented

2025-12-29 01:18:55 +01:00

@txr13 commented on GitHub (Mar 23, 2017):

I personally have a small script for this purpose. It goes through all my certs and compares the SHA-1 hash of the current fullchain.pem to the previous value. If the hash has changed, it fires whatever update is needed for that particular certificate.

You may also be able to use the deploy_cert hook for this purpose, since that is "called once for each certificate that has been produced."

@txr13 commented on GitHub (Mar 23, 2017): I personally have a small script for this purpose. It goes through all my certs and compares the SHA-1 hash of the current fullchain.pem to the previous value. If the hash has changed, it fires whatever update is needed for that particular certificate. You may also be able to use the `deploy_cert` hook for this purpose, since that is "called once for each certificate that has been produced."

adam commented

2025-12-29 01:18:55 +01:00

@mavrekh commented on GitHub (Mar 23, 2017):

Would you mind sharing the hash comparison script, or at least the relevant parts?

@mavrekh commented on GitHub (Mar 23, 2017): Would you mind sharing the hash comparison script, or at least the relevant parts?

adam commented

2025-12-29 01:18:55 +01:00

@txr13 commented on GitHub (Mar 23, 2017):

I don't mind at all. I've uploaded it here for your convenience.

Basically, it loops over all certificate directories in CERTDIR. In each directory, it calculates the current hash for private key and fullchain, checks for the previously-saved hash for the private key and fullchain, and determines whether those files have changed.

If a change is found, then we check the certificate directory for a per-certificate override file telling us what actions to take. If found, execute that script. Otherwise, we perform the default actions. Then we fire off an email notifying us of what needs to be done, save the new hash values to the certificate directory, and move on.

Additional points of note:

this script assumes that a change in the main certificate file is enough to trigger a set of actions, regardless of whether the private key changed or not. If you need other actions to be taken depending on whether the private key also changed, you'll need to move that check up accordingly.
if you don't care about whether the private key updated (for example, if you have set PRIVATE_KEY_RENEW="yes" and don't have that overridden anywhere), then you can remove the checks for private key hash and the second email completely.

@txr13 commented on GitHub (Mar 23, 2017): I don't mind at all. I've uploaded it [here](https://github.com/lukas2511/dehydrated/files/865947/update-certs.txt) for your convenience. Basically, it loops over all certificate directories in `CERTDIR`. In each directory, it calculates the current hash for private key and fullchain, checks for the previously-saved hash for the private key and fullchain, and determines whether those files have changed. If a change is found, then we check the certificate directory for a per-certificate override file telling us what actions to take. If found, execute that script. Otherwise, we perform the default actions. Then we fire off an email notifying us of what needs to be done, save the new hash values to the certificate directory, and move on. Additional points of note: - this script assumes that a change in the main certificate file is enough to trigger a set of actions, regardless of whether the private key changed or not. If you need other actions to be taken depending on whether the private key also changed, you'll need to move that check up accordingly. - if you don't care about whether the private key updated (for example, if you have set `PRIVATE_KEY_RENEW="yes"` and don't have that overridden anywhere), then you can remove the checks for private key hash and the second email completely.

adam commented

2025-12-29 01:18:55 +01:00

@mavrekh commented on GitHub (Mar 24, 2017):

Thank you so much! This is really helpful.

@mavrekh commented on GitHub (Mar 24, 2017): Thank you so much! This is really helpful.

adam commented

2025-12-29 01:18:56 +01:00

@lukas2511 commented on GitHub (Jul 10, 2017):

I'd recommend using the deploy_cert hook for this like @txr13 already mentioned.

@lukas2511 commented on GitHub (Jul 10, 2017): I'd recommend using the `deploy_cert` hook for this like @txr13 already mentioned.

adam commented

2025-12-29 01:18:57 +01:00

@mavrekh commented on GitHub (Jul 11, 2017):

Yes, I ended up implementing a deploy_cert hook and it works great. Sorry for not closing this earlier, and thanks so much for your help.

@mavrekh commented on GitHub (Jul 11, 2017): Yes, I ended up implementing a deploy_cert hook and it works great. Sorry for not closing this earlier, and thanks so much for your help.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#205