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

AutoSSL usually “just works” until it doesn’t. Then you’re dealing with failed DCV checks, users stuck on an expired certificate, or a site that loads on HTTPS but still shows “Not secure.” This cPanel AutoSSL troubleshooting tutorial walks you through the checks to run in WHM, the logs to review on the server, and the fixes that restore normal renewals.

The steps below assume you manage a cPanel/WHM server (VPS or dedicated) and you’re comfortable with SSH. If you’d rather not spend your evening chasing DCV failures, consider a managed VPS hosting plan from HostMyCode for control panel patching, TLS upkeep, and ongoing monitoring.

What you need before you start (quick checklist)

• WHM root access (or reseller access with the right privileges).
• SSH access as root (strongly recommended for log reads and curl tests).
• Your hostname resolves correctly to the server IP (A/AAAA), and rDNS is set for mail reputation (separate topic, but commonly misconfigured).
• Port 80 and 443 reachable from the internet (AutoSSL validation depends on this).

If DNS is part of your issue (wrong A record, AAAA pointing elsewhere, slow propagation), keep this related runbook handy: MX Record Setup Tutorial (2026).

The same DNS hygiene applies to web validation, not just mail.

Map the symptom to the right AutoSSL failure mode

AutoSSL failures are repetitive. Label the symptom first.

You’ll usually reach the root cause faster.

• AutoSSL says “The system was unable to fetch the DCV file.” Usually port 80 reachability, a redirect chain, or a proxy in the way.
• AutoSSL issues a cert, but the browser still shows the old one. You’re likely hitting the wrong vhost, the wrong IP, a CDN/proxy endpoint, or an SNI mismatch.
• HTTPS works but “Not secure” persists. Mixed content (HTTP assets) or missing security headers. The certificate is fine; the page isn’t.
• Failures only for some domains/accounts. Addon/parked domain DNS mismatch, a docroot problem, or per-account rules blocking DCV paths.

Step 1: Confirm AutoSSL is enabled and using the expected provider

In WHM, go to SSL/TLS → Manage AutoSSL.

1. Verify the AutoSSL Provider (commonly Let’s Encrypt or cPanel (Sectigo)).
2. Make sure AutoSSL is enabled for the affected accounts.
3. Check Options for “Allow AutoSSL to replace invalid or expiring certificates” so AutoSSL can recover cleanly.

Practical note: If you recently switched providers, double-check what’s selected in WHM.

Policy changes and rate limits still happen. It’s easy to end up with “a valid cert” that isn’t the one you expected.

Pick one provider and stick with it.

That keeps renewals predictable.

Step 2: Run AutoSSL for a single user and read the log like a detective

In WHM → Manage AutoSSL:

1. Select the impacted user.
2. Click Run AutoSSL For Selected Users.
3. Open the result details and copy the exact error string.

Then switch to SSH and review the most recent output. On most cPanel systems, you’ll also find related entries in cPanel’s log directories.

tail -n 200 /usr/local/cpanel/logs/error_log
ls -lah /var/cpanel/logs

If the error mentions DCV, treat it like a failing HTTP request.

Don’t guess. Reproduce it from outside the server.

Step 3: Reproduce DCV checks from your own terminal (HTTP-01 basics)

AutoSSL commonly uses HTTP validation (HTTP-01). The certificate authority expects to fetch a token from a URL like:

http://your-domain.tld/.well-known/pki-validation/...

Even if you force HTTPS for users, the validator still needs reliable access to the token over HTTP.

Run these checks:

# Replace example.com with the failing domain
curl -I http://example.com/
curl -I http://www.example.com/

# If you have a specific DCV URL from WHM logs, test it directly
curl -I http://example.com/.well-known/pki-validation/test.txt

What “good” looks like:

• HTTP/1.1 200 OK for the DCV file URL (or a clean 301/302 chain that ends at 200 and does not require auth).
• No redirect loops (301 → 301 → 301).
• No forced redirect to a different hostname that isn’t being validated (often caused by www/non-www rules).
• No 401/403 from a security plugin, WAF rule, or hotlink protection.

Step 4: Fix the most common DCV breakers (redirects, rewrites, and proxies)

DCV failures usually come from “helpful” rules that were never tested against /.well-known/ paths.

Problem: HTTP to HTTPS redirect blocks the DCV file

