cPanel AutoSSL Failing? Fix That 'Not Secure' Warning

Your cPanel dashboard says the SSL certificate is active. AutoSSL ran successfully last night. And yet Chrome still slaps a "Not Secure" warning on your domain, or worse, throws a full-page privacy error. If you're staring at this right now, you're not imagining things — AutoSSL "succeeding" and your site actually being trusted by browsers are two different things, and the gap between them is where most support tickets come from.

Symptom: The Certificate Looks Fine in cPanel but Browsers Disagree

A few variations we see constantly:

• cPanel > SSL/TLS Status shows a green padlock next to the domain, but the live site shows "Not Secure" in the address bar.
• AutoSSL history shows repeated failures for one subdomain (usually www or an addon domain) while the main domain renews fine.
• Visitors get NET::ERR_CERT_COMMON_NAME_INVALID or ERR_CERT_DATE_INVALID even though you just renewed.
• The padlock shows, but clicking it reveals "connection is not fully secure" — that's mixed content, a different problem wearing the same costume.

Cause: It's Almost Always One of Five Things

1. A CAA record is blocking the certificate authority

If your DNS has a CAA record that only allows, say, Let's Encrypt, but your cPanel server's AutoSSL provider is Sectigo (or vice versa), issuance silently fails. This is the single most common cause we see on domains that were migrated from another host and inherited old DNS records.

2. Domain Control Validation (DCV) can't reach the server

AutoSSL proves you own the domain by requesting a file over HTTP or checking DNS. If a firewall, a security plugin, or a redirect rule (HTTP → HTTPS force-redirect before the cert exists) blocks that validation request, AutoSSL fails and quietly falls back to the last valid cert — which may already be close to expiry.

3. A proxy (usually Cloudflare) is sitting in front of the site

When Cloudflare's proxy (orange cloud) is on, the browser talks to Cloudflare's edge certificate, not your cPanel-issued one. If Cloudflare's SSL mode is set to "Flexible" and your origin cert is expired or missing, you get exactly this "looks fine in cPanel, broken in the browser" split.

4. Mixed content — the cert is fine, some assets aren't

Old http:// image, script, or CSS links hardcoded in the theme or database will trigger "not fully secure" even with a perfectly valid certificate. This is a WordPress database problem, not an SSL problem, and no amount of re-running AutoSSL will fix it.

5. Apache/Nginx is still serving the old certificate chain

Occasionally AutoSSL installs a new cert but the web server process hasn't picked it up, or an intermediate certificate is missing from the chain, so some browsers/devices trust it and others don't.

Fix: Work Through It in This Order

Step 1 — Confirm what's actually being served

Don't trust the cPanel UI alone. Check the live cert from the outside:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -dates -subject -issuer

Compare the "issuer" and expiry dates against what cPanel > SSL/TLS Status > AutoSSL History reports. If they don't match, the web server is the problem (Step 5), not AutoSSL itself.

Step 2 — Check for a blocking CAA record

dig CAA yourdomain.com +short

If it returns something like 0 issue "letsencrypt.org" but your server uses Sectigo/Comodo AutoSSL, add or edit the record:

yourdomain.com.  IN  CAA  0 issue "sectigo.com"
yourdomain.com.  IN  CAA  0 issue "letsencrypt.org"

You can list both if you're not sure which provider your host uses — it's a whitelist, not an either/or. No CAA record at all means every CA is allowed by default, which is also fine.

Step 3 — Let AutoSSL actually reach your domain

• In cPanel, temporarily disable any "force HTTPS" redirect in .htaccess while troubleshooting — a hard redirect can loop the HTTP validation request.
• If you're behind Cloudflare, pause the proxy (grey cloud, DNS-only) for the domain and its www record while AutoSSL runs, then re-enable proxying afterward.
• Whitelist your server's IP in any WAF or security plugin that might be blocking automated requests to /.well-known/pki-validation/.

Step 4 — Re-run AutoSSL and watch the log, don't just trust the padlock

Go to cPanel > SSL/TLS Status, select the domain, and click Run AutoSSL. Then open AutoSSL History immediately after — it tells you exactly which validation method failed and why, which is far more useful than the pass/fail icon.

Step 5 — If Cloudflare is proxying, fix the SSL mode

Set Cloudflare's SSL/TLS mode to Full (Strict), not Flexible. Flexible mode trusts any cert (or none) on the origin server and is the most common source of "secure in Cloudflare, broken at origin" reports.

Step 6 — Clean up mixed content

For WordPress, search and replace hardcoded http:// references in the database rather than just the theme files:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid --all-tables

Run that with WP-CLI over SSH, or use a plugin like Better Search Replace if shell access isn't available. Always back up the database first.

Prevention: Stop This From Happening Again

On Getwebup hosting, AutoSSL and DCV run against our own edge, so most of the CAA and proxy conflicts above simply don't come up — but if you've pointed a domain here through Cloudflare or another CDN, the same rules apply.