Validate challenges after deploy_challenge #586

New Issue

adam · 2025-12-29T01:27:34+01:00

adam commented

2025-12-29 01:27:34 +01:00

Originally created by @rossnick on GitHub (Nov 29, 2022).

I have a case where a particular cert has several SANs. This cert request is validated trough DNS via a hook script. So, doing it's job, dehydrated deploy several challenges, begins to validate them. It happens some times in that very constrained network environment that some requests fails. When it does at that stage, all is stopped and the remaining challenges are still deployed. This particular hook script fails when trying to re-deploy the same challenge, so before retrying, I need to manually clean the challenges from the DNS provider, which is very tedious.

Is there a way to make dehydrated to deploy a challenge and then validate it immediately instead of deploying challenges all at once and validating them all at once ?

Originally created by @rossnick on GitHub (Nov 29, 2022). I have a case where a particular cert has several SANs. This cert request is validated trough DNS via a hook script. So, doing it's job, dehydrated deploy several challenges, begins to validate them. It happens some times in that very constrained network environment that some requests fails. When it does at that stage, all is stopped and the remaining challenges are still deployed. This particular hook script fails when trying to re-deploy the same challenge, so before retrying, I need to manually clean the challenges from the DNS provider, which is very tedious. Is there a way to make dehydrated to deploy a challenge and then validate it immediately instead of deploying challenges all at once and validating them all at once ?

adam closed this issue

2025-12-29 01:27:34 +01:00

adam commented

2025-12-29 01:27:35 +01:00

@lukas2511 commented on GitHub (Nov 29, 2022):

Dehydrated first deploys all tokens and validates them because of a quirk with how wildcard validation is handled (see https://github.com/dehydrated-io/dehydrated/blob/master/docs/troubleshooting.md#dns-invalid-challenge-since-dehydrated-060--why-are-dns-challenges-deployed-first-and-verified-later).

Also (using hook chaining) this reduces the time needed for pre-validation of DNS rollouts, as in a lot of setups only the last deployed token (per certificate) needs to be waited for, instead of waiting for a refresh timer or ttl on every single entry (this is a job for the hook script, dehydrated doesn't pre-validate or wait for anything).

I'm going to work on request retries, which should retry if a request to the CA fails for some reason. Maybe that also solves your issues, but it sounds more like you should fix your hook script to allow redeploying a challenge in case something went wront.

@lukas2511 commented on GitHub (Nov 29, 2022): Dehydrated first deploys all tokens and validates them because of a quirk with how wildcard validation is handled (see https://github.com/dehydrated-io/dehydrated/blob/master/docs/troubleshooting.md#dns-invalid-challenge-since-dehydrated-060--why-are-dns-challenges-deployed-first-and-verified-later). Also (using hook chaining) this reduces the time needed for pre-validation of DNS rollouts, as in a lot of setups only the last deployed token (per certificate) needs to be waited for, instead of waiting for a refresh timer or ttl on every single entry (this is a job for the hook script, dehydrated doesn't pre-validate or wait for anything). I'm going to work on request retries, which should retry if a request to the CA fails for some reason. Maybe that also solves your issues, but it sounds more like you should fix your hook script to allow redeploying a challenge in case something went wront.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#586