Challenge invalid: Timeout, status 400 - but access_log shows status 200 #266

New Issue

adam · 2025-12-29T01:20:36+01:00

adam commented

2025-12-29 01:20:36 +01:00

Originally created by @ghost on GitHub (Nov 30, 2017).

Hi,

I am using dehydrated for some time and renewing my certificate wasn't an issue. But today, the renewal shows an error:

+ Requesting challenge for xxxx.de...
+ Hook: Nothing to do...
+ Responding to challenge for xxxx.de...
+ Hook: Nothing to do...
+ Hook: Nothing to do...
ERROR: Challenge is invalid! (returned: invalid) (result: {
 "type": "http-01",
 "status": "invalid",
 "error": {
   "type": "urn:acme:error:connection",
   "detail": "Fetching http://xxxx.de/.well-known/acme-challenge/tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM: Timeout",
   "status": 400
 },
 "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/pWM9zv9JB0g8obg-FcdYRAXQm1bK78PYclaw8GNJQGU/80195596",
 "token": "tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM",
 "keyAuthorization": "tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM.wh-2S3L2Mqy2m-WibDwtWYpjHWmcSHlHyNFqRFmznHk",
 "validationRecord": [
   {
     "url": "http://xxxx.de/.well-known/acme-challenge/tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM",
     "hostname": "xxxx.de",
     "port": "80",
     "addressesResolved": [
       "46.59.xxxx.15"
     ],
     "addressUsed": "46.59.xxxx.15",
     "addressesTried": []
   }
 ]
})

The apache access log shows:

66.133.109.36 - - [30/Nov/2017:21:46:00 +0100] "GET /.well-known/acme-challenge/tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM HTTP/1.1" 200 354 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
So I see, the webserver is accessible, the challenge was created and accessed by letsencrypt. Why there is a timeout?

Thank you,

Franz

Originally created by @ghost on GitHub (Nov 30, 2017). Hi, I am using dehydrated for some time and renewing my certificate wasn't an issue. But today, the renewal shows an error: ``` + Requesting challenge for xxxx.de... + Hook: Nothing to do... + Responding to challenge for xxxx.de... + Hook: Nothing to do... + Hook: Nothing to do... ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:connection", "detail": "Fetching http://xxxx.de/.well-known/acme-challenge/tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM: Timeout", "status": 400 }, "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/pWM9zv9JB0g8obg-FcdYRAXQm1bK78PYclaw8GNJQGU/80195596", "token": "tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM", "keyAuthorization": "tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM.wh-2S3L2Mqy2m-WibDwtWYpjHWmcSHlHyNFqRFmznHk", "validationRecord": [ { "url": "http://xxxx.de/.well-known/acme-challenge/tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM", "hostname": "xxxx.de", "port": "80", "addressesResolved": [ "46.59.xxxx.15" ], "addressUsed": "46.59.xxxx.15", "addressesTried": [] } ] }) ``` The apache access log shows: `66.133.109.36 - - [30/Nov/2017:21:46:00 +0100] "GET /.well-known/acme-challenge/tYa9u5rqyM8yYwUBAXCqeh_WNqzV41oXU23LbRSCkaM HTTP/1.1" 200 354 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" ` So I see, the webserver is accessible, the challenge was created and accessed by letsencrypt. Why there is a timeout? Thank you, Franz

adam closed this issue

2025-12-29 01:20:36 +01:00

adam commented

2025-12-29 01:20:38 +01:00

@lukas2511 commented on GitHub (Dec 5, 2017):

This doesn't look like a problem with dehydrated. If the problem still remains you should really double-check your webserver configuration (do you maybe have a proxy/cache in front of nginx?) or ask somebody on the LE forums.

@lukas2511 commented on GitHub (Dec 5, 2017): This doesn't look like a problem with dehydrated. If the problem still remains you should really double-check your webserver configuration (do you maybe have a proxy/cache in front of nginx?) or ask somebody on the LE forums.

adam commented

2025-12-29 01:20:39 +01:00

@ghost commented on GitHub (Dec 5, 2017):

Thank you, I found the issue. Letsencrypt validates with serveral source IP addresses. I configured iptables, so three of them were blocked. I modified my iptables configuration and validation was successful.

@ghost commented on GitHub (Dec 5, 2017): Thank you, I found the issue. Letsencrypt validates with serveral source IP addresses. I configured iptables, so three of them were blocked. I modified my iptables configuration and validation was successful.

adam commented

2025-12-29 01:20:39 +01:00

@alainwolf commented on GitHub (Dec 8, 2017):

Just for completion. The IP addresses of the validators is a frequent topic on the Let's Encrypt forums (e.g. see here). The answer from officials is always the same:

The IPs will not be disclosed.
The IPs may change frequently and some day even might use Tor for obfuscation.
If you block port 80/443 your doing it wrong.
If you don't want your web server reachable on the public internet, use DNS validation instead.

You want those IPs for security reasons to block anything else at your firewall. Well LE thinks the other way round. They don't disclose them for security reasons too, so they are not easily spoofed by an attacker.

@alainwolf commented on GitHub (Dec 8, 2017): Just for completion. The IP addresses of the validators is a frequent topic on the Let's Encrypt forums (e.g. [see here)](https://community.letsencrypt.org/t/ip-addresses-le-is-validating-from-to-build-firewall-rule/5410). The answer from officials is always the same: - The IPs will not be disclosed. - The IPs may change frequently and some day even might use Tor for obfuscation. - If you block port 80/443 your doing it wrong. - If you don't want your web server reachable on the public internet, use DNS validation instead. You want those IPs for security reasons to block anything else at your firewall. Well [LE thinks the other way round](https://community.letsencrypt.org/t/ip-addresses-le-is-validating-from-to-build-firewall-rule/5410/23). They don't disclose them for security reasons too, so they are not easily spoofed by an attacker.

adam referenced this issue

2025-12-29 01:29:06 +01:00

[PR #266] [CLOSED] Fix config logic for revoke command. #778

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#266