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
@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.
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!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
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"
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:
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
@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.
@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!