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 challange seems not working correctly #127

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

Originally created by @Tronic69 on GitHub (Jul 8, 2016).

Hello,

since a few days the dns challenge with inwx-acme (=> https://gist.github.com/jreinert/49aca3b5f3bf2c5d73d8) does not work anymore. It looks like dns entry is not created while using letsencrypt.sh:

Processing foo.bar.de
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Jul 24 09:15:00 2016 GMT (Less than 30 days). Renewing!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for foo.bar.de...
 + Responding to challenge for foo.bar.de...
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.foo.bar.de",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/ZEes5isuj1AUjy_xEBKurn71IWJhhXTBgyalzAzUYZU/163456229",
  "token": "HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI",
  "keyAuthorization": "HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI._JeC0mchoXHGH73Jf08LzvreL21_bOSeC3H4NQ_0X8Y"
})

If I use deploy_challange directly using the hook script it works:

# ./inwx-acme deploy_challenge foo.bar.de HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI

# dig TXT _acme-challenge.foo.bar.de

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> TXT _acme-challenge.foo.bar.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15365
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_acme-challenge.foo.bar.de.    IN  TXT

;; ANSWER SECTION:
_acme-challenge.foo.bar.de. 3600 IN TXT "HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI"

;; Query time: 23 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul  8 12:10:32 2016
;; MSG SIZE  rcvd: 100

Any ideas why it does not work anymore and how to debug it?

