Browsers don't just say "SSL is broken." They throw a specific code — NET::ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, ERR_CERT_AUTHORITY_INVALID — or quietly downgrade the padlock to a "Not fully secure" warning while the rest of the page loads fine. Each of these means something different, and each has a different fix. Here's how to tell them apart and clear them for good, whether the certificate came from cPanel's AutoSSL, a paid CA, or Cloudflare.

Symptom: Which Error Are You Actually Seeing?

Open the browser's certificate details (click the padlock, or the warning triangle) before doing anything else. The exact wording tells you which of four problems you have:

  • "Your connection is not private" + NET::ERR_CERT_DATE_INVALID — the certificate has expired, or the server's clock is wrong.
  • NET::ERR_CERT_COMMON_NAME_INVALID — the certificate is valid, but it wasn't issued for the hostname you're visiting.
  • NET::ERR_CERT_AUTHORITY_INVALID — the browser can't build a trusted path back to a root CA, usually a missing intermediate certificate.
  • Grey padlock with an "i" or "Not fully secure," page loads but images/scripts are blocked — mixed content, not a certificate problem at all.

Cause 1: Expired Certificate

This is the simplest case and the one people panic about least usefully. Certificates aren't permanent — Let's Encrypt and Sectigo certs (what most AutoSSL setups use) last 90 days and renew automatically; paid certs from a registrar or CA typically last 1-2 years and do not auto-renew. If a renewal job silently failed, or a manually-purchased cert simply reached its end date, you get ERR_CERT_DATE_INVALID.

Check the actual expiry from the command line instead of trusting the dashboard:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

That prints notBefore and notAfter. If notAfter is in the past, the fix is a straight reissue — in cPanel, go to SSL/TLS Status and click Run AutoSSL, or if it's a paid cert, generate a new CSR and re-submit it to your CA.

Cause 2: Common Name / SAN Mismatch

A TLS certificate lists the exact hostnames it's valid for in its Subject Alternative Name (SAN) field. If you visit www.example.com but the certificate only covers example.com (or vice versa), or the cert was issued for a completely different domain that used to sit on this IP, the browser refuses it outright with ERR_CERT_COMMON_NAME_INVALID.

This shows up most often after:

  • A site migration where the new server's default cert (or a leftover cert from a previous tenant) is being served instead of the right one
  • Adding www as a separate DNS record without adding it to the certificate's SAN list
  • A wildcard cert that doesn't actually cover the specific subdomain you're hitting (wildcards only match one level deep — *.example.com covers shop.example.com, not shop.staging.example.com)

Confirm exactly what's covered:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

If your hostname isn't in that list, reissue the certificate with both the bare domain and the www variant included, or check that the web server's virtual host is actually serving the certificate you think it is — a misconfigured Apache/Nginx server block will happily serve the wrong SSL cert for a hostname it doesn't recognize.

Cause 3: Incomplete Certificate Chain

This is the sneaky one, because the site often looks fine in Chrome on your laptop but throws warnings on a phone, in curl, or in older browsers. It happens when the server sends only the leaf certificate and skips the intermediate certificate that links it back to a trusted root. Some clients cache intermediates and paper over the gap; others don't.

Test it properly with SSL Labs' server test, or from the command line:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl verify -CApath /etc/ssl/certs

If you see unable to get local issuer certificate, the chain is incomplete. In cPanel, re-installing via AutoSSL usually fixes this automatically since it bundles the full chain. If you installed a paid cert manually, make sure you concatenated the intermediate bundle the CA gave you after your certificate in the "Certificate Authority Bundle" field — not just the leaf cert by itself.

Cause 4: Mixed Content

The certificate itself can be perfect and you'll still get a downgraded padlock if the page loads any resource — an image, a script, a stylesheet, an iframe — over plain http:// instead of https://. Browsers block "active" mixed content (scripts, stylesheets) outright and just warn on "passive" content (images).

Open the browser dev tools console and reload the page; blocked or insecure requests are logged there by URL, which is the fastest way to find the culprit. Common sources:

  • Old blog posts or widgets with hardcoded http://example.com/... image links
  • A theme or plugin loading a font or script from a hardcoded HTTP CDN URL
  • WordPress's Settings → General still set to http:// for the site or WordPress address

For WordPress, after fixing the settings, run a database search-and-replace for leftover http:// references in post content:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

As a blunt safety net you can add a Content-Security-Policy header to auto-upgrade insecure requests, but treat it as a patch, not a fix — it doesn't address the underlying hardcoded links:

Header set Content-Security-Policy "upgrade-insecure-requests"

Prevention

  • Check SSL/TLS Status in cPanel monthly, or set a calendar reminder if you're on a manually-managed paid certificate.
  • Whenever you migrate a site or add a subdomain, immediately confirm the certificate's SAN list covers every hostname you'll actually serve.
  • When installing a certificate manually, always include the full intermediate chain the CA provides — never just the leaf certificate.
  • Run new pages and older content through a quick SSL Labs or browser console check after any theme, migration, or CDN change, since that's when mixed content usually gets reintroduced.

Frequently Asked Questions

Why does my site show as secure on desktop Chrome but throws a warning on my phone?

This is the classic sign of an incomplete certificate chain. Desktop Chrome sometimes has the missing intermediate certificate cached from another site, while mobile browsers and other tools don't, so they can't build a trusted path and reject the certificate.

I renewed my certificate but the browser still shows the old expiry date. Why?

The web server usually needs to reload or restart to pick up the new certificate files, and browsers cache certificates for a session. Restart Apache/Nginx (or wait for cPanel's AutoSSL to finish deploying it), then check with a fresh incognito window rather than a tab that was already open.

Can a certificate be valid and still trigger a "Not Secure" warning?

Yes — that's almost always mixed content. The certificate itself checks out, but the page is loading at least one resource over plain HTTP, so the browser downgrades the connection indicator even though the main document is encrypted.

Do wildcard certificates cover all subdomains automatically?

Only one level. *.example.com covers shop.example.com or mail.example.com, but not shop.staging.example.com — that needs its own certificate or a separate wildcard for *.staging.example.com.

What's the fastest way to check all of this without installing anything?

Run your domain through SSL Labs' SSL Server Test. It reports expiry, SAN coverage, chain completeness, and protocol issues in one pass, which is usually faster than checking each cause manually with openssl.