[PR #262] [CLOSED] Retry invalid challenge responses, limit retries to 5. #775

New Issue

adam · 2025-12-29T01:29:05+01:00

adam commented

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

📋 Pull Request Information

Original PR: https://github.com/dehydrated-io/dehydrated/pull/262
Author: @extremeshok
Created: 8/22/2016
Status: ❌ Closed

Base: master ← Head: retry

📝 Commits (2)

75f49bc Retry invalid challenge responses, set number of retries to NUMBER
167f4ab Retry invalid challenge responses, limit retries to 5.

📊 Changes

2 files changed (+93 additions, -10 deletions)

View changed files

📝 README.md (+1 -0)
📝 letsencrypt.sh (+92 -10)

📄 Description

Coded to your coding standards, shellchecked

This will allow for the challenge to be retied for upto 5 times when it fails (returns invalid)

Allot of our servers are via cdn/load-balancers and they do not always sync quick enough, so will fail the first X attempts.

This also allows your script to have resiliency with bad connections/timeouts.

letsencrypt.sh --cron --force --retry

Processing test.extremeshok.com
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Nov 19 22:26:00 2016 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for test.extremeshok.com...
 + Responding to challenge for test.extremeshok.com...attempt: 1
 + Invalid
 + Requesting challenge for test.extremeshok.com...
 + Responding to challenge for test.extremeshok.com...attempt: 2
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!

Update to pull : https://github.com/lukas2511/letsencrypt.sh/pull/261

Retries reduce the load.

Here is the specific use case:

All 1000+ servers/vm's are managed/setup by idempotent configuration management. Spanning multiple data centers and countries.

We run a single node aka ssl.domain.com which is responsible for all ssl deployments for all the servers. ie. All "/.well-known/acme-challenge/" http requests from all the 1000+ servers are proxied to the ssl.domain.com server.

Under real world situations on production servers there are timeouts for the length the proxy request can take. Letsencrypt also has timeouts for the validation response. So fact is they can and will fail to validate because they timed out.

Letsencrypt does and will rate limit the number for validation attempts for a domain, so it provides no more load than the current script. Also if you look at the code, I specifically slow down the retries by adding a random 1-10 second pause between each retry.

I can understand your issue with someone setting 99999 retries, but this is virtually no different to them running the script 99999 times in a loop until the certificate has generated. The major difference is the retries will have a far lower impact on the lets encrypt servers.

Currently: If you are creating a certificate with 20 sub-domains and only one of the 20 sub-domains fails (ie number 19) validation, you are forced to rerun the script and re-validate all the sub-domains which were already validated. Thus you increased the load 18 more times.

With my retries only the failed validation will be retried, thus you only have 1 extra validation.

If you are concerned with the user setting a limit of 99999, I have limited the retries to 5.

In real world production all are verified by the 3rd attempt.

As to the proposed add a hook script, there is no place in the code for a hook after the json verification has been generated and before the verification has been validated.

Not to mention the limitation with the hook scripts as they cant do retries for a timeout.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/dehydrated-io/dehydrated/pull/262 **Author:** [@extremeshok](https://github.com/extremeshok) **Created:** 8/22/2016 **Status:** ❌ Closed **Base:** `master` ← **Head:** `retry` --- ### 📝 Commits (2) - [`75f49bc`](https://github.com/dehydrated-io/dehydrated/commit/75f49bc6c2075a83f0930818fb5a3aabb00bfc5c) Retry invalid challenge responses, set number of retries to NUMBER - [`167f4ab`](https://github.com/dehydrated-io/dehydrated/commit/167f4ab00c7e036ad968c7af3b1a124b1ead5e1a) Retry invalid challenge responses, limit retries to 5. ### 📊 Changes **2 files changed** (+93 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+1 -0) 📝 `letsencrypt.sh` (+92 -10) </details> ### 📄 Description Coded to your coding standards, shellchecked This will allow for the challenge to be retied for upto 5 times when it fails (returns invalid) Allot of our servers are via cdn/load-balancers and they do not always sync quick enough, so will fail the first X attempts. This also allows your script to have resiliency with bad connections/timeouts. letsencrypt.sh --cron --force --retry ``` Processing test.extremeshok.com + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Nov 19 22:26:00 2016 GMT (Longer than 30 days). Ignoring because renew was forced! + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for test.extremeshok.com... + Responding to challenge for test.extremeshok.com...attempt: 1 + Invalid + Requesting challenge for test.extremeshok.com... + Responding to challenge for test.extremeshok.com...attempt: 2 + Challenge is valid! + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + Done! ``` Update to pull : https://github.com/lukas2511/letsencrypt.sh/pull/261 Retries reduce the load. Here is the specific use case: All 1000+ servers/vm's are managed/setup by idempotent configuration management. Spanning multiple data centers and countries. We run a single node aka ssl.domain.com which is responsible for all ssl deployments for all the servers. ie. All "/.well-known/acme-challenge/" http requests from all the 1000+ servers are proxied to the ssl.domain.com server. Under real world situations on production servers there are timeouts for the length the proxy request can take. Letsencrypt also has timeouts for the validation response. So fact is they can and will fail to validate because they timed out. Letsencrypt does and will rate limit the number for validation attempts for a domain, so it provides no more load than the current script. Also if you look at the code, I specifically slow down the retries by adding a random 1-10 second pause between each retry. I can understand your issue with someone setting 99999 retries, but this is virtually no different to them running the script 99999 times in a loop until the certificate has generated. The major difference is the retries will have a far lower impact on the lets encrypt servers. Currently: If you are creating a certificate with 20 sub-domains and only one of the 20 sub-domains fails (ie number 19) validation, you are forced to rerun the script and re-validate all the sub-domains which were already validated. Thus you increased the load 18 more times. With my retries only the failed validation will be retried, thus you only have 1 extra validation. If you are concerned with the user setting a limit of 99999, I have limited the retries to 5. In real world production all are verified by the 3rd attempt. As to the proposed add a hook script, there is no place in the code for a hook after the json verification has been generated and before the verification has been validated. Not to mention the limitation with the hook scripts as they cant do retries for a timeout. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

adam added the pull-request label 2025-12-29 01:29:05 +01:00

adam closed this issue

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#775