cPanel AutoSSL Troubleshooting Tutorial (2026): Fix Failed Renewals, DCV Errors, and Broken HTTPS in WHM

AutoSSL usually “just works” until it doesn’t. Then you’re dealing with browser warnings, failed renewals, and unhappy clients.

This cPanel AutoSSL troubleshooting tutorial walks through the checks that fix most WHM AutoSSL failures in 2026. The goal is a methodical workflow with minimal risk to production sites.

This guide assumes you manage a cPanel/WHM server on AlmaLinux/Rocky Linux. It also assumes you have root-level WHM access.

On a VPS, the same workflow applies. Fresh IPs and new routes can expose DNS and connectivity problems faster.

Before you touch anything: confirm what’s actually failing

Start by locating the exact break point. Most failures fall into one of three buckets: provider (Sectigo / Let’s Encrypt), DCV (domain control validation), or installation (Apache/Nginx/LiteSpeed, SNI, permissions).

WHM path: WHM » SSL/TLS » Manage AutoSSL
Check: The most recent log line and the exact error text per domain

If many unrelated domains fail at once, treat it as server-wide. Common causes include firewall rules, DNS recursion, time drift, IPv6 routing, or a provider misconfiguration.

If only one customer domain fails, treat it as domain-specific. DNS issues, a CDN/proxy setting, or a redirect loop are the usual culprits.

Step 1 — Validate basic prerequisites (these fix a surprising number of cases)

AutoSSL needs four things to stay reliable: correct DNS answers, accurate server time, outbound HTTPS access to the CA, and inbound HTTP/HTTPS reachability for DCV.

Run these checks from SSH as root.

1) Confirm server time and NTP

timedatectl
chronyc sources -v 2>/dev/null || true

If the system clock is off by even a few minutes, validation can fail. TLS errors can also look inconsistent.

Fix NTP first.

2) Confirm outbound HTTPS works (provider API calls)

curl -sS https://api.sectigo.com/ >/dev/null || echo "Outbound HTTPS may be blocked"
curl -sS https://acme-v02.api.letsencrypt.org/directory | head

If these hang or error, check outbound (egress) firewall rules and upstream filtering. On hardened builds, it’s easy to restrict outbound port 443 by accident.

3) Confirm inbound HTTP/HTTPS reachability

From a machine outside the server (or a looking-glass), check:

http://yourdomain.tld/.well-known/pki-validation/ (Sectigo HTTP DCV paths may vary)
http://yourdomain.tld/.well-known/acme-challenge/ (Let’s Encrypt HTTP-01)
https://yourdomain.tld (final install health)

If HTTP force-redirects to HTTPS while HTTPS is broken, you can trigger a DCV loop. Get plain HTTP working first.

Tighten redirects after issuance.

If you suspect firewall rules, verify ports in a controlled way instead of guessing. The port-by-port approach in Firewall audit tutorial helps confirm 80/443/2087/2083/25/587 behave as intended.

Step 2 — Fix the most common AutoSSL failure: DCV doesn’t reach your server

AutoSSL can’t issue a certificate until the CA can prove you control the domain. On cPanel systems, DCV failures usually come from DNS pointing elsewhere.

Other common causes include a CDN proxy intercepting requests, or redirects sending validation to a different host.

2.1 Confirm the domain resolves to the correct IP

On the cPanel server:

DOMAIN=example.com

dig +short A $DOMAIN

dig +short AAAA $DOMAIN

curl -sS -I http://$DOMAIN | head -n 10

Compare A/AAAA results to the server’s public IP:

curl -sS https://ifconfig.me
ip -br a

If the A record doesn’t match your server IP, AutoSSL will fail until DNS is corrected. If you just moved hosting, treat it like a migration issue.

It’s usually not an SSL issue.

This internal guide helps: DNS migration without downtime.

2.2 Watch for CDN/proxy “orange cloud” issues (Cloudflare and similar)

If a domain is proxied through a CDN, the CA’s DCV request can hit the CDN edge instead of your origin. Some setups still validate.

Failures are more likely when:

the CDN enforces HTTPS-only and your origin cert is expired
the CDN blocks /.well-known/ paths
there’s a redirect to a different hostname

Fast test: switch the record to “DNS only” (no proxy) for issuance. Run AutoSSL, then re-enable the proxy.

2.3 Fix redirect loops that break validation

From the server, trace the redirect chain:

curl -sS -I -L http://example.com/.well-known/acme-challenge/test | head -n 40

If it bounces between http/https or www/non-www, fix redirects before rerunning AutoSSL.

In cPanel, check:

cPanel » Domains » Redirects
CMS-level redirects (WordPress plugins, wp-config.php, site URL settings)
.htaccess rules under the domain’s document root (often /home/USER/public_html)

