I set up my macOS 10.11 server running nginx 1.8.0 four years ago. I installed using homebrew. Certbot has worked great all that time, but the recent ACMEv1 deprecation has motivated me to upgrade Certbot from 0.4-ish to the latest version, 1.5.0. I am unfortunately having problems trying to get my server to respond to Let’s Encrypt. I have access to a shell, I manage the computer myself.
What happens is pretty simple: Let’s Encrypt reaches out to the /.well-known/acme-challenge/ URL, gets served a friendly HTML 404 page by my server, an “invalid response”, and fails. Here’s how it goes:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for lovelysunny.company
Using default address 80 for authentication.
Waiting for verification...
Challenge failed for domain lovelysunny.company
http-01 challenge for lovelysunny.company
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: lovelysunny.company
Type: unauthorized
Detail: Invalid response from
https://lovelysunny.company/.well-known/acme-challenge/[a key i snipped out in case it's sensitive]
[208.52.170.87]: "<html>\r\n<head><title>404 Not
Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404
Not Found</h1></center>\r\n<hr><center>"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
Here’s what one of my nginx server .conf files looks like:
## Dumb HTTP server just redirects people to the HTTPS server. That's all it does.
server {
listen 17539;
server_name lovelysunny.company www.lovelysunny.company;
port_in_redirect off;
return 301 https://$host$request_uri;
}
# Actual HTTPS server
server {
listen 17540 ssl;
server_name lovelysunny.company;
access_log /usr/local/var/log/nginx/access.log;
error_log /usr/local/var/log/nginx/error.log error;
port_in_redirect off;
root /Users/lovelysunny/Sites/lovelysunny.company;
## SSL Settings
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
ssl on;
ssl_certificate /etc/letsencrypt/live/www.lovelysunny.company/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.lovelysunny.company/privkey.pem;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
ssl_dhparam /usr/local/etc/nginx/ssl/lovelysunny.dhparam;
# Allow Let's Encrypt to verify I own this domain
include letsencrypt.conf;
location ~ \.(php|html)$ {
try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.html;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
include /usr/local/etc/nginx/fastcgi.conf;
}
}
Every one of my servers has one of those include letsencrypt.conf; lines. letsencrypt.conf looks like this:
location ^~ /.well-known/acme-challenge {
alias /var/lib/letsencrypt/.well-known/acme-challenge;
default_type "text/plain";
try_files $uri =404;
}
Is this configuration old and crappy and needs updating? I don’t actually know where I got all the SSL settings lines, and the letsencrypt.conf — did certbot put it there on first install? Did I find it in some tutorial? I don’t know, but it seemed to work well.
I searched around and couldn’t actually find definitive instructions on what my nginx config is supposed to look like. I did see some example config saying I should use root, not alias. Should I?
Ideally, I want the most future-proof config here that both works and will work with the latest validation method for years to come.
An aside on ports
Nginx serves HTTP on port 17539 and HTTPS on port 17540. pf redirects all incoming 80 and 443 traffic to these weird ports. I can’t remember why I did this, but it’s how the system works and I’m not going to mess with it.
After doing some reading on how certbot works, I thought that this might be some kind of issue. (Even if it wouldn’t make a lot of sense that it wasn’t an issue before I upgraded.) I figured I needed to tell certbot to spin up its nginx server (??) to listen to port 17540. So I tried sudo certbot --http-01-port 17540. After selecting “nginx” and the number for the lovelysunny.company domain, these were the results:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for lovelysunny.company
Using default address 17540 for authentication.
nginx: [warn] conflicting server name "lovelysunny.company" on 0.0.0.0:17540, ignored
Waiting for verification...
Challenge failed for domain lovelysunny.company
http-01 challenge for lovelysunny.company
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: lovelysunny.company
Type: connection
Detail: Fetching
https://lovelysunny.company/.well-known/acme-challenge/[removed key that might have sensitive info again]:
Error getting validation data
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
And that’s where I’m at. Any help in getting this to work — and in helping me get my configuration up to the latest standards — would be greatly appreciated. Sorry my server’s weird.
. The way you've done it is fine, I think stuff like this largely comes down to sysadmin tastes.