Add option to do a quick renewal check #45

New Issue

adam · 2025-12-29T00:23:14+01:00

adam commented

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

Originally created by @pR0Ps on GitHub (Jan 23, 2016).

For setups that require a bit of work to get into a state that allows renewing (opening up holes for the well-known directory, restarting webservers, etc) it might be useful to be able to check if any certs will need renewing in a separate step from actually going through the renewal.

Proposal: have a "cert status" command that returns 0 if everything is fine and 1 if certs will need to be updated.

While it's true that this check can easily be done outside the script with an openssl -checkend, having it in the script where RENEW_DAYS and domains.txt are already properly configured would be convenient.

Thoughts?

Originally created by @pR0Ps on GitHub (Jan 23, 2016). For setups that require a bit of work to get into a state that allows renewing (opening up holes for the well-known directory, restarting webservers, etc) it might be useful to be able to check if any certs will need renewing in a separate step from actually going through the renewal. Proposal: have a "cert status" command that returns `0` if everything is fine and `1` if certs will need to be updated. While it's true that this check can easily be done outside the script with an `openssl -checkend`, having it in the script where `RENEW_DAYS` and `domains.txt` are already properly configured would be convenient. Thoughts?

adam added the enhancement label 2025-12-29 00:23:14 +01:00

adam commented

2025-12-29 00:23:15 +01:00

@lukas2511 commented on GitHub (Jan 26, 2016):

Sounds like a good idea.

I will implement something:

Having output that shows domains with status (most likely in form of "domain.tld [valid|expiring|expired]")
Using exit-level 0 if everything is valid and nothing expiring soon
Using exit-level 1 if a cert is expiring soon
Using exit-level 2 if something actually expired

@lukas2511 commented on GitHub (Jan 26, 2016): Sounds like a good idea. I will implement something: - Having output that shows domains with status (most likely in form of "domain.tld [valid|expiring|expired]") - Using exit-level 0 if everything is valid and nothing expiring soon - Using exit-level 1 if a cert is expiring soon - Using exit-level 2 if something actually expired

adam commented

2025-12-29 00:23:15 +01:00

@sej7278 commented on GitHub (Jul 22, 2016):

👍

different exit codes would be great, even with the existing checks, but if you could run a command just to check the expiration status, and then run again based on the exit code (this time reconfiguring firewall, webserver, services etc.) that would be very useful.

as @pR0Ps says, openssl -checkend looping through domains.txt and parsing the other config options is sub-optimal

@sej7278 commented on GitHub (Jul 22, 2016): :+1: different exit codes would be great, even with the existing checks, but if you could run a command just to check the expiration status, and then run again based on the exit code (this time reconfiguring firewall, webserver, services etc.) that would be very useful. as @pR0Ps says, openssl -checkend looping through domains.txt and parsing the other config options is sub-optimal

adam commented

2025-12-29 00:23:16 +01:00

@mape2k commented on GitHub (Feb 11, 2017):

@pR0Ps: Maybe you could use something like https://github.com/Matty9191/ssl-cert-check as a solution?

./ssl-cert-check -N -x 40 -d "/etc/dehydrated/certs/*/cert.pem"
will output something like
1 certificate(s) will expire (FILE:/etc/dehydrated/certs/example.org/cert.pem on Mar 18 2017)|days=35
and return code 1 (if expires in 40 days) or 2 (if expired already)

@mape2k commented on GitHub (Feb 11, 2017): @pR0Ps: Maybe you could use something like https://github.com/Matty9191/ssl-cert-check as a solution? `./ssl-cert-check -N -x 40 -d "/etc/dehydrated/certs/*/cert.pem" ` will output something like 1 certificate(s) will expire (FILE:/etc/dehydrated/certs/example.org/cert.pem on Mar 18 2017)|days=35 and return code 1 (if expires in 40 days) or 2 (if expired already)

adam commented

2025-12-29 00:23:21 +01:00

@chr4 commented on GitHub (May 11, 2017):

+1 for different exit codes.
This helps automating server restarts upon certificate renewals.

@chr4 commented on GitHub (May 11, 2017): +1 for different exit codes. This helps automating server restarts upon certificate renewals.

adam commented

2025-12-29 00:23:21 +01:00

@adds68 commented on GitHub (Jan 29, 2018):

Would this feature also solve the issue of a hitting LEs rate limits by not renewing the certs every time dehydrated is run?

Currently i have to manually check if the certificate is still valid in Ansible, depending on the return value of that i then run Dehydrated.

I'd like to be able to just have dehydrated check to see if my certificate is still valid, if so not contact LE at all.

