mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 23:23:32 +01:00
Set default RENEW_DAYS=32 #637
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @adrium on GitHub (Apr 11, 2025).
When February is within the validity period of certificates, monthly cronjobs do not always work.
Consider this year's example:
A safer default that prevents the above situation would be RENEW_DAYS=32 or even more.
@lukas2511 commented on GitHub (Apr 11, 2025):
I'd really recommend running it more than once per month, but anyway, nice catch, I've updated the default to 32 days.
@AgentOak commented on GitHub (Apr 11, 2025):
I guess this doesn't hurt (other than increasing load on Let's Encrypts servers by
3.33% * <certificate share of dehydrated>), but it should be noted that a monthly cronjob can never be expected to be reliable anyway.Let's Encrypts issuance API, like any service on the web, has frequent outages caused by maintenance, hardware defects or even deliberate blocks when there are security concerns (like when there was a validation bug in 2020). See status history. Even though these outages are very brief (10 mins - 3 hours), if your cronjob happens to run at the same time the renewal will fail.
The 30 day renewal period is already pretty long so that every client has a ton of opportunities to renew a certificate before it expires. Even if Let's Encrypt were unavailable for weeks at a time you wouldn't notice an issue. With a cronjob period of 1 month you have reduced the number of opportunities to 1, i.e. a single issuance failure will be a guaranteed outage of your service.
@adrium commented on GitHub (Apr 13, 2025):
How do you assume 3.33% more load? Certificates are valid 90 days and renewing them after 60 days (with RENEW_DAYS=30) is already far from optimal.
There are no recommendations regarding how frequent dehydrated -c should be run.
RENEW_DAYS=32 is a safer default for monthly cronjobs.
However, you are correct in terms of stability. Actually, RENEW_DAYS=7 and running dehydrated daily would be even more stable and efficient.
@lukas2511 commented on GitHub (Apr 13, 2025):
In the grand scheme of things I don't think this tiny increase will matter in any way. For inceased security they are now actually advertising 6-day-certificates on their own website, which you would probably also want to renew a few days before expiry to avoid issues.
@jobe1986 commented on GitHub (Apr 13, 2025):
I can't remember where I read it but way back when I first setup dehydrated I'm sure I read somewhere that the recommendation was to have ACME clients check every 6 hours, however to me that seems a little too much even to take into account service outages, though for the 6 day certs that does keep increase the retry attempts in case of service outages. For 90 day certs I use once a day.
If you're worried about LetsEncrypt's server loads, this is precisely why they publish rate limits so you can take those into account when needed: https://letsencrypt.org/docs/rate-limits/ Even with a 6 hourly check, and at my peak 20 certs, I still wasn't hitting any rate limits.
TL;DR: Amongst the general community, including the community support forums, the general recommendation for checking is daily.
@AgentOak commented on GitHub (Apr 13, 2025):
Most users run a daily cronjob and they will now request a new certificate every 58 days instead of every 60 days, so roughly 3.33% more certificates need to be signed. But I suppose Let's Encrypt isn't really bothered by it anyway since they now offer 6-day certs.