DevOps & Deployment
Let’s Encrypt 404 challenge: why it happens
DevOps & Deployment
February 09, 2026
255 views

Most often an Nginx routing/proxy issue.
You run Certbot / Let’s Encrypt and you see “unauthorized” or “404 challenge”.
Meaning: Let’s Encrypt could not access the temporary challenge file from the internet.
Think of it like this:
Let’s Encrypt tries to open:
http://yourdomain/.well-known/acme-challenge/xxxx
If it can’t read it, the certificate fails.
Most common reasons (and fixes):
1) Nginx location is wrong
Your config for:
/.well-known/acme-challenge/
points to a folder that is not actually serving files.
Fix:
Set a clear location and correct root, for example:
location ^~ /.well-known/acme-challenge/ {
root /var/www/letsencrypt;
try_files $uri =404;
}
2) Redirect rules catch everything
You redirect HTTP → HTTPS for all requests, including the challenge path.
Then the file is not found or blocked.
Fix:
Make challenge path an exception before redirect.
3) Cloudflare proxy is interfering
Sometimes proxy + caching rules cause the challenge request to not reach your origin correctly.
Fix options:
- Temporarily set DNS record to “DNS only” (grey cloud) for issuance
- Or disable aggressive cache rules for the challenge path
4) Wrong webroot in Certbot
You run:
certbot certonly --webroot -w /path
But /path is not the same folder Nginx serves.
Fix:
Make sure the -w path matches Nginx root for that location.
Quick test (must work):
Create a test file:
/var/www/letsencrypt/.well-known/acme-challenge/test
Then open in browser:
http://yourdomain/.well-known/acme-challenge/test
If that works, Certbot will work.
KeyTD tip:
When we set up SSL on servers, we always keep a dedicated ACME location so renewals don’t break later.
Ismayil shares practical notes on software quality, delivery speed, and building reliable products.
Related posts

Feb 09, 2026
Case Studies

Feb 09, 2026
DevOps & Deployment
Backup plan: what if your server dies tomorrow?

Feb 09, 2026





