starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-11 22:30:44 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

dns-01: base-domain and wildcard: all challenge deploys are done before validation #431

New Issue
Closed
opened 2025-12-29 01:25:03 +01:00 by adam · 5 comments
adam commented 2025-12-29 01:25:03 +01:00
Owner
Copy Link

Originally created by @fandauchytil on GitHub (Sep 16, 2019).

Problem

If "challenge type" is set to "dns-01" and in "domains.txt" are defined both fqdn and wildcard for that fqdn, script will do challenge for both of them before validation.

Info

commit 05eda91a2f

Example

(Below, I replaced my domain for 'example.com'.)

dehydrated.cfg

CHALLENGETYPE="dns-01"
DOMAINS_TXT="domains.txt"

domains.txt

example.com *.example.com

Output (full output is at the end):

# letsencrypt.sh' -f dehydrated.cfg' -c
...
 + Received 2 authorizations URLs from the CA
 + Deploying challenge tokens...
+ example.com TXT Z7ORPxfTRk-tfwjqRDetMmcMdno83uv9IPAVnsw3nJ8
+ example.com TXT 9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU  # <--- This rewrites the one above
... 
ERROR: Challenge is invalid! (returned: invalid) (result: {
    "detail": "Incorrect TXT record \"9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU\" found at _acme-challenge.example.com",
...

It sets up TXT for 'example.com' twice -- the first one is for domain 'example.com' and the second one is for '*.example.com' (so the first one will be always rewritten). First challenge will always fail, because it expects: Z7ORPxfTRk.., but it will get 9yeYs0leymz9....

Full output from exmaple

Processing example.com with alternative names: *.example.com
 + Checking domain name(s) of egit commit -mxisting cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Oct 13 08:10:59 2019 GMT Certificate will expire
(Less than 30 days). Renewing!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for example.com
 + Handling authorization for example.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
+ example.com TXT Z7ORPxfTRk-tfwjqRDetMmcMdno83uv9IPAVnsw3nJ8
+ Sleeping for 80s...
+ example.com TXT 9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU
+ Sleeping for 80s...
 + Responding to challenge for example.com authorization...
 + Cleaning challenge tokens...
 + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "Incorrect TXT record \"9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU\" found at _acme-challenge.example.com",
    "status": 403
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/XXX",
  "token": "ym-d-ap4B6nrymVGqqoqdY2t7Fq4Az0rV2tg8rWAgz4"
})
Originally created by @fandauchytil on GitHub (Sep 16, 2019). ### Problem If "challenge type" is set to "dns-01" and in "domains.txt" are defined both fqdn and wildcard for that fqdn, script will do challenge for **both** of them **before** validation. ### Info commit 05eda91a2fbaed1e13c733230238fc68475c535e ### Example (Below, I replaced my domain for 'example.com'.) dehydrated.cfg ``` CHALLENGETYPE="dns-01" DOMAINS_TXT="domains.txt" ``` domains.txt ``` example.com *.example.com ``` Output (full output is at the end): ``` # letsencrypt.sh' -f dehydrated.cfg' -c ... + Received 2 authorizations URLs from the CA + Deploying challenge tokens... + example.com TXT Z7ORPxfTRk-tfwjqRDetMmcMdno83uv9IPAVnsw3nJ8 + example.com TXT 9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU # <--- This rewrites the one above ... ERROR: Challenge is invalid! (returned: invalid) (result: { "detail": "Incorrect TXT record \"9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU\" found at _acme-challenge.example.com", ... ``` It sets up TXT for 'example.com' twice -- the first one is for domain 'example.com' and the second one is for '*.example.com' (so the first one will be always rewritten). First challenge will always fail, because it expects: `Z7ORPxfTRk..`, but it will get `9yeYs0leymz9...`. ### Full output from exmaple ``` Processing example.com with alternative names: *.example.com + Checking domain name(s) of egit commit -mxisting cert... unchanged. + Checking expire date of existing cert... + Valid till Oct 13 08:10:59 2019 GMT Certificate will expire (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 2 authorizations URLs from the CA + Handling authorization for example.com + Handling authorization for example.com + 2 pending challenge(s) + Deploying challenge tokens... + example.com TXT Z7ORPxfTRk-tfwjqRDetMmcMdno83uv9IPAVnsw3nJ8 + Sleeping for 80s... + example.com TXT 9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU + Sleeping for 80s... + Responding to challenge for example.com authorization... + Cleaning challenge tokens... + Challenge validation has failed :( ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "dns-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Incorrect TXT record \"9yeYs0leymz9Xp9snRkPeZpc7pOEWoeQYpWeXqBBLrU\" found at _acme-challenge.example.com", "status": 403 }, "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/XXX", "token": "ym-d-ap4B6nrymVGqqoqdY2t7Fq4Az0rV2tg8rWAgz4" }) ```
adam closed this issue 2025-12-29 01:25:03 +01:00
adam commented 2025-12-29 01:25:03 +01:00
Author
Owner
Copy Link

