DuckDNS wildcard/sub-domains failure #375

Closed
opened 2025-12-29 01:23:54 +01:00 by adam · 4 comments
Owner

Originally created by @KillianDS on GitHub (Sep 14, 2018).

I currently try to get a single certificate for a duckdns domain and a sub domain, which fails. You can find some redacted output below for reference.

I think dehydrated first deploys all challenges, then triggers validation for all domains and then cleans all challenges (HOOK_CHAIN is off). However, duckdns is a bit special in that sense that while they do support subdomains, these simply point to the same record as the main domain and you can only set the latter. So what seems to happen is:

  1. Challenge token X is set for main domain
  2. Challenge token Y is set for sub domain, this actually overrides X (my hook strips the sub-domain as per the above).
  3. one of the validations fails because Y is not equal to X

Am I doing something wrong on my end or is this a restriction of how dehydrated/ACME works? In the latter case, would it be possible to explicitly sequence deploy/validate/clean per (sub)domain via some option?

about my setup:
Config only overwrites CA (to use staging) and sets domain file. My domain file is really simple 'mydomain.duckdns.org mysub.mydomain.duckdns.org'. I validated and the hook is working just fine if I only try the single domain or sub-domain, it's the combination that fails.

For reference: I tried using a wildcard certificate instead of a subdomain but that gave the same problem. In this case I actually don't understand how it could work even for other DNS providers, because dehydrated itself asked to install tokens for 'mydomain.duckdns.org' and 'mydomain.duckdns.org' (it stripped the *. itself), which would always conflict.

# INFO: Using main config file /data/workdir/config
Processing mydomain.duckdns.org with alternative names: mysub.mydomain.duckdns.org
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for mydomain.duckdns.org
 + Handling authorization for mysub.mydomain.duckdns.org
 + 2 pending challenge(s)
 + Deploying challenge tokens...
OK //result from my hook: set TXT for one domain
OK //result from my hook: set TXT for the other
 + Responding to challenge for mydomain.duckdns.org authorization...
 + Challenge is valid!
 + Responding to challenge for mysub.mydomain.duckdns.org authorization...
 + Cleaning challenge tokens...
OK
OK
 + 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 \"<redacted>\" found at _acme-challenge.mysub.mydomain.duckdns.org"
    "status": 403
  },
  "url": "https://acme-staging-v02.api.letsencrypt.org/acme/challenge/<redacted>",
  "token": "<redacted>"
})
Originally created by @KillianDS on GitHub (Sep 14, 2018). I currently try to get a single certificate for a duckdns domain and a sub domain, which fails. You can find some redacted output below for reference. I think dehydrated first deploys all challenges, then triggers validation for all domains and then cleans all challenges (HOOK_CHAIN is off). However, duckdns is a bit special in that sense that while they do support subdomains, these simply point to the same record as the main domain and you can only set the latter. So what seems to happen is: 1. Challenge token X is set for main domain 2. Challenge token Y is set for sub domain, this actually overrides X (my hook strips the sub-domain as per the above). 3. one of the validations fails because Y is not equal to X Am I doing something wrong on my end or is this a restriction of how dehydrated/ACME works? In the latter case, would it be possible to explicitly sequence deploy/validate/clean per (sub)domain via some option? about my setup: Config only overwrites CA (to use staging) and sets domain file. My domain file is really simple 'mydomain.duckdns.org mysub.mydomain.duckdns.org'. I validated and the hook is working just fine if I only try the single domain or sub-domain, it's the combination that fails. For reference: I tried using a wildcard certificate instead of a subdomain but that gave the same problem. In this case I actually don't understand how it could work even for other DNS providers, because dehydrated itself asked to install tokens for 'mydomain.duckdns.org' and 'mydomain.duckdns.org' (it stripped the *. itself), which would always conflict. ``` # INFO: Using main config file /data/workdir/config Processing mydomain.duckdns.org with alternative names: mysub.mydomain.duckdns.org + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 2 authorizations URLs from the CA + Handling authorization for mydomain.duckdns.org + Handling authorization for mysub.mydomain.duckdns.org + 2 pending challenge(s) + Deploying challenge tokens... OK //result from my hook: set TXT for one domain OK //result from my hook: set TXT for the other + Responding to challenge for mydomain.duckdns.org authorization... + Challenge is valid! + Responding to challenge for mysub.mydomain.duckdns.org authorization... + Cleaning challenge tokens... OK OK + 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 \"<redacted>\" found at _acme-challenge.mysub.mydomain.duckdns.org" "status": 403 }, "url": "https://acme-staging-v02.api.letsencrypt.org/acme/challenge/<redacted>", "token": "<redacted>" }) ```
adam closed this issue 2025-12-29 01:23:54 +01:00
Author
Owner

@alainwolf commented on GitHub (Sep 14, 2018):

Probably related to #553 and/or #554

Did you read the troubleshooting guide?
Why are DNS challenges deployed first and verified later?

@alainwolf commented on GitHub (Sep 14, 2018): Probably related to #553 and/or #554 Did you read the troubleshooting guide? [Why are DNS challenges deployed first and verified later?](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)
Author
Owner

@KillianDS commented on GitHub (Sep 14, 2018):

I missed that troubleshooting guide, my apologies. If I read that correctly the better solution would be to actually have duckdns support multiple txt records per domain, I will check with them.

@KillianDS commented on GitHub (Sep 14, 2018): I missed that troubleshooting guide, my apologies. If I read that correctly the better solution would be to actually have duckdns support multiple txt records per domain, I will check with them.
Author
Owner

@letroll commented on GitHub (Sep 22, 2018):

@KillianDS Have found a solution? I have same issue...

@letroll commented on GitHub (Sep 22, 2018): @KillianDS Have found a solution? I have same issue...
Author
Owner

@KillianDS commented on GitHub (Sep 25, 2018):

@letroll I don't have a technical solution, as explained in the link above the only way to work around that limitation is to do challenges one by one and to wait for the DNS cache to timeout in between. This would take a while, even with duckdns' short TTL.

I left a suggestion on duckdns' google+ community to support more than one TXT record but did not get any feedback on that.

In any case closing this here as it is indeed a duplicate of #553 (and #554)

@KillianDS commented on GitHub (Sep 25, 2018): @letroll I don't have a technical solution, as explained in the link above the only way to work around that limitation is to do challenges one by one and to wait for the DNS cache to timeout in between. This would take a while, even with duckdns' short TTL. I left a suggestion on duckdns' google+ community to support more than one TXT record but did not get any feedback on that. In any case closing this here as it is indeed a duplicate of #553 (and #554)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#375