DevOps & Deployment

Let’s Encrypt 404 challenge: why it happens

DevOps & Deployment
February 09, 2026
464 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.

Let’s Encrypt 404 challenge: why it happens | KeyTD