@fandauchytil commented on GitHub (Sep 16, 2019):

Please look at pull req. #675, you should see a solution for the problem. Maybe you could solved it like that.

@fandauchytil commented on GitHub (Sep 16, 2019): Please look at pull req. #675, you should see a solution for the problem. Maybe you could solved it like that.
adam commented 2025-12-29 01:25:04 +01:00
Author
Owner
Copy Link

@jobe1986 commented on GitHub (Sep 16, 2019):

Just as an FYI, the overwriting of the TXT DNS resource record is caused by one of 2 possibilities. Those are either the hook script in use not taking full advantage of the DNS update API in use or a DNS update API that doesn't properly allow for the addition of records of the same name with a different value.

It should however be noted that this is not the fault of DNS itself but merely the interface or the way it is being used.

This issue has also been discussed in various ways before such as is the case with issue #554

@jobe1986 commented on GitHub (Sep 16, 2019): Just as an FYI, the overwriting of the TXT DNS resource record is caused by one of 2 possibilities. Those are either the hook script in use not taking full advantage of the DNS update API in use or a DNS update API that doesn't properly allow for the addition of records of the same name with a different value. It should however be noted that this is not the fault of DNS itself but merely the interface or the way it is being used. This issue has also been discussed in various ways before such as is the case with issue #554
adam commented 2025-12-29 01:25:04 +01:00
Author
Owner
Copy Link

@txr13 commented on GitHub (Sep 16, 2019):

DNS allows multiple TXT records to be set for the same hostname. That is, the validation records for both the wildcard and the root can co-exist at the same time.

Your issue appears to be a problem with either your hook script or your DNS host. It is not an issue within dehydrated.

@txr13 commented on GitHub (Sep 16, 2019): DNS allows multiple TXT records to be set for the same hostname. That is, the validation records for both the wildcard and the root can co-exist at the same time. Your issue appears to be a problem with either your hook script or your DNS host. It is not an issue within dehydrated.
adam commented 2025-12-29 01:25:05 +01:00
Author
Owner
Copy Link

@fandauchytil commented on GitHub (Sep 16, 2019):

(Thank you, now I understand that dilemma.)

I really want this feature and it can easily be done as a option, but on the other hand, there is no problem for me to have this local patch.

@fandauchytil commented on GitHub (Sep 16, 2019): (Thank you, now I understand that dilemma.) I really want this feature and it can easily be done as a option, but on the other hand, there is no problem for me to have this local patch.
adam commented 2025-12-29 01:25:05 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Oct 4, 2019):

See https://github.com/lukas2511/dehydrated/blob/master/docs/troubleshooting.md#dns-invalid-challenge-since-dehydrated-060--why-are-dns-challenges-deployed-first-and-verified-later

@lukas2511 commented on GitHub (Oct 4, 2019): See https://github.com/lukas2511/dehydrated/blob/master/docs/troubleshooting.md#dns-invalid-challenge-since-dehydrated-060--why-are-dns-challenges-deployed-first-and-verified-later
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#431
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?