I ran this command:
acme.sh --issue -d saffiregrills.com -w /home/letsencrypt_challenge -k 4096 --force
It produced this output:
saffiregrills.com:Verify error:Invalid response from http://saffiregrills.com/.well-known/acme-challenge/db5cUqtv-cWSFzDTusGLudeoQwTTH8AymRbA0lASCtE [209.126.82.159]:
My web server is (include version):
NGINX
The operating system my web server runs on is (include version):
Debian 11
My hosting provider, if applicable, is:
Contabo
The version of my client is:
ACME.sh v3.0.2
Please note that I've tried running the same ACME.sh command with the --test argument, and everything appears to be working there. However when I remove --test I get the before-mentioned message.
I was able to successfully issue and install a certificate for a test website on the same server using (virtually) the same configuration files.
Here is what my website configuration file looks like right now. Note that several sections have been commented out in the meantime until I can get this fixed.
###
# HTTP Redirect Server Block
###
#server {
# listen 80;
# listen [::]:80;
#
# server_name saffiregrills.com www.saffiregrills.com;
#
# return 301 https://saffiregrills.com$request_uri;
#}
###
# Main/HTTPS Server Block
###
server {
listen 80 default_server;
listen [::]:80 default_server;
# listen 443 ssl http2 default_server;
# listen [::]:443 ssl http2 default_server;
root /home/main_dbe46/saffiregrills.com;
# Add index.php to the list if you are using PHP
index index.html index.php;
server_name saffiregrills.com;
##
# SSL configuration
##
# SSL/TLS Certificates
ssl_certificate /etc/nginx/ssl/saffiregrills.com/saffiregrills.com.cer;
ssl_certificate_key /etc/nginx/ssl/saffiregrills.com/saffiregrills.com.key;
# Huffie-Hellman Group File
ssl_dhparam /etc/nginx/ssl/saffiregrills.com/dhparams.pem;
# Let's Encrypt Root for SSL/TLS Certificate Challenge Responses
include includes/letsencrypt_challenge;
##
# Sitewide Location Rules
##
location / {
# Control Order Nginx Will Use to Match File System to URL Request
try_files $uri $uri/ /index.php;
# Limit Request Types to GET and POST
limit_except GET POST {
deny all;
}
}
##
# Location Rules for All PHP Files
##
location ~* \.php$ {
# PHP FPM Processing
# Block PHP FPM From Executing Code in Uploads Directory
if ($uri !~ "^/uploads/") {
# Execute PHP FPM
fastcgi_pass unix:/run/php/php8.0-fpm_saffiregrills.com.sock;
}
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
##
# Location Rules for All . Files
##
# Hide Dot Type Files For Security Reasons
location ~* /\. {
return 404;
}
##
# Hide SQL, Backup, and Temporary Files
##
location ~* \.(?:sql|bak|php~|php#|save|swp|swo|tmp)$ {
return 404;
}
##
# Location Rules for All Image Files
##
# Client Side Caching of Static Content
# Cache Image Files
location ~* \.(?:ico|gif|jpe?g|png|webp|svg)$ {
expires 1d;
access_log off;
log_not_found off;
add_header Cache-Control private;
open_file_cache max=3000 inactive=120s;
open_file_cache_valid 120s;
open_file_cache_min_uses 4;
open_file_cache_errors on;
}
##
# Location Rules for All Font Files
##
# Cache Font Files
location ~* \.(?:otf|ttf|eot|woff|woff2)$ {
expires 30d;
access_log off;
log_not_found off;
add_header Cache-Control private;
open_file_cache max=3000 inactive=120s;
open_file_cache_valid 120s;
open_file_cache_min_uses 4;
open_file_cache_errors on;
}
##
# Location Rules for All CSS, JS, HTML, and XML Files
##
# Cache CSS, JavaScript, HTML, and XML Files
location ~* \.(css|js|html|xml)$ {
expires 48h;
access_log on;
add_header Cache-Control public;
}
##
# Hide PHP Files in Locations Where Hackers May Attempt to Run Malicious Code Previously Uploaded
##
location ~* /(?:uploads|files|wp-content|wp-includes|akismet)/*.php$ {
return 404;
access_log off;
log_not_found off;
}
##
# Specific Location Rules
##
# Deny Access to Wordpress' XMLRPC for Security, and to Save Memory Consumption
location /xmlrpc.php {
deny all;
}
##
# Gzip Settings
##
gzip on;
gzip_comp_level 6;
gzip_min_length 5120;
gzip_types
text/plain
text/css
application/javascript
application/json
application/x-font-ttf
font/opentype
image/svg+xml
image/x-icon;
gunzip on;
##
# Rate Limiting
##
# Limite Server Requests to 900,000 above the 100,000 Limit in nginx.conf, With Delays Over 100,000
limit_req zone=server burst=900000;
# Limit Requests to 400 per IP Over the 100 Limit in nginx.conf, With Delays Over 100
limit_req zone=per-ip burst=400;
##
# Header Settings
##
##
# Header Configuration
##
# Enforce Strict Transport Security
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Disallow Sniffing Byte Order to Help Prevent XSS
add_header X-Content-Type-Options nosniff;
# Disallow Embeds and IFrames from Any Other Website; Replaced with Content-Security-Policy frame-ancestors
add_header X-Frame-Options SAMEORIGIN;
# Tell Browsers to Turn on XSS Protection, If Disabled By User; Replaced with Content-Security-Policy reflected-xss
add_header X-XSS-Protection "1; mode=block";
# Only Load Content From This Server
add_header X-Permitted-Cross-Domain-Policies master-only;
# Prevent Browser From Sharing Link Origin with Linked Websites
add_header Referrer-Policy SAMEORIGIN;
# Miscellaneous XSS Protection Measures; Allows Loading Images from Anywhere; Automatically Loads Resources with HTTPS over HTTP, Etc.
# See 1) https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
# See 2) https://research.nccgroup.com/wp-content/uploads/2020/07/csp_best_practices.pdf
# add_header Content-Security-Policy "default-src 'self'; object-src 'none'; reflected-xss; upgrade-insecure-requests; img-src 'self' https: data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline'; font-src 'self' https:";
}
I'm sorry, scratch that. It was because my config file referenced the TLS certificate files, when they weren't installed yet. I've commented out those lines and I'm getting a 404 error again after I restart NGINX.
No, you were on the right track. That location would have returned a 404 for the acme challenge requests to /.well-known/acme-challenge. You can make a location just for that to avoid collision. Or make a better regex.
You can just comment out the lines for your certificate files if they do not yet exist. You are only listening to port 80 anyway so they are not needed.
Or, you could create a self-signed cert and use that temporarily. But, best for now to comment out I think.
Ah, great! So that was it. That code is meant to restrict access to files like .htaccess (where present), .ini, and so on. Do you happen to know of a rewrite to the following snippet for NGINX that would do that without also blocking .well-known?
##
# Location Rules for All . Files
##
# Hide Dot Type Files For Security Reasons
# location ~* /\. {
# return 404;
# }
As @MikeMcQ said, I'm still seeing a 404 in my browser. How did you download the TXT, using wget? I would like to know so I can verify it is accessible in the future if I make any configuration changes.
Great, thanks. That's good to know. I am not very familiar with curl or wget, although I know about them. I should probably start using curl more often.
I've changed the regex to the following. It seems to be working so far, as I am still able to access the file using curl, like @Osiris mentioned.
##
# Location Rules for All . Files
##
# Hide Dot Type Files For Security Reasons
location ~* /\.(^well-known) {
return 404;
}
Maybe someone else will come across this and it will help them too. There doesn't seem to be much documentation on NGINX regular expressions, unfortunately. They are clearly different than PHP and JS regular expressions in some ways.
Well, you might not need that one for "." at all. There are no .htaccess files with nginx so if you do not have any others just leave it out.
Otherwise, you could add a location like below and that should take precedence over less qualified ones (I did not study all of yours). You can read about nginx location precedence in their docs. I like to test by putting an odd return code like 418 in a location to see when it triggers. Shown below but remove the "return" line for actual use
I've seen this stuff at other sites too, blocking .ht* files on nginx. Even if nginx doesn't use .ht* files, it doesn't mean webapps install them anyway, being ignorant of the webserver used. Most .ht* files are benign, but you probably don't want to leak your .htpasswd files.
