A WordPress SSL certificate error is the kind of problem that scares visitors away before they ever see your site. Instead of your homepage, they get a full-page browser warning — “This site can’t provide a secure connection,” “Your connection is not private,” or “NET::ERR_CERT_DATE_INVALID” — with a padlock that’s broken or crossed out. It looks alarming, and to a customer it reads as “this site isn’t safe.” The good news: the cause is almost always one of a handful of certificate issues, and most are quick to fix once you know which one you’re facing.
This is a different problem from a mixed-content warning, where the padlock is merely marked “not fully secure” because some images or scripts still load over http. Here, the secure connection is failing outright — the browser won’t even show the page.
Step 1: Read the exact error
The browser is telling you more than it seems. The specific wording narrows the cause down fast:
- “Certificate expired” / ERR_CERT_DATE_INVALID — your certificate lapsed and wasn’t renewed.
- “Name mismatch” / ERR_CERT_COMMON_NAME_INVALID — the certificate is for a different domain (often
wwwvs non-www, or a certificate that only covers one of them). - “Not private” with no certificate at all — a certificate was never installed, or isn’t installed on the server your visitors reach.
- “Weak” or protocol errors — an outdated, misconfigured TLS setup on the server.
Step 2: Fix an expired certificate
By far the most common cause. Most certificates today are the free, auto-renewing kind, and they’re meant to renew themselves every few months without anyone lifting a finger. When you get an “expired” error, that auto-renewal quietly failed — usually a server-side hiccup. On managed hosting this is handled for you; on hosting where you’re responsible for it, you’ll renew the certificate in your host’s control panel or re-run the tool that issued it. Once the new certificate installs, the warning clears immediately.
Step 3: Fix a name mismatch (www vs non-www)
If the certificate covers yoursite.com but a visitor lands on www.yoursite.com (or the reverse), the browser refuses the connection because the names don’t match. Two things to line up:
- Make sure your certificate covers both the
wwwand non-wwwversions of your domain — a standard certificate usually can, or a wildcard certificate covers subdomains too. - In WordPress, set your Site Address (URL) under Settings, General to the exact version you want as canonical, and redirect the other to it so visitors always land on the covered name.
Step 4: Confirm the certificate is actually installed
If there’s no certificate at all, one either was never issued or isn’t installed on the server handling your traffic. Issue a free certificate through your host, and make sure it’s applied to the live domain, not just a temporary or staging address. If your domain sits behind a content delivery network or proxy, remember the certificate has to be valid at every step — the delivery network and your own server both.
Step 5: Push WordPress fully onto HTTPS
Once the certificate is valid, make sure WordPress itself is using it. Set both the WordPress Address and Site Address to the https:// version under Settings, General, and redirect all http traffic to https. If a stubborn setting is fighting you, you can pin the URLs in wp-config.php (WordPress’s main settings file):
define('WP_HOME','https://yoursite.com');
define('WP_SITEURL','https://yoursite.com');
After the certificate is fixed, if the padlock still shows “not fully secure,” you’ve moved on to a mixed-content issue — our guide on how to force HTTPS and fix mixed content takes it from there.
Step 6: Clear caches and re-test
Browsers and CDNs cache certificate state, so after a fix you might still see the old warning for a while. Test in a private browser window, on your phone, and ideally from a different network. If the certificate is genuinely valid now, the warning will be gone for new visitors even if your own browser is being slow to catch up.
When the fix is really the host
Here’s the honest truth about SSL: on hosting that’s actually looking after your site, you should never see a certificate error at all. Certificates should be issued automatically, renewed automatically well before they expire, and cover both versions of your domain from day one. An expired-certificate warning on a live business site almost always means nobody was watching the renewal.
That’s baked into managed WordPress hosting with us. Certificates are set up and auto-renewed for you, https is enforced, and the whole thing is set up so a lapsed certificate doesn’t get the chance to scare your customers off. It’s one of the quiet essentials — the sort of thing that belongs in any honest list of what managed hosting should include. And it’s the same flat price whether you run a single site or a portfolio; the SSL care is part of the plan, not a paid add-on.
A quick recap
- Read the exact browser error to identify the cause.
- Renew an expired certificate.
- Cover both
wwwand non-www, and redirect to one. - Confirm the certificate is installed on the live server (and on your CDN).
- Set WordPress fully to https and redirect http.
- Clear caches and re-test on another device and network.
If certificate warnings keep coming back — or you’d simply rather never think about renewals again — that’s exactly what we take off your plate. Getting SSL right and keeping it right is routine work for our US-based team. If your site is throwing other symptoms alongside the SSL warning, our emergency troubleshooting checklist covers the neighboring problems.