request for wildcard-certificate and base certificate failed #374

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

Originally created by @fbuescher on GitHub (Aug 28, 2018).

hi,
i tried to get a certificate for *.photoprintit.de and photoprintit.de (in that order) and got a challenge-error:

./dehydrated -c -d *.photoprintit.de -d photoprintit.de --alias STAR.photoprintit.de -f /PRODUCTION/ssl/_lets-encrypt/config/config_dns -k /PRODUCTION/ssl/_lets-encrypt/hook_dns.sh -t dns-01

Processing *.photoprintit.de with alternative names: photoprintit.de

  • Creating new directory /PRODUCTION/ssl/_lets-encrypt/config/certs/star.photoprintit.de ...
  • Signing domains...
  • Generating private key...
  • Generating signing request...
  • Requesting new certificate order from CA...
  • Received 2 authorizations URLs from the CA
  • Handling authorization for photoprintit.de
  • Handling authorization for photoprintit.de
  • 2 pending challenge(s)
  • Deploying challenge tokens...

adding the following to the zone definition of photoprintit.de:
_acme-challenge.photoprintit.de. IN TXT "-EtJpdg-kjO088CKlAvCD1JxYF7RxQcXaCOCoq7Ikrw"

adding the following to the zone definition of photoprintit.de:
_acme-challenge.photoprintit.de. IN TXT "asEw1YRSVYCjrh6cztSYjhl7YAUOgB4AfJjqOBh7ZWg"

  • Responding to challenge for photoprintit.de authorization...
  • Challenge is valid!
  • Responding to challenge for photoprintit.de authorization...

invalid_challenge()
photoprintit.de
{
"type": "dns-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Incorrect TXT record "-EtJpdg-kjO088CKlAvCD1JxYF7RxQcXaCOCoq7Ikrw" found at _acme-challenge.photoprintit.de",
"status": 403
},
"url": "https://acme-v02.api.letsencrypt.org/acme/challenge/WZySwmWePdtFQ-5c8MgZ37L73s1bNgLedvsUfqmM85o/6848729146",
"token": "jETTFm5BM19ogdzzr8YxKd_XVVcJetzYj-E0K0YOo9c"
}

############################################

it looks like there are two txt-entries generated (which are served roundrobin by dns) and the auth request from letsencrypt got the wrong one.

i wonder, if the following lines are indicating the problem:

  • Handling authorization for photoprintit.de
  • Handling authorization for photoprintit.de

both challenge token are written to _acme-challenge.photoprintit.de. Is that correct?

after i rerun the process three times, everything worked (because dns served the correct challenge by accident)

any clue?

regards,
Friedhelm

Originally created by @fbuescher on GitHub (Aug 28, 2018). hi, i tried to get a certificate for *.photoprintit.de and photoprintit.de (in that order) and got a challenge-error: ./dehydrated -c -d *.photoprintit.de -d photoprintit.de --alias STAR.photoprintit.de -f /PRODUCTION/ssl/_lets-encrypt/config/config_dns -k /PRODUCTION/ssl/_lets-encrypt/hook_dns.sh -t dns-01 Processing *.photoprintit.de with alternative names: photoprintit.de + Creating new directory /PRODUCTION/ssl/_lets-encrypt/config/certs/star.photoprintit.de ... + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 2 authorizations URLs from the CA + Handling authorization for photoprintit.de + Handling authorization for photoprintit.de + 2 pending challenge(s) + Deploying challenge tokens... adding the following to the zone definition of photoprintit.de: _acme-challenge.photoprintit.de. IN TXT "-EtJpdg-kjO088CKlAvCD1JxYF7RxQcXaCOCoq7Ikrw" adding the following to the zone definition of photoprintit.de: _acme-challenge.photoprintit.de. IN TXT "asEw1YRSVYCjrh6cztSYjhl7YAUOgB4AfJjqOBh7ZWg" + Responding to challenge for photoprintit.de authorization... + Challenge is valid! + Responding to challenge for photoprintit.de authorization... invalid_challenge() photoprintit.de { "type": "dns-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Incorrect TXT record \"-EtJpdg-kjO088CKlAvCD1JxYF7RxQcXaCOCoq7Ikrw\" found at _acme-challenge.photoprintit.de", "status": 403 }, "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/WZySwmWePdtFQ-5c8MgZ37L73s1bNgLedvsUfqmM85o/6848729146", "token": "jETTFm5BM19ogdzzr8YxKd_XVVcJetzYj-E0K0YOo9c" } ############################################ it looks like there are two txt-entries generated (which are served roundrobin by dns) and the auth request from letsencrypt got the wrong one. i wonder, if the following lines are indicating the problem: > + Handling authorization for photoprintit.de > + Handling authorization for photoprintit.de both challenge token are written to _acme-challenge.photoprintit.de. Is that correct? after i rerun the process three times, everything worked (because dns served the correct challenge by accident) any clue? regards, Friedhelm
adam closed this issue 2025-12-29 01:23:54 +01:00
Author
Owner

@lukas2511 commented on GitHub (Aug 28, 2018):

You are probably running into the same issue as a lot of other people: Your hook-script overwrites the old txt record instead of adding a second one. Dehydrated doesn't know which is used for the wildcard so it has to prepare both before doing any verification. 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 for more details.

@lukas2511 commented on GitHub (Aug 28, 2018): You are probably running into the same issue as a lot of other people: Your hook-script overwrites the old txt record instead of adding a second one. Dehydrated doesn't know which is used for the wildcard so it has to prepare both before doing any verification. 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 for more details.
Author
Owner

@fbuescher commented on GitHub (Aug 29, 2018):

Just an update.
Issue was on our side, but other than you suggested.

we have a hook_dns script which updates our bind9 with nsupdate. After updating the first txt record, the changes are visible immediate. When i update the second txt entry, it takes about 6 seconds to become visible. I guess, our bind is busy with notifying the peers with the first new entry and needs some time to finish.

workaround: adding a "sleep 10" after the nsupdate in the hook_dns ...

thanks for your prompt answer!

@fbuescher commented on GitHub (Aug 29, 2018): Just an update. Issue was on our side, but other than you suggested. we have a hook_dns script which updates our bind9 with nsupdate. After updating the first txt record, the changes are visible immediate. When i update the second txt entry, it takes about 6 seconds to become visible. I guess, our bind is busy with notifying the peers with the first new entry and needs some time to finish. workaround: adding a "sleep 10" after the nsupdate in the hook_dns ... thanks for your prompt answer!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#374