Deploy challenges once per domain, not once per altname #28

Closed
opened 2025-12-29 00:22:35 +01:00 by adam · 8 comments
Owner

Originally created by @erorus on GitHub (Jan 9, 2016).

example.com www.example.com something.example.com

Current flow:

  1. Request example.com challenge
  2. Deploy example.com challenge response
  3. Verify example.com challenge response
  4. Clean example.com challenge response
  5. Request www.example.com challenge
  6. Deploy www.example.com challenge response
  7. Verify www.example.com challenge response
  8. Clean www.example.com challenge response
  9. Request something.example.com challenge
  10. Deploy something.example.com challenge response
  11. Verify something.example.com challenge response
  12. Clean something.example.com challenge response
  13. Request certificate

Proposed flow:

  1. Request example.com challenge
  2. Request www.example.com challenge
  3. Request something.example.com challenge
  4. Deploy example.com www.example.com something.example.com challenge responses
  5. Verify example.com challenge response
  6. Verify www.example.com challenge response
  7. Verify something.example.com challenge response
  8. Clean example.com www.example.com something.example.com challenge responses
  9. Request certificate

This is more useful with DNS challenges, since DNS may take extra time to update, and you can touch the DNS record once for all subdomains.

However, this can also apply to HTTP challenges, where maybe your upload/copy script can push all challenges once, or maybe you need to reload your web server config only once, etc.

Originally created by @erorus on GitHub (Jan 9, 2016). example.com www.example.com something.example.com Current flow: 1. Request example.com challenge 2. Deploy example.com challenge response 3. Verify example.com challenge response 4. Clean example.com challenge response 5. Request www.example.com challenge 6. Deploy www.example.com challenge response 7. Verify www.example.com challenge response 8. Clean www.example.com challenge response 9. Request something.example.com challenge 10. Deploy something.example.com challenge response 11. Verify something.example.com challenge response 12. Clean something.example.com challenge response 13. Request certificate Proposed flow: 1. Request example.com challenge 2. Request www.example.com challenge 3. Request something.example.com challenge 4. Deploy example.com www.example.com something.example.com challenge responses 5. Verify example.com challenge response 6. Verify www.example.com challenge response 7. Verify something.example.com challenge response 8. Clean example.com www.example.com something.example.com challenge responses 9. Request certificate This is more useful with DNS challenges, since DNS may take extra time to update, and you can touch the DNS record once for all subdomains. However, this can also apply to HTTP challenges, where maybe your upload/copy script can push all challenges once, or maybe you need to reload your web server config only once, etc.
adam added the enhancement label 2025-12-29 00:22:35 +01:00
adam closed this issue 2025-12-29 00:22:35 +01:00
Author
Owner

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

I see why this would be useful, but it seems that quite a lot would have to be written differently to support this...

Didn't really take a look at the DNS verification, but I think you actually should be able to generate your challenge response in advance and just add it as some kind of wildcard in your zonefile.

@lukas2511 commented on GitHub (Jan 15, 2016): I see why this would be useful, but it seems that quite a lot would have to be written differently to support this... Didn't really take a look at the DNS verification, but I think you actually should be able to generate your challenge response in advance and just add it as some kind of wildcard in your zonefile.
Author
Owner

@erorus commented on GitHub (Jan 15, 2016):

If it's not the direction you want to go, that's fine. I already have it working in my fork (just ignore all that PHP crap). I thought I'd suggest it and get your take on it.

Thanks so much for your script. :)

@erorus commented on GitHub (Jan 15, 2016): If it's not the direction you want to go, that's fine. [I already have it working in my fork](https://github.com/erorus/letsencrypt.sh/compare/master...erorus:namecheap-dns?expand=1) (just ignore all that PHP crap). I thought I'd suggest it and get your take on it. Thanks so much for your script. :)
Author
Owner

@nneul commented on GitHub (Jan 22, 2016):

erorus's patch looks pretty tiny/clean - would be nice to see this. Would isolating it into a self contained PR work?

@nneul commented on GitHub (Jan 22, 2016): erorus's patch looks pretty tiny/clean - would be nice to see this. Would isolating it into a self contained PR work?
Author
Owner

@erorus commented on GitHub (Jan 25, 2016):

Submitted PR: https://github.com/lukas2511/letsencrypt.sh/pull/114

I defaulted it to current behavior so as not to break existing scripts.

@erorus commented on GitHub (Jan 25, 2016): Submitted PR: https://github.com/lukas2511/letsencrypt.sh/pull/114 I defaulted it to current behavior so as not to break existing scripts.
Author
Owner

@meiser79 commented on GitHub (Feb 5, 2016):

I just looked at the commit and have a question. In line 403, the challenge_token is removed if you use http-01. Why do you do it again in the lines 423 - 428?

@meiser79 commented on GitHub (Feb 5, 2016): I just looked at the commit and have a question. In line 403, the challenge_token is removed if you use http-01. Why do you do it again in the lines 423 - 428?
Author
Owner

@nneul commented on GitHub (Feb 5, 2016):

I think he's doing that because if the challenges are all generated up front, and then the process is interrupted in middle due to error - that will insure that the leftover ones are cleaned up (the ones for which the cleanup hook wasn't fired.)

@nneul commented on GitHub (Feb 5, 2016): I think he's doing that because if the challenges are all generated up front, and then the process is interrupted in middle due to error - that will insure that the leftover ones are cleaned up (the ones for which the cleanup hook wasn't fired.)
Author
Owner

@TerraTech commented on GitHub (Apr 12, 2016):

It seems that the script just iterates (batches) and calls the HOOK handler for each domain/subdomain. Is there a way to signal the handler that we have received the last iterative domain? Reason being is on the last subdomain, our HOOK handler will invoke a "wait for DNS validation" to ensure that all TXT entries are now being seen by our three authoritative (djbdns) DNS servers. We batch up DNS changes and push them out to the primary/secondaries every 60 seconds (or less). Possibly add a configurable "magic" value that is send after the last domain.

@TerraTech commented on GitHub (Apr 12, 2016): It seems that the script just iterates (batches) and calls the HOOK handler for each domain/subdomain. Is there a way to signal the handler that we have received the last iterative domain? Reason being is on the last subdomain, our HOOK handler will invoke a "wait for DNS validation" to ensure that all TXT entries are now being seen by our three authoritative (djbdns) DNS servers. We batch up DNS changes and push them out to the primary/secondaries every 60 seconds (or less). Possibly add a configurable "magic" value that is send after the last domain.
Author
Owner

@lukas2511 commented on GitHub (Apr 12, 2016):

@TerraTech if you use HOOK_CHAIN=yes in your config all challenge deployments and cleanups (for 1 certificate) are done within one hook call each, and this should be relatively easy to parse within your hook script. see docs/hook_chain.md

@lukas2511 commented on GitHub (Apr 12, 2016): @TerraTech if you use `HOOK_CHAIN=yes` in your config all challenge deployments and cleanups (for 1 certificate) are done within one hook call each, and this should be relatively easy to parse within your hook script. see [docs/hook_chain.md](https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/hook_chain.md)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#28