Introduction

An ACME challenge returning 404 usually means the certificate authority is asking for the right path, but your server stack is not serving the expected token from that exact location. This often happens during Let's Encrypt issuance and renewals after redirects, rewrites, CDN changes, or document-root changes. The goal is to trace who handles /.well-known/acme-challenge/ before assuming the certificate service itself is broken.

Symptoms

  • Let's Encrypt or another ACME client fails HTTP validation with a 404 response
  • Manual certificate issuance or renewal stalls on one hostname but not others
  • Browsing to the challenge path shows a not found page or application route
  • The issue started after a redirect rule, hosting migration, or proxy rollout
  • DNS looks correct, but validation still fails publicly

Common Causes

  • The ACME client writes challenge files to a different document root than the live site uses
  • Redirect or rewrite rules capture the challenge path before the validation file is served
  • A CDN, proxy, or load balancer forwards the request to the wrong backend
  • The hostname resolves correctly, but traffic reaches an old server or mismatched virtual host
  • Cleanup tasks or deployment scripts remove challenge files before validation completes

Step-by-Step Fix

  1. Confirm which hostname and exact /.well-known/acme-challenge/ URL the certificate authority is requesting.
  2. Test the challenge path from the public internet to see whether the 404 comes from the origin, a proxy, or the application layer.
  3. Verify the ACME client writes the token into the same document root and virtual host that serves the live hostname.
  4. Review redirect, rewrite, and framework routing rules to ensure the challenge path bypasses normal application handling.
  5. Check CDN, reverse-proxy, and load-balancer behavior so the validation request reaches the intended backend without path changes.
  6. Confirm DNS and virtual-host mapping still point the hostname at the right server during the validation window.
  7. Temporarily simplify challenge handling if needed so the token is served directly from the web server.
  8. Retry issuance only after the exact token URL returns the expected content publicly on every requested hostname.
  9. Keep renewal path exceptions documented so future deploys do not reintroduce 404s on ACME validation routes.