cPanel AutoSSL Troubleshooting Tutorial (2026): Fix Stuck Renewals, Wrong vhosts, and Missing DNS Records

AutoSSL usually fails for unglamorous reasons. The hostname may resolve to a different server. A proxy/CDN may intercept HTTP validation. Or a stale vhost mapping may remain after a migration.

This cPanel AutoSSL troubleshooting tutorial gives you a repeatable workflow. You’ll isolate the exact failure, apply the right fix, and confirm the certificate installs on the correct virtual host.

The steps below assume a cPanel & WHM server (common on AlmaLinux/Rocky) with root access. On client-facing servers, schedule changes for off-peak hours. Also factor in DNS TTL before you change records.

What you’ll check (and why it matters)

• Domain resolution: AutoSSL must validate the domain against the server’s public IP (or a proxy path that reaches it).
• Validation method: cPanel’s Let’s Encrypt flow typically uses HTTP-01; DNS-01 isn’t the default in most installs.
• cPanel account + vhost mapping: The cert has to land on the right Apache vhost / SNI configuration.
• Time, firewall, and proxy behavior: Clock drift, filtered ports, and CDN proxies can fail validation with minimal clues.
• Logs: The fastest fixes come from matching the AutoSSL error string to a known cause.

If you run production hosting on a VPS, stability matters more than people admit. Clean routing, consistent IP assignments, and predictable DNS reduce “random” AutoSSL failures.

A properly sized managed VPS hosting plan can make AutoSSL fade into the background. It becomes routine instead of a recurring ticket.

Prerequisites: confirm your hostname and licensing basics

First, make sure the server’s main hostname resolves to the server’s primary public IP. If this is broken, AutoSSL is only part of the fallout. You’ll also see odd TLS defaults and mail behavior.

# On the server
hostname -f

# Check what cPanel believes your main shared IP is
grep -E '^ADDR|^HOST' /etc/wwwacct.conf

# Quick DNS check (run from your workstation if possible)
dig +short A $(hostname -f)

If the A record points elsewhere, fix DNS before you change anything in WHM. If you also need reverse DNS aligned (important for mail reputation), handle PTR at the same time.

HostMyCode covers that workflow here: PTR record setup tutorial.

Step 1: reproduce the failure and capture the exact AutoSSL error

Don’t troubleshoot from memory. Trigger AutoSSL for one account. You want a short, relevant log you can act on.

1. WHM → SSL/TLS → Manage AutoSSL
2. Select a provider (cPanel/Let’s Encrypt) and keep it consistent while you debug.
3. Open the Manage Users tab.
4. Select one failing user and click Run AutoSSL For Selected Users.

Now read the log:

# Typical location for AutoSSL logs
ls -lah /usr/local/cpanel/logs/autossl/

# Read the most recent run
tail -n 200 /usr/local/cpanel/logs/autossl/* 2>/dev/null | sed -n '1,200p'

Common error strings you’ll see:

• DNS DCV: No local authority
• HTTP DCV: “403” or “404”
• CAA forbids issuance
• Rate limited
• Domain is on the AutoSSL excluded list

Once you have the exact wording from the log, stop guessing. The steps below map common failures to specific fixes.

Step 2: fix DNS validation failures (wrong A/AAAA, NXDOMAIN, split DNS)

DNS problems often show up as “NXDOMAIN,” “SERVFAIL,” “No local authority,” or validations that clearly hit the wrong IP.

Check A and AAAA for the exact hostname AutoSSL is validating

AutoSSL validates each covered name. That usually includes the apex, www, mail, autodiscover, and others. It depends on how the account is configured.

# Replace with a failing name from the AutoSSL log
DOMAIN=example.com

# Query from the server
dig +short A $DOMAIN
dig +short AAAA $DOMAIN

# Query authoritative nameservers (helps detect split DNS)
dig +trace $DOMAIN A | sed -n '1,120p'

• If A points to the wrong server, correct the zone at your DNS provider.
• If AAAA exists but the server doesn’t actually serve that hostname over IPv6, validation may go to IPv6 and fail. Either configure IPv6 correctly or remove the AAAA record.

Quick pitfall: CDN/proxy “orange cloud” breaks HTTP validation

If the domain is proxied through a CDN, HTTP-01 challenges may never reach your cPanel server. For issuance, temporarily switch the record to “DNS only.” Or configure the CDN to pass /.well-known/acme-challenge/ through without caching or blocking.

For safer DNS changes (low TTL, staged testing, rollback), keep this nearby: DNS cutover tutorial.

Step 3: fix HTTP DCV failures (403/404, redirects, wrong docroot)

With HTTP DCV, the CA requests a token under http://domain/.well-known/acme-challenge/. A 403 or 404 usually means the request isn’t reaching the vhost/docroot AutoSSL expects.

Verify the vhost and document root cPanel is using

# Find the cPanel user that owns the domain
DOMAIN=example.com
/usr/local/cpanel/bin/whoowns $DOMAIN

# Get the docroot for that domain
/usr/local/cpanel/bin/whmapi1 domainuserdata domain=$DOMAIN | egrep 'user:|documentroot:|serveralias:'

Now confirm the vhost exists and matches what cPanel reports:

# Apache vhost mapping (path varies by cPanel version; this is the common file)
grep -R "ServerName $DOMAIN" -n /etc/apache2/conf.d/ 2>/dev/null | head

# cPanel-managed userdata (useful for finding docroots and aliases)
ls -lah /var/cpanel/userdata/*/$DOMAIN* 2>/dev/null