Step 3 — Check AutoSSL provider settings in WHM (and pick the right one)

WHM can use different AutoSSL providers depending on your cPanel build and licensing. In 2026, that usually means Sectigo (the default).

Some servers also use Let’s Encrypt if you enabled it.

WHM: WHM » SSL/TLS » Manage AutoSSL
Verify: the provider is enabled, and you’ve accepted terms (if prompted)

If you need maximum flexibility (wildcards, DNS challenges, non-standard routing), an ACME workflow can fit better than relying only on AutoSSL.

For Nginx/Apache servers outside cPanel, see: Let’s Encrypt setup guide.

Step 4 — Read the AutoSSL logs the right way (so you stop guessing)

The WHM UI is good for a quick summary. The logs show the actual cause.

File names can vary slightly by cPanel version. These locations are typical:

/usr/local/cpanel/logs/error_log (broad cPanel errors)
/usr/local/cpanel/logs/autossl/ (AutoSSL runs, per provider)
/var/log/messages or /var/log/secure (OS-level issues)

Useful commands:

ls -lah /usr/local/cpanel/logs/autossl/ 2>/dev/null || true

tail -n 200 /usr/local/cpanel/logs/error_log

When you spot a failing domain, search for these markers:

DCV, CAA, NXDOMAIN, SERVFAIL
timeout, connection refused, 403, 404
rate limit (often after repeated forced runs)

Step 5 — Fix CAA record problems (silent SSL killers)

CAA records control which certificate authorities may issue for a domain. Restrictive CAA entries can break AutoSSL even when DNS and routing look fine.

Check CAA:

dig +short CAA example.com
dig +short CAA www.example.com

If CAA exists and your AutoSSL provider isn’t allowed, you have two options:

Update CAA to allow the provider (Sectigo or Let’s Encrypt).
Switch provider (if your environment supports it) to match the allowed CAA entries.

Example CAA entries (adjust to your provider policy):

; Allow Let's Encrypt
example.com. 3600 IN CAA 0 issue "letsencrypt.org"

; Allow Sectigo (often via sectigo.com)
example.com. 3600 IN CAA 0 issue "sectigo.com"

CAA updates still need DNS propagation time. If DNS is hosted externally, confirm you edited the authoritative zone.

Don’t edit an old copy on the cPanel server.

Step 6 — Confirm the domain is actually on the correct vhost (and not parked wrong)

On busy cPanel servers, domains can end up in odd states. They may be parked on the wrong account or assigned to a placeholder vhost.

They can also point at a shared IP that doesn’t match the expected SSL target.

From SSH, locate vhost mapping:

grep -R "ServerName example.com" -n /etc/apache2/conf.d/userdata/ 2>/dev/null | head

grep -R "example.com" -n /etc/apache2/conf.d/ 2>/dev/null | head

Then validate in WHM:

WHM » Account Information » List Accounts (confirm owner)
WHM » DNS Functions » Edit DNS Zone (confirm zone content)
WHM » SSL/TLS » Install an SSL Certificate on a Domain (verify correct cert target)

Step 7 — Repair common chain and installation issues (cert exists, but browsers still warn)

Sometimes AutoSSL issues the certificate, but installation doesn’t stick. In other cases, the server serves the wrong chain.

The result is familiar: “NET::ERR_CERT_AUTHORITY_INVALID” or “certificate not trusted,” even when the cert looks recent.

7.1 Test what the server is actually serving

DOMAIN=example.com

openssl s_client -connect ${DOMAIN}:443 -servername ${DOMAIN} -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Check three basics:

Subject matches the domain (not another site on the same IP)
Not After date is in the future
Issuer matches the expected CA

7.2 Fix mixed web stacks: Nginx in front of Apache/WHM

If you run Nginx as a reverse proxy in front of a cPanel Apache backend, WHM can show a valid deployment while Nginx still serves an old or wrong certificate.

That’s how you get “WHM says valid, browsers say invalid.”

In this setup, verify certificate paths and real-IP handling at the proxy layer. This internal walkthrough covers the common pitfalls: Nginx in front of cPanel without breaking SSL.

Step 8 — Make sure your firewall and security stack isn’t blocking DCV

AutoSSL often needs inbound HTTP (port 80) even if you force HTTPS. ModSecurity, WAF rules, and bot protection can also block requests under /.well-known/.

That breaks validation.

Checklist:

Allow inbound 80/tcp and 443/tcp to the server.
Do not block /.well-known/acme-challenge/ and CA validation paths.
Temporarily relax rules for the failing domain if needed, then re-tighten.

If you suspect a lockout or a messy ruleset, use the controlled workflow in VPS firewall troubleshooting. The same approach applies to WHM.

