token validation command parameter #201

New Issue

adam · 2025-12-29T01:18:46+01:00

adam commented

2025-12-29 01:18:46 +01:00

Originally created by @gertcuykens on GitHub (Feb 22, 2017).

I couldn't find a way to only repeat the challenge validation part for dns-01

When using a manual hook.sh you have to change the TXT record every time after a failed validation attempt, even if initial token is valid for several days.

It's also not clear on which dns server the txt record get checked by letsencrypt, does it check on the name server from the domain directly or just some random dns server that can take days to replicate?

When invalid you also get no details. I can only assume it just some dns replication that still didn't update the txt record.

set -e
set -u
set -o pipefail

case "$1" in
	"deploy_challenge")
		echo ""
		echo "Add the following to the zone definition of ${2}:"
		echo "_acme-challenge.${2}. IN TXT \"${4}\""
		echo ""
		echo -n "Press enter to continue..."
		read tmp
		echo ""
	;;
	"clean_challenge")
		echo ""
		echo "Now you can remove the following from the zone definition of ${2}:"
		echo "_acme-challenge.${2}. IN TXT \"${4}\""
		echo ""
		echo -n "Press enter to continue..."
		read tmp
		echo ""
	;;
	"deploy_cert")
		# do nothing for now
	;;
	"unchanged_cert")
		# do nothing for now
	;;
	*)
		echo "Unknown hook \"${1}\""
		exit 1
	;;
esac

exit 0

Originally created by @gertcuykens on GitHub (Feb 22, 2017). I couldn't find a way to only repeat the challenge validation part for dns-01 When using a manual hook.sh you have to change the TXT record every time after a failed validation attempt, even if initial token is valid for several days. It's also not clear on which dns server the txt record get checked by letsencrypt, does it check on the name server from the domain directly or just some random dns server that can take days to replicate? When invalid you also get no details. I can only assume it just some dns replication that still didn't update the txt record. ``` set -e set -u set -o pipefail case "$1" in "deploy_challenge") echo "" echo "Add the following to the zone definition of ${2}:" echo "_acme-challenge.${2}. IN TXT \"${4}\"" echo "" echo -n "Press enter to continue..." read tmp echo "" ;; "clean_challenge") echo "" echo "Now you can remove the following from the zone definition of ${2}:" echo "_acme-challenge.${2}. IN TXT \"${4}\"" echo "" echo -n "Press enter to continue..." read tmp echo "" ;; "deploy_cert") # do nothing for now ;; "unchanged_cert") # do nothing for now ;; *) echo "Unknown hook \"${1}\"" exit 1 ;; esac exit 0 ```

adam closed this issue

2025-12-29 01:18:46 +01:00

adam commented

2025-12-29 01:18:47 +01:00

@txr13 commented on GitHub (Feb 22, 2017):

I don't believe there's a way to retry a challenge which has already been marked invalid by the CA. According to ACME spec, "The server is said to 'finalize' the authorization when it has completed all the validations it is going to complete, and assigns the authorization a status of 'valid' or 'invalid', corresponding to whether it considers the account authorized for the identifier."

So if a DNS validation did not validate, and the CA marks it as invalid, you must get a new token and change the TXT record.

