DevOps & Deployment

Let’s Encrypt 404 challenge: why it happens

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

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 Ismayilov

Content Author at KeyTD

Ismayil shares practical notes on software quality, delivery speed, and building reliable products.