cPanel AutoSSL failed

When cpanel autossl failed, the control panel could not complete DV—your vhost may still serve an expired leaf until AutoSSL succeeds and Apache/nginx reloads.

Server administrators and resellers see AutoSSL errors in SSL/TLS Status, WHM Manage AutoSSL, or email from the server's monitoring.

AutoSSL orchestrates vendor CAs (Let's Encrypt, Sectigo) per domain on the account. Failure is usually reachability, DNS, or exclusion—not a random cPanel bug.

This guide correlates panel errors with logs, CLI checks, and external openssl proof.

First response

In WHM or cPanel, open SSL/TLS Status and expand the failed domain's last AutoSSL message. Copy the exact Boulder/Sectigo error (rate limit, 403 on /.well-known, DNS failure).

Confirm the domain resolves to this server from public resolvers (dig +short A example.com). If Cloudflare orange-cloud proxies the record, ensure SSL mode allows HTTP validation or switch to DNS validation compatible with your provider.

Link Certbot renewal troubleshooting when you also run standalone certbot outside AutoSSL on the same host.

WHM resellers should reproduce as the affected cPanel user when running uapi SSL calls, not only as root. Capture the AutoSSL provider configured globally versus per-package overrides. Rate-limit errors need cooling-off periods documented in Boulder messages.

What this error means

AutoSSL is cPanel's scheduled job that requests, installs, and replaces certificates on vhosts. Failed means no new leaf was installed; Apache may keep serving the previous cert until it too expires—then customers see bigcommerce ssl certificate expired-class browser errors regardless of CMS.

WHM can set AutoSSL providers, exclusions, and notification thresholds. User-level SSL/TLS Status shows per-domain progress.

A success email does not replace openssl proof: verify the live handshake after the nightly cron.

AutoSSL failure is a control-plane signal that no new trusted leaf reached the Apache or nginx vhost. Users may still see partially trusted chains or outdated commercial certs until someone fixes DCV and reruns the job. Nightlies mean a Monday failure might have started Friday.

Common causes

Domain aliases point email or DNS elsewhere while HTTP still should hit this machine—split DNS breaks HTTP-01.

.htaccess or ModSecurity returns 403 for /.well-known/acme-challenge/ paths.

Expired default hostname cert on shared IP causes SNI fallback to wrong vhost during validation.

Rate limits after too many failed orders for the same FQDN set in 168 hours.

Manual Exclude from AutoSSL checkbox left checked on migrated sites.

IPv6-only DNS without working v6 vhost binding.

HTTP validation breaks when LiteSpeed rewrite rules send challenges to WordPress. DNS-only clouds proxy HTTP away from the origin IP AutoSSL expects. Custom port listeners terminate TLS on 8443 while validation probes port 80 on a parked page.

Confirm from the outside

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname users type.

How to read the output

After a fix, issuer should match your configured AutoSSL provider. Serial number must change from the expired certificate.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

CLI and logs

/usr/local/cpanel/bin/autossl_check --all
/usr/local/cpanel/bin/checkallsslcerts

tail -n 80 /var/cpanel/logs/autossl/txt/autossl.log

For a single user:

/uapi --user=CPUSER SSL get_autossl_problems

curl the ACME challenge path from an external host while tailing autossl logs. Compare autossl_check exit codes with panel timestamps.

Fix checklist

1. Remove AutoSSL exclusions unless you intentionally use purchased certs.
2. Fix DNS so HTTP-01 reaches this server on port 80.
3. Allow /.well-known in firewall and security modules.
4. Run autossl_check --all and watch logs.
5. Use Manage SSL Sites to confirm the new PEM is mapped to the vhost.
6. Restart web server if the panel does not reload automatically.
7. Verify each alias and subdomain listed in the certificate SANs.
8. Add external monitoring before the next 90-day ACME window.

Roll out and verify

Treat AutoSSL as a scheduled job, not a one-click charm. Before forcing renewal, snapshot current Apache/nginx vhost SSL directives and note which users own the failing domain—resellers need user consent before rewriting certificates on shared packages.

When validation errors mention HTTP-01, curl the challenge path from four external vantage points (home ISP, LTE, a VPS, and a synthetic monitor). A single geography succeeding while others see 403 usually means GeoIP firewall rules or Cloudflare page rules, not a global cPanel defect.

Post-fix, enable SSL/TLS Status email notifications at the WHM level if you operate a fleet. Pair panel alerts with external checks on high-value customer domains because AutoSSL can report success while a custom nginx include still points at last month's fullchain.

Document which domains use purchased EV or OV products excluded from AutoSSL separately in your inventory. Mixing manual and automated lifecycles on one IP causes recurring tickets unless ownership is explicit in the CMDB.

Schedule quarterly audits for Exclude from AutoSSL checkboxes after migrations. Pair panel notifications with external monitors on customer storefronts.

When to use automation

Certificate files on disk and green panels lie until a stranger's TLS handshake succeeds. Schedule live checks on the exact hostname shoppers or API clients resolve, including redirects and the certificate presented after your platform edge terminates the connection. Pair TLS notAfter with RDAP domain registration data so revalidation is not blocked by registrar billing.

Run a one-shot proof on /check, then add the production hostname to monitoring with alerts at 30, 14, 7, and 1 day thresholds. ssldays reads the live chain external users see—useful when shared hosting, PaaS edges, or CMS layers each claim TLS is fine.