Invalid response from http://mywebsite.com/.well-known/acme-challenge/oZ66T7W1ROegLzBZC9AsjurwjiBak-L0UyffdWwP9Zk: 204

I ran this command: I wanted to install a SSL certificate with let's encrypt

It produced this output: Domain could not be validated, error message: error type: urn:ietf:params:acme:error:unauthorized, error detail: 2001:8d8:100f:f000::200: Invalid response from Buying and selling domains by experts | Hire a broker today! | Sedo 204
Invalid response from Buying and selling domains by experts | Hire a broker today! | Sedo 204

My web server is (include version): NGINX

The operating system my web server runs on is (include version): Ubuntu 22.04

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): cloud panel

For test purpose I created a test file http://chezjescobi.com/.well-known/acme-challenge/test.txt and this file can be accessed successfully over HTTP. Moreover the domain and subdomain are pointing correctly to the IP address where the website is hosted.

This is my server configuration

server {

listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
{{ssl_certificate_key}}
{{ssl_certificate}}
server_name mywebsite.com www.mywebsite.com;
root /home/user/htdocs/basic/web;
index index.php;

if ($scheme != "https") {
rewrite ^ https://$host$uri permanent;
}

location ~ /.well-known {
auth_basic off;
allow all;
}

{{settings}}

location / {
{{varnish_proxy_pass}}
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_hide_header X-Varnish;
proxy_redirect off;
proxy_max_temp_file_size 0;
proxy_connect_timeout 720;
proxy_send_timeout 720;
proxy_read_timeout 720;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
}

location ~* ^.+.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map)$ {
add_header Access-Control-Allow-Origin "*";
expires max;
access_log off;
}

if (-f $request_filename) {
break;
}
}

server {
listen 8080;
listen [::]:8080;

server_name mywebsite.com www.mywebsite.com;
root /home/user/htdocs/basic/web;
index index.php;

try_files $uri $uri/ /index.php?$args;
index index.php index.html;

location ~ .php$ {
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri =404;
fastcgi_read_timeout 3600;
fastcgi_send_timeout 3600;
fastcgi_param HTTPS "on";
fastcgi_param SERVER_PORT 443;
fastcgi_pass 127.0.0.1:{{php_fpm_port}};
fastcgi_param PHP_VALUE "{{php_settings}}";
}

if (-f $request_filename) {
break;
}
}

It seems the Let's Encrypt validation server only allows HTTP 200 status codes as valid (next to some redirects that is).

Your server is sending HTTP 204 status codes for some reason. For the challenge file and your test file that is. For your main site, it's returning a 404 file not found :thinking:

2 Likes

204 is a successful code but it also means "nothing to see here"

Clients don't usually expect a response body, with 204.

3 Likes

Interestingly enough the Baseline Requirements only require a 2xx response, so instead of 200, a status of 204 would be just fine.

The ACME protocol (RFC 8555) does not specify anything with regard to the HTTP status code.

1 Like

It assumes a response body, tho

A 204 response is terminated by the end of the header section; it cannot contain content or trailers.

4 Likes

True true, you'd need some content for a successful challenge anyway :grin:

1 Like

What shoul I do now?

By the way, there's an Apache webserver responding on your IP addresses. Not nginx.

2 Likes

Is there any suggestion changes that I can make in the server configuration?

Show us the full nginx config. There's something that makes these 204s. It's either nginx or your application.

nginx -T

And use backticks

```
Like this
```
3 Likes

The full nginx configuration is in my description of the issue on the top

It doesn't look that full. But also read above, you have Apache responding. Check your Apache config, assuming it's on the same machine.

3 Likes

That's not going to help if an Apache server is responding. But weirdly enough there's an nginx responding for the challenge, but Apache for the main server.

2 Likes

Why do you think that there is apache server responding for main server?

Because that's how the webserver identifies itself:

osiris@erazer ~ $ curl -Lv http://chezjescobi.com/
*   Trying [2001:8d8:100f:f000::200]:80...
* Connected to chezjescobi.com (2001:8d8:100f:f000::200) port 80 (#0)
> GET / HTTP/1.1
> Host: chezjescobi.com
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Content-Type: text/html
< Content-Length: 601
< Connection: keep-alive
< Keep-Alive: timeout=15
< Date: Mon, 11 Sep 2023 17:02:13 GMT
< Server: Apache
< 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>
   Error 404 - Not found
  </title>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="no-cache" http-equiv="cache-control">
 </head>
 <body style="font-family:arial;">
  <h1 style="color:#0a328c;font-size:1.0em;">
   Error 404 - Not found
  </h1>
  <p style="font-size:0.8em;">
   Die angegebene Seite konnte nicht gefunden werden.
  </p>
 </body>
</html>
* Connection #0 to host chezjescobi.com left intact
osiris@erazer ~ $
1 Like

We should've known.

~
❯ curl -IL http://chezjescobi.com/ -4
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 11 Sep 2023 17:04:07 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://chezjescobi.com/
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Permitted-Cross-Domain-Policies: master-only
Referrer-Policy: same-origin

curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

~
❯ curl -IL http://chezjescobi.com/ -6
HTTP/1.1 404 Not Found
Content-Type: text/html
Connection: keep-alive
Keep-Alive: timeout=15
Date: Mon, 11 Sep 2023 17:04:17 GMT
Server: Apache

IPv6 and IPv4 go to different machines.

5 Likes

Not from my point of view, I get the same 404 error for IPv4 and IPv6.

2 Likes

There are two A records. I got 85.31.238.86.

5 Likes

Ah, that would explain a lot indeed. For some reason I'm only connecting to 217.160.0.229.

But that wouldn't fix the 204 error, unless the IPv6 address is also not correct.

2 Likes

How should be normally the Ipv6 adress configured normally? the Domain and subdomain were only connected to the ipv4 address of the host.