AutoSSL failures land in the inbox as a wall of “The system failed to validate” messages, and with the move to short-lived 200-day certificates in cPanel 136 the renewal window is tighter than it used to be. Nearly every failure falls into a handful of categories, and the AutoSSL log names the category if you know how to read it. This guide takes them in the order you should check.
Table of Contents
Short answer: Run /usr/local/cpanel/bin/autossl_check --user=USERNAME and read the reason it prints for each domain. Almost every failure is one of five causes: the domain does not resolve to the server, a CDN proxy or redirect intercepts the challenge, a CAA record names a different CA, a rewrite or security rule blocks /.well-known/, or the CA has rate-limited the account. Fix the named cause, re-run the check, and confirm the new certificate with openssl s_client.
Read the log before changing anything
Start with the per-account log rather than the notification email:
/usr/local/cpanel/bin/autossl_check --user=USERNAME
tail -50 /var/cpanel/logs/autossl/*/txtThe check runs validation in the foreground and prints each domain with a reason. The reasons you will see most are “DNS DCV: no local authority”, “HTTP DCV: the content did not match”, “403” or “301” responses on the challenge URL, “CAA record prevents issuance”, and “this domain does not resolve to any IPs on this server”. Each maps to a section below.
On 136 and later the same information is under WHM » SSL/TLS » Manage AutoSSL » Logs. Check which provider is active (Sectigo is the default since 136; Let’s Encrypt is optional) because the two differ slightly around CAA and wildcard handling.
Domain does not resolve here
The most common cause is not a bug at all: the domain’s A record points elsewhere, or a subdomain (mail., cpanel., autodiscover.) was created automatically and never had DNS. AutoSSL tries every subdomain on the vhost and reports failures for each. If the customer does not need certificates for those names, exclude them so the notifications stop:
uapi --user=USERNAME SSL set_autossl_excluded_domains domains=mail.example.com,webdisk.example.comIf the domain should resolve here, fix DNS first and re-run the check. Do not spend time on the other categories until dig +short example.com returns this server’s IP from an external resolver.
Cloudflare and other CDN proxies
When a domain is proxied (orange cloud), HTTP DCV requests from the CA hit Cloudflare, not your server. Cloudflare passes /.well-known/acme-challenge/ through in most configurations, but any of these break it: a “Always Use HTTPS” rule that redirects the challenge before the origin sees it, a page rule with a cache-everything setting, a WAF rule blocking unusual user agents, or Cloudflare’s own Universal SSL competing at the edge.
Options, in order of preference:
- Use DNS DCV instead of HTTP. cPanel does this automatically when the zone is hosted on the server with local authority; with Cloudflare as the DNS host you need the zone on cPanel with Cloudflare as a delegated or synced provider, or accept HTTP DCV.
- Add a Cloudflare configuration rule that disables Always Use HTTPS and caching for the path
/.well-known/acme-challenge/*. - Temporarily grey-cloud the record, run
autossl_check, then re-enable the proxy. The certificate on the origin only matters for Full (strict) mode, but you still want it valid.
Also confirm the origin sees real client IPs; the Cloudflare and cPanel guide covers mod_remoteip, which stops cPHulk and ModSecurity from blocking the CA’s validation requests because they all appear to come from Cloudflare ranges.
CAA records
A CAA record on the domain (or any parent) restricts which CAs may issue. AutoSSL checks CAA before requesting and reports the conflict. Look it up:
dig +short CAA example.com
dig +short CAA $(echo example.com | awk -F. '{print $(NF-1)"."$NF}')If the customer moved from another provider, a leftover 0 issue "letsencrypt.org" blocks Sectigo, and vice versa. Either add the record for the active provider (0 issue "sectigo.com" for the default, 0 issue "letsencrypt.org" for the alternative) or remove the CAA record entirely. cPanel can add the correct CAA automatically when the zone is local; check Tweak Settings » Security » Allow AutoSSL to add CAA records.
Blocked /.well-known/ paths
HTTP DCV places a file under /.well-known/acme-challenge/ (or /.well-known/pki-validation/ for Sectigo) in the docroot and expects the CA to fetch it. Anything that rewrites or protects that path breaks validation:
- WordPress and Laravel front-controller rewrites without a
RewriteCondexcluding.well-known. - Password-protected directories or IP allowlists on the docroot.
- A ModSecurity rule matching the random token string; check
/etc/apache2/logs/modsec_audit.log. - Redirects from HTTP to HTTPS on a domain whose current certificate is already expired, so the CA gets a TLS error.
- A
.htaccesswithOptions -Indexesplus aFilesMatchdeny on dotfiles that catches the directory.
Test exactly what the CA sees:
curl -sIL http://example.com/.well-known/acme-challenge/test 2>&1 | headYou want a 404 from your own server (the file does not exist yet), not a 301, 403 or a redirect to a different host. cPanel adds an Apache-level alias for the validation paths that should take precedence over .htaccess, but application-level rewrites in Nginx (if using the ea-nginx reverse proxy) or LiteSpeed can bypass it, so check the include files for those servers.
A common pitfall is a customer-managed redirect from the bare domain to www that was created in cPanel » Redirects with “wildcard” ticked; it redirects the challenge path too.
Rate limits and provider-side issues
If the log shows the CA rejecting requests with a rate limit, the account has been retrying failed domains for days. Exclude the broken names, wait for the window, and retry; switching providers under Manage AutoSSL is a legitimate way around a temporary block. Our SSL expiry check script reports certificates approaching expiry so you catch these before the customer does.
Verify
After fixing the cause, re-run /usr/local/cpanel/bin/autossl_check --user=USERNAME and confirm every listed domain returns a success line, then check the installed certificate:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -issuerThe issuer should match the active provider and the not-after date should be roughly 200 days out on 136 and later. Finally, confirm the AutoSSL notification for that account has cleared under WHM » Manage AutoSSL » Logs; a clean run leaves no pending failures.
AutoSSL failed cPanel at a glance
Official documentation: Let’s Encrypt documentation, cPanel & WHM documentation, Linux man pages.
Related guides: Connecting an AI agent to a cPanel account with MCP (v138) and auditing what it can do · Fix Imunify360 missing from the WHM interface (enable-plugin and other causes) · Locking down WHM: 2FA, cPHulk, Host Access Control and scoped API tokens.
Frequently asked questions
Does a Cloudflare-proxied domain break AutoSSL on cPanel?
Not by itself. Cloudflare passes /.well-known/acme-challenge/ through unless an Always Use HTTPS rule, a cache-everything page rule or a WAF rule interferes; add a configuration rule that excludes that path, or use DNS DCV where the zone is hosted on the server.
How long does AutoSSL take to retry after a failed DCV?
The AutoSSL cron runs once a day, so a repaired domain is retried within 24 hours; running autossl_check for the user retries immediately without waiting for the cron.
Can I stop AutoSSL notifications for subdomains that will never validate?
Yes. Exclude them with uapi --user=USERNAME SSL set_autossl_excluded_domains domains=... or from the account’s SSL/TLS Status page; AutoSSL then skips those names and the failure emails stop.