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.
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:
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
于 2018-05-18 06:50:43 +00:00 修改标题 Sticky: How to troubleshoot E_PREFAIL_CHALLENGE 为 Sticky: How to troubleshoot E_FAIL_DRY_CHALLENGE
E_FAIL_DRY_CHALLENGE
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:
le-challenge-....module is not properly configured or wasn't tested by the author before the latest releaseFailed DNS-01 Dry Run
Basically this means that
dig TXT _acme-challenge.whatever.comdid not return the appropriate<<keyAuthorizationHash>>challenge record in the list of TXT records queried at your nameserver.Common reasons for failure:
dig +trace TXT _acme-challenge.whatever.coma few times on the server before trying againle-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_acme-challengeDNS record was magically deleted... ?Triggering Errors (on purpose) for Testing
You can literally use
example.comin this instance.This will cause curl to set the https SNI (servername indicator) to "example.com" while resolving it to your local server.
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: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:
Sticky: How to troubleshoot E_PREFAIL_CHALLENGE为 Sticky: How to troubleshoot E_FAIL_DRY_CHALLENGE