Sticky: How to troubleshoot E_FAIL_DRY_CHALLENGE #4

Open
opened 4 years ago by coolaj86 · 0 comments
coolaj86 commented 4 years ago
Owner

E_FAIL_DRY_CHALLENGE

early-warning detection ability that borders on pre-cognition

In order to decrease the likelihood of being blocked for hitting bad request rate limits I implemented a "dry run" to catch errors before the real request is made to the ACME server.

Failed HTTP-01 Dry Run

Basically this means that curl https://whatever.com/.well-known/acme-challenge/<<token>> did not return a valid <<keyAuthorization>>

Common reasons for failure:

  • Port 80 is not publicly available, blocked by a firewall, not properly port-forwarded or tunneled
  • The IP address of your domain doesn't point or port-forward to your server
  • The le-challenge-.... module is not properly configured or wasn't tested by the author before the latest release
  • The challenge file was magically deleted... ?

Failed DNS-01 Dry Run

Basically this means that dig TXT _acme-challenge.whatever.com did not return the appropriate <<keyAuthorizationHash>> challenge record in the list of TXT records queried at your nameserver.

Common reasons for failure:

  • The DNS record did not propagate to the nameservers in time
  • Your local DNS cache as old bad values, run dig +trace TXT _acme-challenge.whatever.com a few times on the server before trying again
  • The le-challenge-.... module is not properly configured or wasn't tested by the author before the latest release and isn't actually adding the proper records
  • The _acme-challenge DNS record was magically deleted... ?

Triggering Errors (on purpose) for Testing

You can literally use example.com in this instance.

This will cause curl to set the https SNI (servername indicator) to "example.com" while resolving it to your local server.

curl --resolve example.com:443:127.0.0.1 https://example.com

Meanwhile, 'example.com' actually has an address that resolves to something that isn't 127.0.0.1, which means that it will create the error state of not being able to fetch the challenge.

If you try this with a name that doesn't exist, you won't get far enough in the process to trigger the error you're intending to trigger. You can spoof this by adding that domain to your /etc/hosts:

sudo bash -c "echo '98.138.219.231 doesntexist.com' >> /etc/hosts"

It's important that you don't set the IP to a local address, otherwise it will succeed instead of failing.

Then you still need to use the same curl trick from above:

curl --resolve doesntexist.com:443:127.0.0.1 https://doesntexist.com
E_FAIL_DRY_CHALLENGE ==================== > early-warning detection ability that borders on pre-cognition In order to decrease the likelihood of being blocked for hitting bad request rate limits I implemented a "dry run" to catch errors before the real request is made to the ACME server. Failed HTTP-01 Dry Run ====================== Basically this means that `curl https://whatever.com/.well-known/acme-challenge/<<token>>` did not return a valid `<<keyAuthorization>>` Common reasons for failure: * Port 80 is not publicly available, blocked by a firewall, not properly port-forwarded or tunneled * The IP address of your domain doesn't point or port-forward to your server * The `le-challenge-....` module is not properly configured or wasn't tested by the author before the latest release * The challenge file was magically deleted... ? Failed DNS-01 Dry Run ===================== Basically this means that `dig TXT _acme-challenge.whatever.com` did not return the appropriate `<<keyAuthorizationHash>>` challenge record in the list of TXT records queried at your nameserver. Common reasons for failure: * The DNS record did not propagate to the nameservers in time * Your local DNS cache as old bad values, run `dig +trace TXT _acme-challenge.whatever.com` a few times on the server before trying again * The `le-challenge-....` module is not properly configured or wasn't tested by the author before the latest release and isn't actually adding the proper records * The `_acme-challenge` DNS record was magically deleted... ? Triggering Errors (on purpose) for Testing ============================= You can literally use `example.com` in this instance. This will cause curl to set the https SNI (servername indicator) to "example.com" while resolving it to your local server. ``` curl --resolve example.com:443:127.0.0.1 https://example.com ``` Meanwhile, 'example.com' actually has an address that resolves to something that isn't 127.0.0.1, which means that it will create the error state of not being able to fetch the challenge. If you try this with a name that doesn't exist, you won't get far enough in the process to trigger the error you're intending to trigger. You can spoof this by adding that domain to your `/etc/hosts`: ``` sudo bash -c "echo '98.138.219.231 doesntexist.com' >> /etc/hosts" ``` It's important that you don't set the IP to a local address, otherwise it will succeed instead of failing. Then you still need to use the same curl trick from above: ``` curl --resolve doesntexist.com:443:127.0.0.1 https://doesntexist.com ```
coolaj86 changed title from Sticky: How to troubleshoot E_PREFAIL_CHALLENGE to Sticky: How to troubleshoot E_FAIL_DRY_CHALLENGE 4 years ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.