I'm not sure which servers LE uses for DNS validation, but it's recommended to insert a validation step into your deploy_challenge to be sure the data has replicated. Some hooks (like https://github.com/AnalogJ/lexicon) just sleep for 30 seconds, while others (like https://github.com/bennettp123/dehydrated-email-notify-hook) actually perform a lookup to be sure they get the expected data back, before returning to validate the challenge. FWIW, using dehydrated-email-notify-hook with Google DNS has worked marvelously for me to verify replication has succeeded before the challenge gets validated with LE.

@txr13 commented on GitHub (Feb 22, 2017): I don't believe there's a way to retry a challenge which has already been marked invalid by the CA. According to ACME spec, "The server is said to 'finalize' the authorization when it has completed all the validations it is going to complete, and assigns the authorization a status of 'valid' or 'invalid', corresponding to whether it considers the account authorized for the identifier." So if a DNS validation did not validate, and the CA marks it as invalid, you _must_ get a new token and change the TXT record. I'm not sure which servers LE uses for DNS validation, but it's recommended to insert a validation step into your `deploy_challenge` to be sure the data has replicated. Some hooks (like https://github.com/AnalogJ/lexicon) just sleep for 30 seconds, while others (like https://github.com/bennettp123/dehydrated-email-notify-hook) actually perform a lookup to be sure they get the expected data back, before returning to validate the challenge. FWIW, using `dehydrated-email-notify-hook` with Google DNS has worked marvelously for me to verify replication has succeeded before the challenge gets validated with LE.

adam commented

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

@gertcuykens commented on GitHub (Feb 22, 2017):

I use the above hook script that stops at "Press enter to continue..." then I do dig txt foo.com @ns.foo.com to check the txt record. When I see it, then I continue the script pressing enter. But it returns invalid every time without details what exactly did it check instead of the txt record i see with dig

@gertcuykens commented on GitHub (Feb 22, 2017): I use the above hook script that stops at "Press enter to continue..." then I do `dig txt foo.com @ns.foo.com` to check the txt record. When I see it, then I continue the script pressing enter. But it returns invalid every time without details what exactly did it check instead of the txt record i see with dig

adam commented

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

@txr13 commented on GitHub (Feb 22, 2017):

Right, but I doubt that LE is checking the authoritative nameservers for the domain directly. They're probably querying a well-known resolver (like Google DNS), which will update according to the TTL on the domain.

Note that this will not be affected by the TTL on the TXT record itself. Other resolvers will be refreshing the domain according to the zone refresh time, before they can process the new TXT record and start refreshing according to that record's individual TTL.

LE doesn't seem to give details on which DNS servers they use to do the validation. I believe this is to make it more difficult to compromise (or spoof) a given DNS resolver and use that to validate unauthenticated domains. Safest thing to do, IMO, is wait the full refresh time on the zone. Or, use a different server to perform your own verification that the data is replicating to other resolvers.

@txr13 commented on GitHub (Feb 22, 2017): Right, but I doubt that LE is checking the authoritative nameservers for the domain directly. They're probably querying a well-known resolver (like Google DNS), which will update according to the TTL on the domain. Note that this will not be affected by the TTL on the TXT record itself. Other resolvers will be refreshing the domain according to the zone refresh time, before they can process the new TXT record and start refreshing according to that record's individual TTL. LE doesn't seem to give details on which DNS servers they use to do the validation. I believe this is to make it more difficult to compromise (or spoof) a given DNS resolver and use that to validate unauthenticated domains. Safest thing to do, IMO, is wait the full refresh time on the zone. Or, use a different server to perform your own verification that the data is replicating to other resolvers.

adam commented

2025-12-29 01:18:49 +01:00

@gertcuykens commented on GitHub (Feb 22, 2017):

Ok thanks, one more thing if the domain.txt config file contains "foo.com my.foo.com" i asume the hook script get called twice?

@gertcuykens commented on GitHub (Feb 22, 2017): Ok thanks, one more thing if the domain.txt config file contains "foo.com my.foo.com" i asume the hook script get called twice?

adam commented

2025-12-29 01:18:49 +01:00

@txr13 commented on GitHub (Feb 22, 2017):

That depends on whether you've implemented HOOK_CHAIN or not. Without it, yes, the hook will get called twice (with the validation delay in between each).

With HOOK_CHAIN implemented, you can get all the hostnames validated in a single call (per certificate).

@txr13 commented on GitHub (Feb 22, 2017): That depends on whether you've implemented HOOK_CHAIN or not. Without it, yes, the hook will get called twice (with the validation delay in between each). With HOOK_CHAIN implemented, you can get all the hostnames validated in a single call (per certificate).

adam commented

2025-12-29 01:18:49 +01:00

@gertcuykens commented on GitHub (Feb 22, 2017):

Thanks, on second thought it is maybe better to still be able to split it into 2 separate commands where you can then for example kill the script after deploy_challenge and after 48 hours launch dehydrated again with a parameter to continue where it left off?

@gertcuykens commented on GitHub (Feb 22, 2017): Thanks, on second thought it is maybe better to still be able to split it into 2 separate commands where you can then for example kill the script after `deploy_challenge` and after 48 hours launch dehydrated again with a parameter to continue where it left off?

adam commented

2025-12-29 01:18:50 +01:00

@txr13 commented on GitHub (Feb 22, 2017):

What's the advantage to that versus having the hook sleep itself for the desired length of time?

@txr13 commented on GitHub (Feb 22, 2017): What's the advantage to that versus having the hook sleep itself for the desired length of time?

adam commented

2025-12-29 01:18:50 +01:00

@gertcuykens commented on GitHub (Feb 22, 2017):

You can turn off your computer :)

@gertcuykens commented on GitHub (Feb 22, 2017): You can turn off your computer :)

adam commented

2025-12-29 01:18:51 +01:00

@cpu commented on GitHub (Feb 22, 2017):

It's also not clear on which dns server the txt record get checked by letsencrypt, does it check on the name server from the domain directly or just some random dns server that can take days to replicate?

