404 on .well-known

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: unknownsaints.com

I ran this command: nginx -T

It produced this output: `# configuration file /etc/nginx/nginx.conf:
user http;
worker_processes auto;
worker_cpu_affinity auto;

events {
multi_accept on;
worker_connections 1024;
}

http {
charset utf-8;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
log_not_found off;
types_hash_max_size 4096;
client_max_body_size 4M;

MIME

include mime.types;
default_type application/octet-stream;

logging

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;

We will need this when proxying requests to other machines.

#upstream blackhatui {

ip_hash;

server 127.0.0.1;

#}

server {
root /usr/share/www/unknownsaints.com;
index index.html index.htm;
server_name 162.218.222.200 unknownsaints.com www.unknownsaints.com;

location / {
}

# Serve static assets
location /static/ {
  autoindex on;
  root /usr/share/www/unknownsaints.com/static;
}


listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/unknownsaints.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/unknownsaints.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
include letsencrypt.conf;

if ($host = www.unknownsaints.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot


if ($host = unknownsaints.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot



server_name 162.218.222.200 unknownsaints.com www.unknownsaints.com;
listen 80 default_server;
return 404; # managed by Certbot

}
}

… mimes omitted …

configuration file /etc/letsencrypt/options-ssl-nginx.conf:

This file contains important security parameters. If you modify this file

manually, Certbot will be unable to automatically provide future security

updates. Instead, Certbot will print and log an error message with a path to

the up-to-date file that you will need to refer to when manually updating

this file.

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

ssl_ciphers “ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384”;

configuration file /etc/nginx/letsencrypt.conf:

location ^~ /.well-known/acme-challenge/ {
allow all;
root /var/lib/letsencrypt/;
default_type “text/plain”;
try_files $uri =404;
}

`

My web server is (include version): nginx 1.17.9

The operating system my web server runs on is (include version): arch linux 5.6.0-rc5-1-ARCH

My hosting provider, if applicable, is: me

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): nope

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 1.3.0

I’m not able to get to .well-known/acme-challenge/test (I created the directory structure and set permissions). I have tried this without the location rule for .well-known and just create the structure in my site directory with correct permissions and that let’s me get to the test file, but still fails the challenge request.

The repeated message in /var/logs/nginx/access.log "GET /.well-known/acme-challenge/x3Lne74JfG1Ts0nZLZxp1yfe4XFiYZV2-zj_IVvqjVc HTTP/1.1" 404 146 "-" "Go-http-client/1.1"

Nothing shows up in the error.log

I’ve been fighting this one most of the day and have tried multiple ways of solving it with nginx.conf entries and I’m just at a loss. Any help would be greatly appreciated.

1 Like

unless you are using the webroot plugin, appropriately configured, remove this.

what certbot command are you using?

1 Like

https://www.archlinux.org/packages/?name=certbot

That include is just that last section from the nginx -T command which is from multiple posts I had read with similar problems. I have since pulled it out and just placed a .well-known/acme-challenge structure in the static hosted locations. That allowed me to get to a test file, but didn’t fix the reoccurring 404 in the access.log

** Edited **
I thought it was worth noting, that if I change the return 404 in the section that listens to port 80, to a 500 (me diagnosing) that the response sends a 500 instead in the acces.log.

1 Like

That request isn’t coming from Certbot and it’s probably not coming from Let’s Encrypt.

Certbot is written in Python, so it wouldn’t have a Go User-Agent header, and it doesn’t make requests like that.

Let’s Encrypt does use Go, but the validation system uses a distinct User-Agent, and as far as I know they don’t have any other systems making strange HTTP requests.

You might not want to post it here, for privacy reasons, but can you check out the IP address or addresses that are making these requests?

You might have a Go-based ACME client that’s automatically trying to create/renew some certificate and making pre-check requests – perhaps running on a different, perhaps old server – or it might be bizarre Internet garbage.

1 Like

Hi @blackhatbrg

I could download the file.

http://unknownsaints.com/.well-known/acme-challenge/test

there is a redirect http -> https, then the "wrong" Content-Type

Content-Type: application/octet-stream

The file has the content

success

So if you use --webroot, that should work. And the "wrong" Content-Type isn't a problem if Letsencrypt checks your file. That's only a "partial" problem checking the file with a browser.

1 Like

Yeah, I removed the conf include and switched to just straight static serving with the dir structure setup in the share. That seems to have solved getting to the test file.

Also, very possible there’s some legacy setup hitting that service (god only knows what it is). Does everythign appear to be working? I guess I had assumed something was failing with ssl which is why it wasn’t serving, it could just be something with my codebase or dir-structure that’s breaking now

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.