Test challenge path locally

Create a temporary file in the expected docroot. Then fetch it over HTTP. This quickly confirms whether routing is correct.

DOCROOT=$( /usr/local/cpanel/bin/whmapi1 domainuserdata domain=$DOMAIN | awk -F': ' '/documentroot:/{print $2; exit}' )

mkdir -p "$DOCROOT/.well-known/acme-challenge"
echo ok-$(date +%s) > "$DOCROOT/.well-known/acme-challenge/ping"

# From the server (tests local routing)
curl -I http://$DOMAIN/.well-known/acme-challenge/ping
curl -s http://$DOMAIN/.well-known/acme-challenge/ping

• If you get 301/302 to HTTPS, that’s often fine. But long redirect chains can break validation. Fix redirect loops first.
• If you get 403, check ModSecurity rules and rewrite rules that block .well-known.
• If you get 404, you’re likely hitting the wrong vhost, the wrong docroot, or a proxy/CDN layer.

Redirect loops show up constantly during migrations. If your domain bounces between HTTP/HTTPS or between www/apex, fix that before you rerun AutoSSL: HTTPS redirect troubleshooting tutorial.

Step 4: fix “certificate installed on the wrong site” (SNI/vhost mismatches)

This looks dramatic because the browser shows the “wrong” certificate. In practice, it’s usually a mapping problem. A rebuild often clears it up.

Confirm which certificate Apache serves

DOMAIN=example.com

# Show the presented cert subject (run from anywhere with openssl)
echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

If the subject doesn’t match the domain, check ownership and placement. The domain may be parked/addon’d under the wrong account. It may also exist as a duplicate where it shouldn’t.

Rebuild Apache conf and user data cache

After restores, migrations, and manual edits, rebuilding the webserver config is often the cleanest reset:

/usr/local/cpanel/scripts/rebuildhttpdconf
/usr/local/cpanel/scripts/restartsrv_httpd

# Rebuild userdata caches for a single user if needed
USER=$( /usr/local/cpanel/bin/whoowns example.com )
/usr/local/cpanel/scripts/updateuserdatacache --user=$USER

Re-run AutoSSL for that same user in WHM. If the certificate still installs to the wrong place, check for duplicate ServerName/ServerAlias entries across vhosts. This often happens when a domain is added to the wrong account.

Step 5: fix CAA record blocks (issuance forbidden)

CAA records restrict which certificate authorities may issue for your domain. If the log says “CAA forbids issuance,” you need a DNS change. It isn’t a server-side tweak.

Check existing CAA records

DOMAIN=example.com

# Query CAA
# If nothing returns, there may be no CAA, which is fine
# If it returns restrictions, you must allow your AutoSSL provider
 dig +short CAA $DOMAIN

If you use Let’s Encrypt through cPanel, CAA must allow it, for example:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"

Update the record at your DNS provider. Wait for TTL to expire. Then rerun AutoSSL.

Step 6: fix rate limits and “too many certificates” errors

Rate limits often follow repeated failed attempts. This is common across many subdomains. It also happens after migrations when the same SAN list is requested again and again.

• Stop hammering AutoSSL. Fix DNS and routing first.
• Reduce covered names temporarily. Remove unused subdomains from the account if they don’t need cert coverage.
• Stagger issuance. Run per-account while you stabilize things, not “all users” on a loop.

A simple workflow works best. Get one representative account issuing cleanly, then move to the next. That prevents one mistake from turning into a server-wide failure storm.

Step 7: check server time, firewall, and local resolver issues