Some stacks redirect everything to HTTPS, but don’t serve the validation file correctly over HTTP.

This is especially common behind a proxy/CDN.

Fix: allow the validation path through before your redirects. For Apache (.htaccess), add this near the top:

<IfModule mod_rewrite.c>
RewriteEngine On

# Allow DCV/ACME paths
RewriteRule ^\.well-known/ - [L]

# Your existing redirect rules below
# RewriteCond %{HTTPS} !=on
# RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Problem: A reverse proxy or CDN points the domain somewhere else

If the domain sits behind a CDN/proxy, the CA validates the edge—not your origin.

That can work, but only if the edge forwards the validation path correctly.

Quick diagnostic:

dig +short A example.com
dig +short AAAA example.com
curl -I http://example.com/ | head

If the IPs don’t match your server (or you see a proxy IP you didn’t expect), decide where validation should happen.

If you need strict origin control, temporarily set DNS to “DNS only” (no proxy) during issuance. Then re-enable the proxy after the certificate installs.

Problem: The domain resolves to IPv6 (AAAA) but the server isn’t serving it

This one burns time because IPv4 looks fine.

If the domain has an AAAA record pointing to an unreachable IPv6 address, some validators will try IPv6 first and fail.

Fix options:

• Remove/disable the AAAA record if you don’t serve IPv6 on this host.
• Properly configure IPv6 on the server and ensure Apache/LiteSpeed listens and routes vhosts on IPv6.

Step 5: Confirm vhost routing and the document root for the failing domain

AutoSSL writes validation files into the domain’s document root.

If the docroot isn’t what you think it is—or the domain is mapped to a different account—DCV will fail.

Start in WHM. Confirm the account owns the domain and that the domain is mapped where you expect.

Then inspect the vhost config generated by Apache/LiteSpeed:

# Common location on cPanel
grep -R "ServerName example.com" -n /etc/apache2/conf.d/userdata/ 2>/dev/null || true
grep -R "ServerName example.com" -n /usr/local/apache/conf/userdata/ 2>/dev/null || true

# Quick check of docroot through httpd -S
/usr/sbin/httpd -S 2>/dev/null | grep -i "example.com" || true

Pitfall: after a migration, parked domains often end up attached to the wrong account.

Check WHM for ownership instead of relying on what “should” be true.

If you’re actively moving accounts, line this up with a clean transfer plan. This migration guide helps prevent DNS and TLS surprises: cPanel Transfer Tool Tutorial (2026).

Step 6: Check firewall/WAF rules that block the validation path

Security layers can block “odd looking” paths like /.well-known/.

If you run ModSecurity (common on cPanel), confirm you aren’t denying the validator request.

• WHM → ModSecurity™ Vendors / ModSecurity™ Tools
• Look for rules triggered by the validation request in audit logs.

If you want a safe enablement approach that won’t wreck WordPress logins or checkout flows, see: cPanel ModSecurity Setup Guide Tutorial (2026).

Network-level check: confirm ports 80/443 are reachable from outside your network.

# On the server (verifies local listeners)
ss -lntp | egrep ':80|:443'

# From your workstation
nc -vz example.com 80
nc -vz example.com 443

Step 7: Fix “certificate installed but browser shows old cert” (SNI/IP mix-ups)

If WHM shows a new certificate but browsers keep showing the expired one, you’re almost always connecting to a different IP or vhost than you think.

Confirm what the server is actually presenting

# Replace example.com with the domain
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Verify the basics:

• NotAfter matches what WHM installed.
• Subject includes the right domain (or SAN).
• You’re connecting to the correct IP (verify with dig +short A).

Common causes and fixes

• Wrong DNS target: the A record still points to the old server. Update it, then wait for TTL to expire.
• CDN edge cache: the CDN is still serving an old cert. Purge/refresh at the CDN, or confirm the CDN’s origin cert mode.
• Shared IP + missing SNI scenario: rare in 2026, but legacy clients without SNI can see the default cert. Ensure the default/hostname cert is valid too.

Step 8: Resolve mixed content warnings after AutoSSL succeeds

If the certificate is valid but the browser still warns users, the problem is usually mixed content.

The page loads over HTTPS, but scripts/images/styles still load over HTTP.

Fast way to find offenders: open DevTools → Console and look for “Mixed Content” messages. Each one includes the exact URL you need to fix.