Step 9 — Force a single-domain recheck without hammering the CA

Repeatedly clicking “Run AutoSSL” can trigger rate limits. This is especially common while DNS is still wrong.

A safer cadence is:

Fix DNS/proxy/redirect/firewall first.
Wait for authoritative DNS to answer correctly.
Run AutoSSL once, then inspect logs.

In WHM, you can target a specific user or domain from the AutoSSL interface. If you need CLI access (and your cPanel build supports it), check for scripts under /usr/local/cpanel/bin/.

Stick to supported commands for your version.

Step 10 — Troubleshoot “hostname certificate” warnings (WHM/Exim/Dovecot)

Many SSL complaints aren’t about customer sites. They’re about service endpoints like:

WHM: https://server.example.com:2087
cPanel: https://server.example.com:2083
Webmail: https://server.example.com:2096
Mail services: IMAP/POP/SMTP

Most of these come down to hostname mismatch. Verify that your server hostname resolves to the server IP.

Also confirm forward and reverse DNS are correct.

Check hostname: hostname -f
Check A record: dig +short A $(hostname -f)

PTR matters for mail deliverability and general trust. For the current 2026 workflow, use: rDNS setup guide.

Step 11 — Quick recovery: restore HTTPS fast while you troubleshoot AutoSSL

Sometimes you need to restore HTTPS before you finish root-cause work. These options often buy you time:

Install a certificate manually (temporary) while you keep working on DCV.
Serve a valid cert at the proxy layer (if you have one) and fix origin later.
Roll back a recent change (DNS, firewall, redirect) if you can identify it.

If you want a broader renewal-focused diagnostic flow, pair this with: TLS renewal troubleshooting.

Step 12 — Prevent repeat incidents: a short AutoSSL reliability checklist

Standardize DNS: avoid split-brain zones; document where authoritative DNS lives.
Monitor expiry: alert at 14 days and 7 days before expiration (per domain).
Keep port 80 reachable: even if you force HTTPS, allow ACME/DCV paths.
Document proxy behavior: especially for resellers using Cloudflare.
Patch cPanel safely: AutoSSL provider logic changes over time. Maintain updates.

If you host client sites at scale, the difference is rarely “better SSL.” It’s consistent DNS, tighter networking, and predictable change control.

A managed VPS hosting plan can also take routine patching and baseline security work off your plate.

Where HostMyCode fits (and when to consider moving)

If WHM runs on an underpowered node, or the network is unreliable, SSL failures tend to repeat. AutoSSL is sensitive to DNS, HTTP reachability, and clean service restarts after updates.

For production cPanel workloads, plan for CPU headroom and steady disk I/O. This matters most during backups and update windows.

If your current environment is strained, consider running WHM on a HostMyCode VPS. You can also move to dedicated servers for higher-density reseller hosting.

If AutoSSL issues keep coming back, the root cause is usually basic hygiene: consistent DNS, clear firewall rules, and predictable patching. HostMyCode can run your WHM stack on a managed VPS or a reliable VPS so renewals and validations don’t turn into urgent tickets.

FAQ: AutoSSL failures in WHM

Why does AutoSSL fail for some addon domains but not the main domain?

Addon domains often use separate DNS zones, different proxy settings, or were attached to the wrong account/vhost. Start by confirming A/AAAA records and ownership in WHM.

Do I need port 80 open if every site forces HTTPS?

In many cases, yes. HTTP-based DCV (including ACME HTTP-01) needs port 80 reachable for /.well-known/ challenges. You can still force HTTPS for normal traffic while allowing those paths.

How do I know if a CAA record is blocking issuance?

Run dig +short CAA yourdomain.tld. If CAA exists and doesn’t authorize your CA (Sectigo/Let’s Encrypt), issuance can fail even when everything else looks correct.

WHM shows a valid certificate, but browsers still warn. What now?

Test the served certificate with openssl s_client using SNI. If you run Nginx/LiteSpeed/proxies, verify the certificate at the outermost layer, not just inside WHM.

How can I reduce SSL incidents across many client sites?

Standardize DNS management, monitor certificate expiry, keep cPanel updated, and avoid “mystery” firewall rules. For reseller setups, document CDN/proxy settings per client.

Summary

Most AutoSSL failures come from a short list: incorrect DNS answers, blocked validation paths, redirect loops, restrictive CAA records, or a mismatch between what WHM installs and what your web stack serves.

Work outside-in: DNS → HTTP reachability → provider logs → installation verification.

If you want fewer 2 a.m. surprises, run WHM on dependable infrastructure and keep the fundamentals clean. HostMyCode’s VPS hosting (or managed VPS hosting) is a solid foundation for cPanel servers where renewals happen quietly.