New certificate errors Django nginx gunicorn 404

Help
1

I can successfully access http://www.ve3nrt.net/.well-known/acme-challenge/test.html from outside my nat, but I get 404 errors when trying to obtain a certificate. I "watch"ed the challenges directory and did not see any new file appear there. Log file doesn’t appear to say anything more useful than does the console output.

Appreciate the help.

Chris

Here is my nginx configuration file

server {
listen 80;
server_name staging.leonis.ve3nrt.net;
error_page 401 403 404 /404.html;

location /static {
    alias /home/django/staging.leonis.ve3nrt.net/static;
}

location /.well-known/acme-challenge/ {
    alias /home/django/challenges/;
    try_files $uri =404;
}

location / {
    proxy_pass http://unix:/tmp/staging.leonis.ve3nrt.net.socket;
    proxy_set_header Host $host;
}

}

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: ve3nrt.net

I ran this command:
sudo certbot --authenticator webroot --installer nginx -d ve3nrt.net,www.ve3nrt.net --webroot-path=/home/django/challenges

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for ve3nrt.net
http-01 challenge for www.ve3nrt.net
Using the webroot path /home/django/challenges for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. ve3nrt.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://ve3nrt.net/.well-known/acme-challenge/RtLeIW9pzU6jDq36fUTnnn6OuW0Ui7PHAOSCsjMw_08 [69.165.222.201]: 404, www.ve3nrt.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.ve3nrt.net/.well-known/acme-challenge/ujkrs4nYsuxbkX73Btn3T_tZjDZOjQ-szRtB-bsLf0o [69.165.222.201]: 404

IMPORTANT NOTES:

My web server is (include version):
nginx/1.10.3

The operating system my web server runs on is (include version):
Raspbian stretch

My hosting provider, if applicable, is:
N/A

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

2

That needs to be "root /home/django/challenges/;".

Certbot is placing the files in /home/django/challenges/.well-known/acme-challenge/.

3

Thank you! I’m new to nginx and didn’t appreciate the difference between alias and root. The certificates were issued after I changed it. I did get another error though shown below. It looks like I can install the certificates manually, but I have learned that it is worthwhile trying to understand the cause of any error message or other anomaly.

From a bit of googling it seems that maybe server_name should be set to the domain name, but I’m afraid that I would break other stuff by doing that.

Chris

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for ve3nrt.net
http-01 challenge for www.ve3nrt.net
Using the webroot path /home/django/challenges for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem
Cannot find a VirtualHost matching domain ve3nrt.net.

IMPORTANT NOTES:

  • Unable to install the certificate
4

Certbot can't figure out what virtual host to clone to create an SSL virtual host without the server_name directive.

The only thing that would break by setting it was that if you failed to add a domain to the server_name that it turns out was actually being used.

If you're concerned about that you can explicitly define the default virtual host by adding default_server to the listen directive, e.g.

listen 80 default_server;

In fact, it might already be there. Many default configurations already add this so the default virtual host doesn't change randomly due to files being added to include directories, etc.

Otherwise, without a server_name set you will have to configure your own SSL virtual host using the certificates certbot has already obtained.

1 Like
5

Thank you for the helpful replies. All is well. The configuration has become considerably more complex since I wrote the above but nginx, letsencrypt and Django are all working together now in perfect harmony. Compared to my previous experience with Apache httpd, nginx is a dream to work with.

–Chris

6

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