"keep-going" option for cron mode #72

New Issue

adam · 2025-12-29T00:24:08+01:00

adam commented

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

Originally created by @BtbN on GitHub (Feb 23, 2016).

Because of the plain amount of sub-domains I am using I keep running into the rate-limit a lot of the times.
A lot of the other domains would still renew successfully, but the script in --cron mode aborts after the first cert fails to renew.

It would be extremely useful to have an option to make it continue with the other certs if one of them fails.

Originally created by @BtbN on GitHub (Feb 23, 2016). Because of the plain amount of sub-domains I am using I keep running into the rate-limit a lot of the times. A lot of the other domains would still renew successfully, but the script in --cron mode aborts after the first cert fails to renew. It would be extremely useful to have an option to make it continue with the other certs if one of them fails.

adam closed this issue

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

adam commented

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

@lukas2511 commented on GitHub (Mar 18, 2016):

I think this would be great in combination with a failed_sign hook (open for better names), which would make things like #160 easier.

@lukas2511 commented on GitHub (Mar 18, 2016): I think this would be great in combination with a `failed_sign` hook (open for better names), which would make things like #160 easier.

adam commented

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

@Cyborgscode commented on GitHub (Mar 22, 2016):

the "keep going" features is required for many real world situations.

a domain does no longer point to the server which created the cert.
the script does not know this, so it tries to renew the cert, which fails and it stops => no renew for the other domainnames.

Solution:

enable dns checks for the domainnames, where the IN A has to point to an ip in the output of "ip addr" .
enable a admin notification emailadress to get an email if a fail on the creation or renew of a cert happens.
keep going with the next cert.
keep track of the amount of fails, incase LE has a failrate limit.

Lets be honest, your script is now in use by a lot of hosters, as it's the only easy to integrate solution on the market. You properbly will get a lot a those stability request in the near future.

@Cyborgscode commented on GitHub (Mar 22, 2016): the "keep going" features is required for many real world situations. - a domain does no longer point to the server which created the cert. the script does not know this, so it tries to renew the cert, which fails and it stops => no renew for the other domainnames. Solution: 1) enable dns checks for the domainnames, where the IN A has to point to an ip in the output of "ip addr" . 2) enable a admin notification emailadress to get an email if a fail on the creation or renew of a cert happens. 3) keep going with the next cert. 4) keep track of the amount of fails, incase LE has a failrate limit. Lets be honest, your script is now in use by a lot of hosters, as it's the only easy to integrate solution on the market. You properbly will get a lot a those stability request in the near future.

adam commented

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

@lukas2511 commented on GitHub (Mar 22, 2016):

@Cyborgscode

we may add a pre-sign hook so you can do checks in a hook before anything else happens, this won't become a part of letsencrypt itself.
related to #160, there will be more hooks making this easier to implement
yes, by now i agree that continuing would be a good idea in most cases
i'm not sure about this one, may be implemented at a later point

@lukas2511 commented on GitHub (Mar 22, 2016): @Cyborgscode 1) we may add a pre-sign hook so you can do checks in a hook before anything else happens, this won't become a part of letsencrypt itself. 2) related to #160, there will be more hooks making this easier to implement 3) yes, by now i agree that continuing would be a good idea in most cases 4) i'm not sure about this one, may be implemented at a later point

adam referenced this issue

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

Let people try the staging CA before pointing to the production CA #144

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#72