For WordPress, you can often clean this up without adding another plugin:

• Ensure WordPress Address and Site Address use https://.
• Search/replace old http URLs carefully (best done with WP-CLI on a backup).

If you’re operating WordPress on VPS and want predictable HTTPS + performance, HostMyCode’s WordPress hosting is designed for stable TLS, caching options, and support that understands control panels.

Step 9: AutoSSL for the server hostname and service certificates

Users notice when webmail, cPanel, or WHM throws certificate warnings.

That’s often the server hostname certificate, not a website certificate.

In WHM:

1. Go to Service Configuration → Manage Service SSL Certificates.
2. Check the certificate for cpanel, whm, webmail, ftp, and mail services.
3. Verify the hostname resolves correctly (A/AAAA) and is reachable.

Heads-up: if your hostname A record points to a private IP or the wrong public IP, AutoSSL will fail for the hostname.

Website AutoSSL can still work at the same time.

Step 10: Common AutoSSL edge cases (and the clean fixes)

Edge case: Domain points to the server, but the site is a “Coming Soon” redirect elsewhere

If HTTP requests bounce to a different host that isn’t being validated, DCV can fail.

Fix: temporarily disable the redirect, or add an exception for /.well-known/ as shown earlier.

Edge case: Account uses CloudLinux/CageFS and custom docroots

AutoSSL expects consistent docroots.

If a user heavily customized their home directory, or you restored from a partial backup, validation files can land somewhere that isn’t web-accessible.

Fix: correct the domain’s document root in cPanel, then rebuild Apache conf and restart:

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

Edge case: DNS propagation mismatch during migrations

During cutover, some resolvers hit the new server while others still reach the old one.

AutoSSL may validate against one endpoint while users browse the other.

Fix: lower TTL before migrations, keep the old server serving the same validation/redirect rules temporarily, then issue/renew after DNS settles.

For a disciplined backup-and-restore approach around migrations, this tested runbook is a good companion: Disaster recovery tutorial (2026).

Step 11: Verify renewal automation and avoid repeating the incident

Once issuance works, make sure renewals will still work next month.

• Confirm AutoSSL runs regularly: WHM schedules it, but verify it isn’t failing silently.
• Keep port 80 open for validation, even if you redirect normal traffic to HTTPS.
• Standardize redirect rules across accounts; don’t let each customer invent a fragile rewrite chain.
• Document CDN/proxy behavior for ACME/DCV paths so you don’t rediscover the same issue later.

Quick monthly check (SSH): sample a few domains and confirm expiry is comfortably in the future.

# Check a domain's current expiry date
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Troubleshooting flowchart (fast decision list)

1. AutoSSL fails with DCV error → test curl -I http://domain/.well-known/....
2. If curl can’t reach port 80 → firewall/DNS/proxy problem, fix reachability first.
3. If curl redirects strangely → add /.well-known/ exception in rewrites.
4. If AutoSSL succeeds but cert still looks old → verify DNS target and check with openssl s_client.
5. If HTTPS is valid but browser warns → fix mixed content URLs in the site/app.

Summary: stable AutoSSL comes from boring, consistent plumbing

Reliable AutoSSL renewals come down to three basics: DNS points where you think it points, port 80 can serve a simple validation file, and your rewrite/proxy rules don’t interfere with the validator.

Get those right, and the certificate drama usually stops.

If you want a control panel server where SSL renewals, web stack updates, and day-two operations are handled with discipline, start with a HostMyCode VPS or step up to managed VPS hosting for hands-on assistance.

FAQ

Does AutoSSL require port 80 to be open?

Most AutoSSL validations still rely on HTTP access to a token file. Keep port 80 reachable and let your redirect rules allow /.well-known/ paths through.

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

Those domains often have different DNS, docroots, or redirect rules. Confirm the domain resolves to your server and that the vhost docroot is correct for that account.

AutoSSL installed a cert, but browsers show the old certificate—what’s fastest to check?

Run openssl s_client against the domain to see what the server presents, then verify the A/AAAA records point to that server. CDN proxies are also a common culprit.

How do I fix “Not secure” after SSL is valid?

That’s usually mixed content. Use browser DevTools to find HTTP asset URLs and update them to HTTPS (or fix hard-coded links in themes/plugins).