Right, but I doubt that LE is checking the authoritative nameservers for the domain directly. They're probably querying a well-known resolver (like Google DNS), which will update according to the TTL on the domain.

Let's Encrypt/Boulder does check authoritative nameservers directly - we do not use a well-known resolver. We choose one authoritative server at random when there are several.

@cpu commented on GitHub (Feb 22, 2017): > It's also not clear on which dns server the txt record get checked by letsencrypt, does it check on the name server from the domain directly or just some random dns server that can take days to replicate? > Right, but I doubt that LE is checking the authoritative nameservers for the domain directly. They're probably querying a well-known resolver (like Google DNS), which will update according to the TTL on the domain. Let's Encrypt/Boulder does check authoritative nameservers directly - we do not use a well-known resolver. We choose one authoritative server at random when there are several.

adam commented

2025-12-29 01:18:51 +01:00

@txr13 commented on GitHub (Feb 22, 2017):

@cpu Thanks for the clarification!

I'm guessing that this means that, if you have multiple authoritative nameservers (say, primary and secondary), there's a possibility that the CA queries a secondary authoritative nameserver before it's had a chance to replicate from the primary. If so, this means that we just need to ensure that all authoritative nameservers have the validation data before notifying the CA to perform validation.

@txr13 commented on GitHub (Feb 22, 2017): @cpu Thanks for the clarification! I'm guessing that this means that, if you have multiple authoritative nameservers (say, primary and secondary), there's a possibility that the CA queries a secondary authoritative nameserver before it's had a chance to replicate from the primary. If so, this means that we just need to ensure that all authoritative nameservers have the validation data before notifying the CA to perform validation.

adam commented

2025-12-29 01:18:51 +01:00

@cpu commented on GitHub (Feb 22, 2017):

I'm guessing that this means that, if you have multiple authoritative nameservers (say, primary and secondary), there's a possibility that the CA queries a secondary authoritative nameserver before it's had a chance to replicate from the primary. If so, this means that we just need to ensure that all authoritative nameservers have the validation data before notifying the CA to perform validation.

Yup! That's correct. Ideally you want your process to verify the correct TXT record is returned from all of your authoritative DNS servers before you ask Let's Encrypt to validate.

@cpu commented on GitHub (Feb 22, 2017): > I'm guessing that this means that, if you have multiple authoritative nameservers (say, primary and secondary), there's a possibility that the CA queries a secondary authoritative nameserver before it's had a chance to replicate from the primary. If so, this means that we just need to ensure that all authoritative nameservers have the validation data before notifying the CA to perform validation. Yup! That's correct. Ideally you want your process to verify the correct TXT record is returned from all of your authoritative DNS servers before you ask Let's Encrypt to validate.

adam commented

2025-12-29 01:18:52 +01:00

@gertcuykens commented on GitHub (Feb 23, 2017):

hmm i am beginning to think there is still something wrong with dns-01 in master or LE just hate ns0.transip.net. name servers. How am I going to debug this? @cpu do you work at LE can you see log files or something when I give you a domain name with a challenge record?

@gertcuykens commented on GitHub (Feb 23, 2017): hmm i am beginning to think there is still something wrong with dns-01 in master or LE just hate ns0.transip.net. name servers. How am I going to debug this? @cpu do you work at LE can you see log files or something when I give you a domain name with a challenge record?

adam commented

2025-12-29 01:18:52 +01:00

@cpu commented on GitHub (Feb 23, 2017):

How am I going to debug this? @cpu do you work at LE can you see log files or something when I give you a domain name with a challenge record?

Can you make a new thread on the community forum's help section with details of your problem? Please include the domain name - its the most directly helpful piece of information. I'll keep an eye out and can help provide insight from the Let's Encrypt server perspective as-required. Thanks!

@cpu commented on GitHub (Feb 23, 2017): > How am I going to debug this? @cpu do you work at LE can you see log files or something when I give you a domain name with a challenge record? Can you make a new thread on the [community forum's help section](https://community.letsencrypt.org/c/help) with details of your problem? Please include the domain name - its the most directly helpful piece of information. I'll keep an eye out and can help provide insight from the Let's Encrypt server perspective as-required. Thanks!

adam commented

2025-12-29 01:18:52 +01:00

@gertcuykens commented on GitHub (Feb 23, 2017):

done

@gertcuykens commented on GitHub (Feb 23, 2017): done

adam referenced this issue

2025-12-29 01:28:56 +01:00

[PR #201] [MERGED] Update wellknown.md #749

Sign in to join this conversation.