Originally created by @Tronic69 on GitHub (Jul 8, 2016). Hello, since a few days the dns challenge with inwx-acme (=> https://gist.github.com/jreinert/49aca3b5f3bf2c5d73d8) does not work anymore. It looks like dns entry is not created while using letsencrypt.sh: ``` Processing foo.bar.de + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Jul 24 09:15:00 2016 GMT (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for foo.bar.de... + Responding to challenge for foo.bar.de... ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "dns-01", "status": "invalid", "error": { "type": "urn:acme:error:connection", "detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.foo.bar.de", "status": 400 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/ZEes5isuj1AUjy_xEBKurn71IWJhhXTBgyalzAzUYZU/163456229", "token": "HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI", "keyAuthorization": "HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI._JeC0mchoXHGH73Jf08LzvreL21_bOSeC3H4NQ_0X8Y" }) ``` If I use deploy_challange directly using the hook script it works: ``` # ./inwx-acme deploy_challenge foo.bar.de HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI # dig TXT _acme-challenge.foo.bar.de ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> TXT _acme-challenge.foo.bar.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15365 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_acme-challenge.foo.bar.de. IN TXT ;; ANSWER SECTION: _acme-challenge.foo.bar.de. 3600 IN TXT "HHzFaTGm-Usb23_xEJJ0q8DeWoLLssiGvjpWIyjpTkI" ;; Query time: 23 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 8 12:10:32 2016 ;; MSG SIZE rcvd: 100 ``` Any ideas why it does not work anymore and how to debug it?
adam closed this issue 2025-12-29 00:25:29 +01:00
adam commented 2025-12-29 00:25:30 +01:00
Author
Owner
Copy Link

@gertcuykens commented on GitHub (Jul 10, 2016):

I think the dns server need more time, can you try to put a sleep timeout in letsencrypt.sh just before it is asking to verify the DNS challange.

@gertcuykens commented on GitHub (Jul 10, 2016): I think the dns server need more time, can you try to put a sleep timeout in `letsencrypt.sh` just before it is asking to verify the DNS challange.
adam commented 2025-12-29 00:25:30 +01:00
Author
Owner
Copy Link

@lxp commented on GitHub (Jul 10, 2016):

I think hook scripts should ensure that the challenge is fully deployed before they return.
So, I would put the sleep at the end of deploy_challenge in the hook script, if there is no better way to ensure deployment.

@lxp commented on GitHub (Jul 10, 2016): I think hook scripts should ensure that the challenge is fully deployed before they return. So, I would put the sleep at the end of deploy_challenge in the hook script, if there is no better way to ensure deployment.
adam commented 2025-12-29 00:25:30 +01:00
Author
Owner
Copy Link

@germeier commented on GitHub (Jul 10, 2016):

see: https://community.letsencrypt.org/t/dns-challenge-is-in-staging/8322/20

@germeier commented on GitHub (Jul 10, 2016): see: https://community.letsencrypt.org/t/dns-challenge-is-in-staging/8322/20
adam commented 2025-12-29 00:25:31 +01:00
Author
Owner
Copy Link

@txr13 commented on GitHub (Jul 11, 2016):

I note that https://github.com/bennettp123/letsencrypt.sh-email-notify-hook (linked from the wiki section of this project, under "Examples for DNS 01 hooks") implements a check where it sleeps and verifies that DNS has propagated before it returns from deploying the challenge.

Hooks that implement a similar check will probably be okay? I have had the odd instance (several versions ago) where the hook's check would pass, but LE would fail the challenge verification anyway... so in the worst case, maybe you add a couple of sleeps after the hook's check returns, just to try and hedge your bets?

@txr13 commented on GitHub (Jul 11, 2016): I note that https://github.com/bennettp123/letsencrypt.sh-email-notify-hook (linked from the wiki section of this project, under "Examples for DNS 01 hooks") implements a check where it sleeps and verifies that DNS has propagated before it returns from deploying the challenge. Hooks that implement a similar check will _probably_ be okay? I have had the odd instance (several versions ago) where the hook's check would pass, but LE would fail the challenge verification anyway... so in the worst case, maybe you add a couple of sleeps after the hook's check returns, just to try and hedge your bets?
adam commented 2025-12-29 00:25:31 +01:00
Author
Owner
Copy Link

@Tronic69 commented on GitHub (Jul 11, 2016):

@lxp

I think hook scripts should ensure that the challenge is fully deployed before they return.
So, I would put the sleep at the end of deploy_challenge in the hook script, if there is no better way to ensure deployment.

I agree, the best option would be that the hook-scripts will check DNS entries after deploying them. But that's not implemented, yet.

@gertcuykens
I already had put some sleeps into it, but after that it was only working for the first domain of a multi-domain certificate.
I have now tested a bit more an found a working version with 3 sleeps:

# Respond to challenges
  idx=0
  for altname in ${altnames}; do
    challenge_token="${challenge_tokens[${idx}]}"
    keyauth="${keyauths[${idx}]}"

    # Wait for hook script to deploy the challenge if used
    # shellcheck disable=SC2086
    [[ -n "${HOOK}" ]] && [[ "${HOOK_CHAIN}" != "yes" ]] && "${HOOK}" "deploy_challenge" ${deploy_args[${idx}]}

    ###### Tronic69: wait 10 seconds ...
    sleep 10

    # Ask the acme-server to verify our challenge and wait until it is no longer pending
    echo " + Responding to challenge for ${altname}..."
    result="$(signed_request "${challenge_uris[${idx}]}" '{"resource": "challenge", "keyAuthorization": "'"${keyauth}"'"}' | clean_json)"

    reqstatus="$(printf '%s\n' "${result}" | get_json_string_value status)"

    while [[ "${reqstatus}" = "pending" ]]; do
      ###### Tronic69: wait 5 seconds ...
      sleep 5
      result="$(http_request get "${challenge_uris[${idx}]}")"
      reqstatus="$(printf '%s\n' "${result}" | get_json_string_value status)"
    done

    [[ "${CHALLENGETYPE}" = "http-01" ]] && rm -f "${WELLKNOWN}/${challenge_token}"

    # Wait for hook script to clean the challenge if used
    if [[ -n "${HOOK}" ]] && [[ "${HOOK_CHAIN}" != "yes" ]] && [[ -n "${challenge_token}" ]]; then
      # shellcheck disable=SC2086
      "${HOOK}" "clean_challenge" ${deploy_args[${idx}]}
    fi
    idx=$((idx+1))

    if [[ "${reqstatus}" = "valid" ]]; then
      echo " + Challenge is valid!"
    else
      break
    fi
      ##### Tronic69: wait 10 seconds
      sleep 10
  done

I know, the longer middle sleep (default: 1) makes not really sense, but after increasing it it worked. ^^
Maybe the (first and thrid) sleep time should be configurable in config.

@Tronic69 commented on GitHub (Jul 11, 2016): @lxp > I think hook scripts should ensure that the challenge is fully deployed before they return. > So, I would put the sleep at the end of deploy_challenge in the hook script, if there is no better way to ensure deployment. I agree, the best option would be that the hook-scripts will check DNS entries after deploying them. But that's not implemented, yet. @gertcuykens I already had put some sleeps into it, but after that it was only working for the first domain of a multi-domain certificate. I have now tested a bit more an found a working version with 3 sleeps: ``` # Respond to challenges idx=0 for altname in ${altnames}; do challenge_token="${challenge_tokens[${idx}]}" keyauth="${keyauths[${idx}]}" # Wait for hook script to deploy the challenge if used # shellcheck disable=SC2086 [[ -n "${HOOK}" ]] && [[ "${HOOK_CHAIN}" != "yes" ]] && "${HOOK}" "deploy_challenge" ${deploy_args[${idx}]} ###### Tronic69: wait 10 seconds ... sleep 10 # Ask the acme-server to verify our challenge and wait until it is no longer pending echo " + Responding to challenge for ${altname}..." result="$(signed_request "${challenge_uris[${idx}]}" '{"resource": "challenge", "keyAuthorization": "'"${keyauth}"'"}' | clean_json)" reqstatus="$(printf '%s\n' "${result}" | get_json_string_value status)" while [[ "${reqstatus}" = "pending" ]]; do ###### Tronic69: wait 5 seconds ... sleep 5 result="$(http_request get "${challenge_uris[${idx}]}")" reqstatus="$(printf '%s\n' "${result}" | get_json_string_value status)" done [[ "${CHALLENGETYPE}" = "http-01" ]] && rm -f "${WELLKNOWN}/${challenge_token}" # Wait for hook script to clean the challenge if used if [[ -n "${HOOK}" ]] && [[ "${HOOK_CHAIN}" != "yes" ]] && [[ -n "${challenge_token}" ]]; then # shellcheck disable=SC2086 "${HOOK}" "clean_challenge" ${deploy_args[${idx}]} fi idx=$((idx+1)) if [[ "${reqstatus}" = "valid" ]]; then echo " + Challenge is valid!" else break fi ##### Tronic69: wait 10 seconds sleep 10 done ``` I know, the longer middle sleep (default: 1) makes not really sense, but after increasing it it worked. ^^ Maybe the (first and thrid) sleep time should be configurable in config.
adam commented 2025-12-29 00:25:31 +01:00
Author
Owner
Copy Link

@benediktg commented on GitHub (Jul 11, 2016):

This patch should add the sleep time only if you are using CHALLENGETYPE="dns-01". You can apply it by

cd /opt/letsencrypt.sh  # or where your cloned letsencrypt.sh repository is
wget -Osleep.patch https://github.com/lukas2511/letsencrypt.sh/files/358017/sleep.patch.txt
git apply sleep.patch

Configurable sleep times should be possible by introducing someting like SLEEPTIME=10 in the config file and calling sleep "${SLEEPTIME}" instead of just sleep 10 in letsencrypt.sh.

Reverting this patch is possible by

git apply -R sleep.patch
rm sleep.patch

😉

@benediktg commented on GitHub (Jul 11, 2016): This [patch](https://github.com/lukas2511/letsencrypt.sh/files/358017/sleep.patch.txt) should add the sleep time only if you are using `CHALLENGETYPE="dns-01"`. You can apply it by ``` sh cd /opt/letsencrypt.sh # or where your cloned letsencrypt.sh repository is wget -Osleep.patch https://github.com/lukas2511/letsencrypt.sh/files/358017/sleep.patch.txt git apply sleep.patch ``` Configurable sleep times should be possible by introducing someting like `SLEEPTIME=10` in the config file and calling `sleep "${SLEEPTIME}"` instead of just `sleep 10` in `letsencrypt.sh`. Reverting this patch is possible by ``` sh git apply -R sleep.patch rm sleep.patch ``` :wink:
adam commented 2025-12-29 00:25:31 +01:00
Author
Owner
Copy Link

@txr13 commented on GitHub (Jul 11, 2016):

I really feel like this should be handled in the relevant hook script(s), not as a patch to letsencrypt.sh itself...

@txr13 commented on GitHub (Jul 11, 2016): I really feel like this should be handled in the relevant hook script(s), not as a patch to letsencrypt.sh itself...
adam commented 2025-12-29 00:25:32 +01:00
Author
Owner
Copy Link

@tomchiverton commented on GitHub (Jul 14, 2016):

The challenge script should be responsible for deploying the change, waiting till it's applied e.g. by querying DNS back again, and then exiting.

This is what letsencrypt.sh is expecting

@tomchiverton commented on GitHub (Jul 14, 2016): The challenge script should be responsible for deploying the change, waiting till it's applied e.g. by querying DNS back again, and then exiting. This is what letsencrypt.sh is expecting
adam commented 2025-12-29 00:25:32 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Jul 20, 2016):

Yea everything that has to do with rolling out these challenges should be done in the hook script, even the waiting for DNS updates. There are way to many different setups out there to do this cleanly within letsencrypt.sh. Closing this issue.

@lukas2511 commented on GitHub (Jul 20, 2016): Yea everything that has to do with rolling out these challenges should be done in the hook script, even the waiting for DNS updates. There are way to many different setups out there to do this cleanly within letsencrypt.sh. Closing this issue.
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#127
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?