Sticky: How to troubleshoot E_FAIL_DRY_CHALLENGE #4

New Issue

coolaj86 · 2018-05-18T06:47:26Z

coolaj86 commented

2018-05-18 06:47:26 +00:00

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

2018-05-18 06:50:43 +00:00

Sign in to join this conversation.

No Label

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coolaj86/acme.js-ARCHIVED#4