AutoSSL can fail in confusing ways when the server clock drifts. It can also fail if outbound connections to CA endpoints are blocked.

Confirm time sync (TLS hates clock drift)

timedatectl
chronyc tracking 2>/dev/null || true

If time looks suspicious, fix NTP first. With enough drift, TLS validation and API calls become unreliable.

HostMyCode walks through common causes and fixes here: VPS time sync troubleshooting tutorial.

Confirm required ports aren’t blocked

At minimum, you need outbound HTTPS (443) for ACME API calls. Most setups also need inbound 80/443 reachable for validation and installs.

# Quick port listeners
ss -lntp | egrep ':(80|443)\s'

# Firewalld (Alma/Rocky often)
firewall-cmd --list-services 2>/dev/null || true
firewall-cmd --list-ports 2>/dev/null || true

# CSF (common on cPanel)
csf -l 2>/dev/null | head || true

If you run CSF/LFD, check whether a temporary bot spike led to blocks. Also verify port 80 is open externally. AutoSSL may still rely on it even if you force HTTPS.

Step 8: run a clean re-issue and verify installation end-to-end

After each change, rerun AutoSSL for the same user. You’re aiming for “The certificate is now installed.” You also want a run that doesn’t skip domains unexpectedly.

Confirm the new cert covers what you think it covers

DOMAIN=example.com

# Show SANs (Subject Alternative Names)
echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null \
 | openssl x509 -noout -text | sed -n '/Subject:/,/X509v3 Subject Alternative Name/p' | sed -n '1,60p'

Then test from a browser and confirm:

• The chain is trusted.
• The certificate matches the expected name (and www if you want it covered).
• Redirect behavior is stable (no loops, no unexpected hops).

Practical checklist: the 10-minute AutoSSL triage

1. Run AutoSSL for one user; copy the exact error.
2. dig A/AAAA for each failing name; remove broken AAAA.
3. Disable CDN proxy temporarily if HTTP-01 is blocked.
4. curl http://domain/.well-known/acme-challenge/ping to confirm routing.
5. Fix redirect loops before retrying.
6. Check CAA records if issuance is forbidden.
7. Confirm timedatectl looks sane.
8. Confirm ports 80/443 are open and Apache is listening.
9. Rebuild Apache conf if vhosts look wrong.
10. Verify the served cert with openssl s_client.

Where HostMyCode fits (and how it prevents repeat failures)

AutoSSL issues often spike right after a hosting move or a server resize. If you want fewer moving parts, focus on stability. Stable IPs, straightforward networking, and cleanup help reduce post-migration leftovers. That makes cPanel behavior more predictable.

HostMyCode offers HostMyCode VPS plans for cPanel deployments and managed VPS hosting when you want someone else handling routine admin work. That includes updates, service restarts, and the recurring “why did SSL fail?” checks.

FAQ

Does cPanel AutoSSL require port 80 to be open?

Often, yes. Many AutoSSL flows rely on HTTP-01 validation. That method needs inbound port 80 reachable from the internet. If you block 80, issuance can fail even if your sites “force HTTPS.”

Why does AutoSSL fail only for some addon or parked domains?

Those domains often have different DNS records (wrong A/AAAA), different proxy settings, or incomplete vhost mappings after an account move. Check DNS first. Then confirm the docroot and vhost for each name.

AutoSSL says it succeeded, but browsers still show the old certificate. What now?

Confirm what Apache serves with openssl s_client. If the new cert is installed but clients still see old data, you’re likely hitting a CDN edge cache or another IP (split DNS). Verify DNS from multiple networks.

Can a CAA record break AutoSSL renewals?

Yes. If you set CAA to allow only specific CAs, and your AutoSSL provider isn’t allowed, issuance will fail until you update the CAA record.

What’s the safest way to troubleshoot without impacting every hosted site?

Run AutoSSL for a single failing account. Fix the specific cause. Only then expand to more accounts. Avoid global “Run AutoSSL for all users” loops until you see clean issuance on a test user.

Summary: a repeatable fix beats random retries

AutoSSL isn’t mysterious once you treat it like a validation pipeline. DNS must point to the right place. HTTP must land on the right vhost. The server must be reachable and time-synced.

Capture the exact error, apply the matching fix, then verify what’s served from outside the server.

If you’re planning a migration or consolidating multiple cPanel accounts, run it on predictable infrastructure. Start with a stable HostMyCode VPS (or choose managed VPS hosting) so AutoSSL validation, renewals, and client trust don’t depend on luck.