@adds68 commented on GitHub (Jan 29, 2018): Would this feature also solve the issue of a hitting LEs rate limits by not renewing the certs every time dehydrated is run? Currently i have to manually check if the certificate is still valid in Ansible, depending on the return value of that i then run Dehydrated. I'd like to be able to just have dehydrated check to see if my certificate is still valid, if so not contact LE at all.

adam commented

2025-12-29 00:23:21 +01:00

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

@Wetrain dehydrated is only renewing certificates that have changed or that will expire soon, there are only a few requests against the CA each time the script is run (basically just querying api features)

@lukas2511 commented on GitHub (Jan 29, 2018): @Wetrain dehydrated is only renewing certificates that have changed or that will expire soon, there are only a few requests against the CA each time the script is run (basically just querying api features)

adam commented

2025-12-29 00:23:22 +01:00

@adds68 commented on GitHub (Jan 29, 2018):

@lukas2511 Hm i recently got hit by the 5 certificate renewal limit, due to Ansible running Dehydrated on each deployment, is this correct behaviour, even though i had valid local certificates?

@adds68 commented on GitHub (Jan 29, 2018): @lukas2511 Hm i recently got hit by the 5 certificate renewal limit, due to Ansible running Dehydrated on each deployment, is this correct behaviour, even though i had valid local certificates?

adam commented

2025-12-29 00:23:22 +01:00

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

@Wetrain No idea what your ansible setup is doing, but dehydrated only refreshes certificates 30 days before they'll expire or when the set of domains in the certificate changes. If in your case it runs again and again it either can't find the certificates or you are forcing it to update... Please open an issue with more details if this problem persists, this discussion here is the wrong place for that.

@lukas2511 commented on GitHub (Jan 29, 2018): @Wetrain No idea what your ansible setup is doing, but dehydrated only refreshes certificates 30 days before they'll expire or when the set of domains in the certificate changes. If in your case it runs again and again it either can't find the certificates or you are forcing it to update... Please open an issue with more details if this problem persists, this discussion here is the wrong place for that.

adam commented

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

@lukas2511 commented on GitHub (Feb 11, 2018):

I'm going to finally spend some time implementing this...

Original idea basically still stands, I'm trying to build this nagios-check-like so it can easily be used with tons of monitoring suites.

Any further suggestions?

@lukas2511 commented on GitHub (Feb 11, 2018): I'm going to finally spend some time implementing this... Original idea basically still stands, I'm trying to build this nagios-check-like so it can easily be used with tons of monitoring suites. Any further suggestions?

adam commented

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

@mape2k commented on GitHub (Feb 11, 2018):

I'm using https://github.com/Matty9191/ssl-cert-check to monitor all certificates with nagios which were generated by dehydrated.

@mape2k commented on GitHub (Feb 11, 2018): I'm using https://github.com/Matty9191/ssl-cert-check to monitor all certificates with nagios which were generated by dehydrated.

adam commented

2025-12-29 00:23:24 +01:00

@jglapa commented on GitHub (Feb 28, 2018):

I'm not sure if it's the right place to ask but I'm having problem detecting when I should reload my nginx...
I'm running dehydrated with daily cron and using the route53 dns hook.
I cannot figure out when the cert is actually renewed and (not skipped) so that I can reload nginx.
The script return 0 exit code each time. What would be the right way to do that?

@jglapa commented on GitHub (Feb 28, 2018): I'm not sure if it's the right place to ask but I'm having problem detecting when I should reload my nginx... I'm running dehydrated with daily cron and using the route53 dns hook. I cannot figure out when the cert is actually renewed and (not skipped) so that I can reload nginx. The script return `0` exit code each time. What would be the right way to do that?

adam commented

2025-12-29 00:23:24 +01:00

@chr4 commented on GitHub (Feb 28, 2018):

This is exactly my issue as well. I'm currently calling reload upon every dehydrated run as a workaround.

@chr4 commented on GitHub (Feb 28, 2018): This is exactly my issue as well. I'm currently calling `reload` upon every dehydrated run as a workaround.

adam commented

2025-12-29 00:23:24 +01:00

@txr13 commented on GitHub (Feb 28, 2018):

@jglapa @chr4 You want to implement a hook script. The deploy_cert() function is called for each certificate produced, so that would be the ideal place to reload NGINX.

@txr13 commented on GitHub (Feb 28, 2018): @jglapa @chr4 You want to implement a hook script. The deploy_cert() function is called for each certificate produced, so that would be the ideal place to reload NGINX.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#45