The email subject line is “Potential reduced AutoSSL coverage”, and inside it there is a sentence that reads like a contradiction. Wording varies between cPanel versions, but the two lines customers forward to us most often look close to this:
The system queried for a temporary file at “http://example.com/.well-known/acme-challenge/…”, but the web server responded with the following error: 404 (Not Found). The domain “example.com” resolved to an IP address “203.0.113.5” that does not exist on this server.
Or this one, which reads like two unrelated complaints stapled together:
DNS DCV: No local authority. HTTP DCV: The domain “example.com” does not resolve to any IPv4 addresses on the internet.
Both are cPanel telling you the same thing badly: it tried to prove to a certificate authority that you control the domain, and it could not. That proof step is domain control validation, or DCV, and in our experience it is far and away the most common answer on shared cPanel hosting. The certificate is not corrupt, Let’s Encrypt is not down, cPanel is not broken. Something is stopping the validation request reaching your account, and most of the causes you can fix yourself once you can read the notice.
The most useful field in that first message is the IP address. Compare it against your account’s IP, shown in cPanel’s information panel. If they differ, skip to cause 1.
The certificate you have may not be the certificate you think you have
Only one certificate is installed per domain at a time. AutoSSL leaves a valid purchased certificate alone if it still covers all the account’s names, and replaces one that is expired, self-signed, or missing names.
That last case is the trap. A self-signed certificate is installed when a cPanel account is created, so that HTTPS answers at all. If AutoSSL never succeeds, nothing replaces it: that original certificate stays, listing the right hostnames with a sane-looking expiry, while the site throws a browser warning. People lose time here because everything looks present.
The tell is that the issuer and the subject are identical. From a Mac or Linux terminal (on Windows use WSL, Git Bash, or an online SSL checker):
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuerIf issuer and subject match, you are looking at the self-signed certificate and AutoSSL has been failing, possibly for a long time. Let’s Encrypt is the provider cPanel ships and licenses by default; the older Sectigo provider was removed from cPanel and WHM in late 2024 and existing users were migrated across, so an issuer that still reads Sectigo today means a stale certificate AutoSSL has not managed to replace.
Do not judge any of this from the padlock icon. A keep-alive connection or a resumed TLS session can keep showing the previous certificate for a few minutes, and behind a CDN the padlock is the CDN’s certificate, not your server’s: it looks perfect while issuance at your account has been failing the whole time. The command above talks to your server directly. Your browser may not.
How validation actually works
To issue a certificate for example.com, the certificate authority asks the server to place a one-time file at a specific URL:
http://example.com/.well-known/acme-challenge/<random-token>Plain HTTP, port 80. Let’s Encrypt will follow up to ten redirects, including to HTTPS, and does not check the certificate on whatever it lands on, so an ordinary force-HTTPS redirect is harmless. What breaks validation is a rule that sends the request somewhere that cannot serve the token: a redirect to a different host or a different path, a maintenance page, a login wall, or a 403.
cPanel also runs a local pre-check first, using a file at your document root named like a name ending in .cpaneldcv. A rule that catches only that pattern fails the pre-check while the acme-challenge path looks fine, so test both.
Every HTTP validation failure is a variant of one sentence: that request did not reach the thing that was supposed to answer it. Either DNS sent it elsewhere, or something intercepted it on the way.
The checks that identify the cause
# 1. Where does the domain actually point?
dig +short example.com
# 2. Can the challenge paths be reached from outside?
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/.well-known/acme-challenge/test
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/test.cpaneldcv
# 3. Who answered? (prints the response headers of a real GET)
curl -s -D - -o /dev/null http://example.com/.well-known/acme-challenge/test
# 4. Is the live certificate real or self-signed, and when does it expire?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
# 5. Which names are actually on the certificate?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltNameIf check 5 returns “unrecognized option”, your openssl predates the -ext flag (which includes the build shipped with macOS). Use this instead:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"Read check 2 carefully, because everybody misreads it. A bare 404 with no redirect target is a pass. The token genuinely does not exist, so 404 is the correct answer; what it proves is that the request arrived and got a normal response. What you do not want is a 403, or a 301/302 pointing at an error page, a login page, or a block page.
A 404 is only a pass if it came from your server, which is what check 3 is for: read the Server: header, note whether a CF-Ray: header is present, and cross-check the IP from check 1. A CDN’s 404 is indistinguishable from yours in check 2 alone.
Which brings us back to the notice at the top. cPanel says the domain “responded with 404” and then says the domain resolved to an IP address that does not exist on this server. The 404 is not the complaint. The second sentence is. Some other machine answered, and it returned a 404 because it has never heard of your token.
Cause 1: the domain no longer points at your hosting account
This is the one we see most. The site moved to another host, went behind a proxy, or someone changed the A record during a migration and never changed it back. The account is still there, still holding the domain, still trying to renew a certificate for a name that resolves somewhere else.
Check 1 tells you immediately. If it returns an address that is not your account’s IP, nothing else here matters until that is fixed: either point the A record back at your account, or, if the site genuinely lives elsewhere now, stop AutoSSL chasing it (see cause 4).
If it returns nothing at all, run dig again without +short, because you need the status line. SERVFAIL usually means the domain’s nameservers are missing or not answering, which is a registrar-side fix; NXDOMAIN usually means the name does not exist, so check the domain has not expired. Either way, cPanel cannot validate a name that does not resolve, which is what the second notice above is saying.
Cause 2: a proxy is answering instead of your server
If check 1 returns an address you do not recognise, run whois on it. If it names Cloudflare or another CDN, validation traffic is not reaching your account directly. The site still looks fine to visitors, because the padlock they see is the edge certificate, so nobody notices that issuance at the origin has been failing.
The orange cloud itself is the problem, in two ways. The domain now resolves to Cloudflare rather than your account, so cPanel’s local pre-check fails. And Cloudflare’s edge settings can intercept the challenge before it reaches your server: “Always Use HTTPS”, Automatic HTTPS Rewrites, redirect rules, WAF rules, and “Under Attack” mode will all do it. Check 2 shows a redirect or a block page instead of a bare 404.
The encryption mode (Flexible, Full, Full Strict) is not the cause, and changing it will not fix DCV. Do not drop to Flexible hoping it helps: that sends all Cloudflare-to-origin traffic unencrypted and does nothing for validation.
The durable answer is Full (Strict) with a Cloudflare origin certificate on your account. That replaces AutoSSL rather than fixing it, so once it is in place, exclude the domain from AutoSSL (see cause 4) or the notices keep arriving forever. Origin CA certificates are trusted only by Cloudflare, so this works only while the domain stays proxied.
Grey-clouding the record temporarily also works, but you redo it at every renewal, and it publishes your server’s real IP address, which passive DNS services keep permanently even after the proxy goes back on.
Cause 3: your own .htaccess is intercepting the challenge
If the domain points at us correctly but check 2 returns a redirect or a 403, look at your .htaccess before assuming it is a server problem. The usual culprits: a maintenance-mode or coming-soon plugin rewriting every request to one page, security plugin rules that return 403 on unfamiliar paths, hotlink protection, IP-based access rules.
Forcing HTTPS is not one of them. A redirect-to-SSL setting or an “always use HTTPS” toggle is fine, because Let’s Encrypt follows the redirect and does not check the certificate at the other end. Customers turn this off as a guess and it never helps. The problem is a rule that rewrites or blocks the validation paths, not the redirect.
The fix is an exclusion placed above your catch-all rules, so challenge requests are served normally and everything else still redirects:
RewriteEngine On
RewriteRule ^\.well-known/acme-challenge/ - [L]
RewriteRule \.cpaneldcv$ - [L]Edit .htaccess under Files > File Manager, with “Show Hidden Files” enabled in its settings.
Cause 4: names quietly missing from the certificate
This one produces the most confused tickets. The main site has a padlock and looks fine, but a subdomain or addon domain throws a warning and the coverage notice keeps arriving.
When a name fails validation, AutoSSL does not give up on the whole certificate. It requests a replacement that leaves that name out, so the account carries on looking healthy while the certificate silently shrinks. If every name fails, you get the summary line NO_UNSECURED_DOMAIN_PASSED_DCV, meaning “none of them passed, so I wrote nothing”. That is a summary, not a cause; there is always a per-name reason behind it.
Check 5 prints the Subject Alternative Name list, the definitive record of what the certificate covers. Searching a .crt file for your hostname finds nothing even when it is there, because the file is base64 and the names sit inside the encoded blob.
Compare that list against what the account owns: domains, subdomains, addon and parked domains. For anything missing, ask whether it still resolves, and whether it resolves here. Usually it is a leftover, such as an old staging subdomain or a parked domain nobody kept the DNS current for.
Remove it from the account if you genuinely do not use it, under Domains or Subdomains. Otherwise exclude it from AutoSSL: go to Security > SSL/TLS Status, tick the checkbox next to the domain, and click the exclude button (the label toggles between excluding and including based on the domain’s current state). Excluded domains are skipped on future runs, which stops the notices. While you are on that page, Run AutoSSL triggers an immediate run instead of waiting for the daily one.
Cause 5: it was switched off
AutoSSL can simply be off, for the account or for one domain. The SSL/TLS Status page shows this per domain; filter it to unsecured domains and you will see which ones are being skipped.
One thing to rule out rather than chase: AutoSSL renews inside a window before expiry, and that window depends on the provider, so treat any specific number of days you read online with suspicion. Days remaining are irrelevant if you are getting coverage notices anyway, because those report a validation failure happening now, not an expiry. Do not wait.
Two things people misdiagnose as DCV
The first is wildcards. A name such as *.example.com cannot be validated over HTTP at all. It needs DNS validation, and AutoSSL can only publish the required TXT record if the cPanel server is itself authoritative for the zone. Where the authoritative copy of the zone is not held on the hosting server, it has no local authority to write that record, so No local authority: "*.example.com" is expected rather than a fault. Individual subdomains are issued normally and cover most real needs. If you specifically need a wildcard, ask us first: installing a third-party certificate is not available on every plan.
The second is a missing intermediate chain, which is not AutoSSL at all. It happens with certificates you bought and uploaded, and the symptom is distinctive: fine in desktop Chrome, untrusted on phones or older devices. The certificate was installed without its CA bundle. Reinstall it under Security > SSL/TLS > Manage SSL sites, including the bundle the issuer supplied.
What to send us when you open a ticket
Some of these are not yours and not fixable from inside cPanel. Send them over rather than continuing to debug.
| Symptom | What to include |
|---|---|
| Challenge path returns a redirect or block page and it is not your .htaccess or your CDN | The domain, plus the full output of checks 2 and 3 |
| A 403 on the challenge path you cannot explain | The domain, the output of check 2, and any security plugins you have installed |
| Self-signed certificate persists after AutoSSL runs | The domain and the output of check 4 |
| “No local authority” on your base domain, not a wildcard | The domain and the exact notice text |
Worth knowing: if check 2 comes back as a redirect rather than a bare 404 and you have ruled out your own .htaccess and your CDN, the interception is above your account at the web server level. Nothing you change inside cPanel will help. Send us the output.
Last thing, and it matters more than it sounds: do not sit on the Run AutoSSL button. Let’s Encrypt’s published rate limits cap failed validations per hostname per hour, and the allowance refills gradually rather than all at once. Burn through it and that hostname is blocked from new orders until the window refills, which turns a twenty-minute fix into an afternoon of waiting. Run it once, read the result, fix the actual cause, then run it again.
Be First to Comment