starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-09-02 17:37:12 +02:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2025-12-29 01:20:36 +01:00 by adam · 3 comments
adam commented 2025-12-29 01:20:36 +01:00
Owner
Copy Link
Copy Source

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
Author
Owner
Copy Link
Copy Source

@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
Author
Owner
Copy Link
Copy Source

@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
Author
Owner
Copy Link
Copy Source

@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.
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 labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#266