Challenge appears to be deleted before validation #231

New Issue

adam · 2025-12-29T01:19:26+01:00

adam commented

2025-12-29 01:19:26 +01:00

Originally created by @tjbp on GitHub (Jun 26, 2017).

Hi all - am attempting to use dehydrated -c to renew my certificates, and am running into a strange problem. I have nginx configured to catch the challenge request:

server {
    listen 80;
    server_name my.domain;

    location ^~ /.well-known/acme-challenge {
        alias /var/lib/dehydrated/acme-challenges;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

If I place a file test.html inside /var/lib/dehydrated/acme-challenges, I can access it via HTTP without issue at http://my.domain/.well-known/acme-challenge/test.html. When I run dehydrated -c and monitor the directory I see the challenge file momentarily appear, then disappear again. Nginx always serves a 404 not found to the validation server, as if the challenge was deleted early or created late. Could this be possible?

This is my config:

CONFIG_D=/etc/dehydrated/conf.d
BASEDIR=/var/lib/dehydrated
WELLKNOWN="${BASEDIR}/acme-challenges"
DOMAINS_TXT="/etc/dehydrated/domains.txt"

This is the output:

Processing my.domain
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Jun 18 04:00:00 2017 GMT (Less than 30 days). Renewing!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for my.domain...
 + Responding to challenge for my.domain...
ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Invalid response from http://my.domain/.well-known/acme-challenge/rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c: \"\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003e\"",
    "status": 403
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/6XMnOh0ZyG6RcZdIxuIe1VxMTEtPVJxc-yNONiKBZO4/1422950687",
  "token": "rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c",
  "keyAuthorization": "rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c.T9vNIBjkPIw64N7_VHXt7rw6P-u0v0CsAPd-VE1QqfI",
  "validationRecord": [
    {
      "url": "http://my.domain/.well-known/acme-challenge/rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c",
      "hostname": "my.domain",
      "port": "80",
      "addressesResolved": [
        "**.**.**.**",
        ":**"
      ],
      "addressUsed": ":**",
      "addressesTried": []
    }
  ]
})

Originally created by @tjbp on GitHub (Jun 26, 2017). Hi all - am attempting to use `dehydrated -c` to renew my certificates, and am running into a strange problem. I have nginx configured to catch the challenge request: ``` server { listen 80; server_name my.domain; location ^~ /.well-known/acme-challenge { alias /var/lib/dehydrated/acme-challenges; } location / { return 301 https://$host$request_uri; } } ``` If I place a file `test.html` inside `/var/lib/dehydrated/acme-challenges`, I can access it via HTTP without issue at http://my.domain/.well-known/acme-challenge/test.html. When I run `dehydrated -c` and monitor the directory I see the challenge file momentarily appear, then disappear again. Nginx always serves a 404 not found to the validation server, as if the challenge was deleted early or created late. Could this be possible? This is my config: ``` CONFIG_D=/etc/dehydrated/conf.d BASEDIR=/var/lib/dehydrated WELLKNOWN="${BASEDIR}/acme-challenges" DOMAINS_TXT="/etc/dehydrated/domains.txt" ``` This is the output: ``` Processing my.domain + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Jun 18 04:00:00 2017 GMT (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for my.domain... + Responding to challenge for my.domain... ERROR: Challenge is invalid! (returned: invalid) (result: { "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:unauthorized", "detail": "Invalid response from http://my.domain/.well-known/acme-challenge/rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c: \"\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003e\"", "status": 403 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/6XMnOh0ZyG6RcZdIxuIe1VxMTEtPVJxc-yNONiKBZO4/1422950687", "token": "rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c", "keyAuthorization": "rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c.T9vNIBjkPIw64N7_VHXt7rw6P-u0v0CsAPd-VE1QqfI", "validationRecord": [ { "url": "http://my.domain/.well-known/acme-challenge/rInpsmtmJYctGn9yPHImSvEE-v7vW6Vipid72vjwV8c", "hostname": "my.domain", "port": "80", "addressesResolved": [ "**.**.**.**", ":**" ], "addressUsed": ":**", "addressesTried": [] } ] }) ```

adam closed this issue

2025-12-29 01:19:26 +01:00

adam commented

2025-12-29 01:19:26 +01:00

@shoeper commented on GitHub (Jun 26, 2017):

Have you checked if the challenge has acutally been there using ls? A permission problem is much more likely.

@shoeper commented on GitHub (Jun 26, 2017): Have you checked if the challenge has acutally been there using ls? A permission problem is much more likely.

adam commented

2025-12-29 01:19:27 +01:00

@txr13 commented on GitHub (Jun 26, 2017):

The addressUsed is IPv6. Is Nginx listening and reachable on IPv6?

@txr13 commented on GitHub (Jun 26, 2017): The addressUsed is IPv6. Is Nginx listening and reachable on IPv6?

adam commented

2025-12-29 01:19:27 +01:00

@tjbp commented on GitHub (Jun 27, 2017):

@txr13 D'oh, well spotted - that was it. Thanks!

@tjbp commented on GitHub (Jun 27, 2017): @txr13 D'oh, well spotted - that was it. Thanks!

adam referenced this issue

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