SSL Validation Failing? Fix Blocked .well-known/acme-challenge

Your certificate renewal just failed, and the error log says something like “Invalid response from http://yourdomain.com/.well-known/acme-challenge/... : 404” or WHM's AutoSSL log shows a DCV (Domain Control Validation) failure. The domain loads fine in a browser. DNS is correct. So why can't the certificate authority see the one file it's asking for? This is one of the most common — and most misdiagnosed — reasons SSL issuance breaks on both shared cPanel hosting and self-managed VPS boxes.

Symptom: Certificate Issuance or Renewal Fails, But the Site Loads Fine

A few ways this shows up depending on your stack:

• cPanel/AutoSSL: WHM > SSL/TLS Status shows a red X, and the AutoSSL log (WHM > SSL/TLS > Manage AutoSSL > View Log) says something like Failed to download http://yourdomain.com/.well-known/acme-challenge/<token> : 404.
• Certbot on a VPS: certbot renew exits with urn:ietf:params:acme:error:unauthorized and “Invalid response from ... : 403” or a redirect where a 200 was expected.
• Manual DCV check: you visit http://yourdomain.com/.well-known/acme-challenge/test yourself and get a 404, a login prompt, or a redirect to HTTPS instead of a plain-text response.

The certificate authority (Let's Encrypt, Sectigo, whichever your host uses) has to fetch a specific file over plain HTTP before it will issue anything. If that one request fails for any reason, the whole validation fails — even though every other part of your site works perfectly.

Cause: Something Between the Internet and Your Web Root Is Intercepting the Request

In order of how often we actually see them:

1. A force-HTTPS redirect fires before the challenge file is served

If your .htaccess or Nginx config unconditionally redirects all HTTP traffic to HTTPS, the CA's validation request gets redirected too — and CAs generally won't follow a redirect to HTTPS during HTTP-01 validation on a site that doesn't have a valid cert yet (that's the chicken-and-egg problem the challenge exists to solve). Classic case: someone installs a "force SSL" plugin or adds a blanket RewriteRule right after getting one subdomain's cert, which then breaks renewal for every other domain on the account.

2. ModSecurity or a WAF rule is blocking access to dotfiles/hidden paths

Some security rulesets treat any path starting with a dot (like .well-known) as suspicious and return a 403. This is common after installing security plugins (Wordfence, iThemes Security, custom ModSecurity rules) that indiscriminately block "hidden" directories.

3. Nginx has no location block for .well-known, and the catch-all swallows it

A single-page app or WordPress try_files rule that funnels every request to index.php or index.html will intercept the acme-challenge request too, since it never falls through to a real file on disk. Without an explicit location ^~ /.well-known/acme-challenge/ block, Nginx does exactly what you told it to do — serve the app, not the file.

4. A CDN or reverse proxy is caching or rewriting the response

If Cloudflare (or similar) is proxying traffic in "Full" or "Full (Strict)" mode with page rules that force HTTPS, or if a caching rule serves a cached 404 for that path, the origin server never actually sees the validation request — or the CA gets a cached miss instead of the live token.

5. The webroot for the DNS-facing domain doesn't match where the app actually lives

Addon domains and parked domains in cPanel sometimes point to a different document root than you expect. If the challenge file gets written to /home/user/public_html/subdomain/.well-known/... but the domain actually resolves to /home/user/public_html/, validation fails even though nothing looks "broken."

Fix: Confirm the Request Path End-to-End, Then Remove the Blocker

Step 1 — Reproduce the exact request the CA makes

From an external machine (not localhost — you need to test what the internet sees):

curl -v http://yourdomain.com/.well-known/acme-challenge/test-file

You want a plain HTTP 200 or 404 from your own server — not a redirect (301/302) to HTTPS, not a 403, and not someone else's login page. Watch the Location: header in the response; a redirect here is almost always the root cause.

Step 2 — If you see a redirect to HTTPS, carve out an exception

For Apache/.htaccess, add this above any existing force-HTTPS rules:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

For Nginx, add a dedicated location block before your catch-all/proxy rules:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/yourdomain.com;
    default_type "text/plain";
    try_files $uri =404;
}

location / {
    return 301 https://$host$request_uri;
}

Order matters in Nginx — location blocks are matched by specificity, so the ^~ prefix match for the challenge path will win over a generic / block regardless of the order you write them in, but keep it above for readability and to avoid mistakes during future edits.

Step 3 — If you get a 403, check for WAF/ModSecurity rules

In WHM, go to Security > ModSecurity Configuration and check for hits against the domain around the failure timestamp. On a VPS running ModSecurity directly:

grep -i "acme-challenge" /var/log/apache2/modsec_audit.log

If a rule ID shows up, whitelist that specific path rather than disabling ModSecurity entirely:

<LocationMatch "^/\.well-known/acme-challenge/">
    SecRuleRemoveById 920440 920450
</LocationMatch>

(Swap in whatever rule IDs your log actually shows — don't copy these blind.)

Step 4 — If a CDN sits in front, bypass it for the challenge path

In Cloudflare, add a Page Rule or Cache Rule for yourdomain.com/.well-known/acme-challenge/* set to "Cache Level: Bypass" and, if you're on Flexible/Full SSL mode, a Configuration Rule to disable "Always Use HTTPS" for that path specifically. Alternatively, switch to DNS-01 validation (via certbot with a DNS plugin, or your CA's DNS-based flow) so the CDN is never in the request path at all — this is the more robust long-term fix if you're fronting everything with Cloudflare anyway.

Step 5 — Re-run validation

In WHM: SSL/TLS > Manage AutoSSL > Run AutoSSL for the account, or from the CLI:

# cPanel
/usr/local/cpanel/scripts/autossl_check --user=cpaneluser --force

# Certbot
certbot renew --cert-name yourdomain.com --dry-run

Always use --dry-run first with Certbot — Let's Encrypt's real rate limits are unforgiving (5 failures per account/hostname per hour), and you don't want to burn attempts while you're still debugging the redirect rule.

Prevention

• Whenever you add a force-HTTPS rule, security plugin, or WAF ruleset, immediately test curl -v http://yourdomain/.well-known/acme-challenge/anything afterward — don't wait for the next renewal cycle to find out you broke it.
• If you manage Nginx configs by hand, keep the .well-known location block in a shared snippet you include across every server block, so it can't be forgotten on a new site.
• For sites permanently behind a CDN, switch to DNS-01 validation once and stop worrying about HTTP-path interception entirely.
• Set a calendar reminder a few days before any manually-managed (non-AutoSSL) certificate expires — don't rely solely on renewal automation for domains with custom redirect or WAF rules.