You open your website in Chrome and see “Not Secure” beside the address.
The confusing part? Your URL starts with https://. You installed an SSL certificate months ago. You even tested it once and everything looked fine.
So why is the browser still complaining?
Usually, HTTPS itself isn't the problem. Something around it is.
The certificate may have expired. A page may still be loading images over HTTP. Your server may be redirecting incorrectly. The certificate might not match the hostname. Or the browser may be reporting a deeper TLS configuration problem.
Chrome uses certificates to authenticate HTTPS sites and protect the connection between the browser and the website. When that trust check fails, Chrome can show errors such as NET::ERR_CERT_DATE_INVALID or ERR_CERT_COMMON_NAME_INVALID.
The good news is that most of these problems are fixable.
The trick is finding the actual one.
Why does my website say “Not Secure” with HTTPS?
First, check the exact warning.
If Chrome simply shows Not Secure, the page may still be using plain HTTP somewhere. Chrome explains that a connection marked “Not secure” isn't providing a private connection, meaning information sent through it could potentially be viewed or changed.
But a certificate error is different.
For example:
NET::ERR_CERT_DATE_INVALID
ERR_CERT_COMMON_NAME_INVALID
NET::ERR_CERT_AUTHORITY_INVALID
These don't all mean the same thing.
NET::ERR_CERT_DATE_INVALID commonly means the certificate is expired or the device's clock is wrong.
ERR_CERT_COMMON_NAME_INVALID usually points to a hostname mismatch. For example, the certificate might be valid for www.example.com but you're visiting example.com, and the certificate doesn't cover both.
NET::ERR_CERT_AUTHORITY_INVALID can mean the certificate isn't trusted by the browser, or that an intermediary is presenting an untrusted certificate.
Don't Google the error, copy the first fix you find, and hope for the best.
Read the actual certificate first.
In Chrome, click the site information icon beside the address, open the certificate details, and check the Subject, Validity, and Subject Alternative Name fields.
That's often enough to find the problem in two minutes.
The most common cause is mixed content
This one catches people constantly.
Your page loads over:
https://example.com
But somewhere inside the page, it requests:
http://example.com/images/logo.png
The main connection is encrypted. That image isn't.
That's called mixed content.
The same thing can happen with JavaScript, CSS, fonts, videos, iframes, API requests, and other resources.
A WordPress migration is a classic example. You move a site from HTTP to HTTPS, install the certificate, change the WordPress URL, and assume you're finished.
Then an old plugin still generates:
<script src="http://example.com/script.js"></script>
Now the site has an HTTPS address, but parts of the page are still trying to use HTTP.
Open Chrome DevTools and check the Console tab. Browsers will often tell you exactly which resource is being blocked or upgraded.
You can also search your source code or database for old HTTP URLs.
For a WordPress site, I'd specifically search for:
http://yourdomain.com
and:
http://www.yourdomain.com
Don't blindly replace every http:// string, though. External services and hardcoded URLs can behave differently, and a bad global replacement can create another problem.
Fix the source of the HTTP reference instead.
An SSL certificate can be installed and still be wrong
“I have an SSL certificate” isn't the same as “my HTTPS configuration is healthy.”
The certificate needs to be valid for the hostname you're using.
Imagine your business site works at:
https://example.com
but your certificate only covers:
www.example.com
A visitor going to the root domain can get a certificate-name error even though the server technically has an SSL certificate installed.
The same problem appears with subdomains.
You might have:
example.com
www.example.com
shop.example.com
api.example.com
These aren't automatically covered by every certificate.
Check the certificate's Subject Alternative Name (SAN) list. That's where modern certificates specify the hostnames they cover.
And check the expiration date.
A certificate that expired last night doesn't care that your website worked perfectly yesterday.
This is one reason SSL monitoring is more useful than a once-a-year certificate check. Certificate problems are boring right up until they take down a checkout page on a Sunday morning.
Your HTTP to HTTPS redirect can also be broken
A proper HTTPS setup should normally send visitors from HTTP to HTTPS.
For example:
http://example.com
↓
301 redirect
↓
https://example.com
The server should return a permanent redirect, usually 301, with an HTTPS URL in the Location header.
You can check this yourself from a terminal:
curl -I http://example.com
You want to see something similar to:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
Then check the HTTPS response:
curl -I https://example.com
This should return a successful response such as 200 OK, or another expected status depending on your application.
A common mistake is creating a redirect loop.
For example:
HTTP → HTTPS → HTTP → HTTPS → ...
This can happen when a reverse proxy or CDN handles TLS but the application behind it thinks the original request was HTTP.
The result is often:
ERR_TOO_MANY_REDIRECTS
Google's Chrome documentation specifically lists redirect loops and SSL certificate errors as separate classes of connection problems, which is why you shouldn't treat every HTTPS warning as an “SSL problem.”
HSTS makes HTTPS stricter, not magically safer
Once HTTPS works correctly, there's another header worth understanding:
Strict-Transport-Security: max-age=31536000; includeSubDomains
That's HSTS, or HTTP Strict Transport Security.
It tells browsers to remember that your site should only be accessed over HTTPS. The max-age value above is 31,536,000 seconds, which is one year. includeSubDomains extends the policy to subdomains.
HSTS is useful because it reduces downgrade and HTTP interception risks.
But here's the part people get wrong.
Don't turn on aggressive HSTS before you've tested every relevant subdomain.
If you publish:
Strict-Transport-Security: max-age=31536000; includeSubDomains
and legacy.example.com still only works over HTTP, you've just told browsers that subdomain must use HTTPS too.
That can break things.
MDN also recommends careful testing before using includeSubDomains, because it applies the policy to subdomains that may not yet support HTTPS correctly.
HSTS is a useful security control.
It's not a substitute for fixing broken TLS.
Don't confuse HTTPS with complete website security
This is probably the most important point.
HTTPS protects the connection between the browser and the server.
It doesn't tell you whether your WordPress plugin has a vulnerability.
It doesn't tell you whether someone added a malicious administrator account.
It doesn't tell you whether your server is exposing an old PHP version.
It doesn't tell you whether your website went offline at 3 AM.
And it definitely doesn't tell you whether your checkout actually works.
I've seen people spend hours getting an A-grade SSL report while their website was running an outdated plugin with a known vulnerability.
That's backwards.
I'd treat HTTPS as one layer of website security, not the whole thing.
You want the certificate monitored. You want uptime monitored. You want known vulnerabilities detected. And for important sites, you want actual browser checks that verify the things customers use, not just whether the homepage returns 200 OK.
That's the difference between checking whether a server is alive and checking whether a website is actually working.
For teams managing multiple sites, Torlyx combines SSL and uptime monitoring with vulnerability scanning and real-browser checks, so these problems can be detected continuously instead of waiting for a customer to report them. https://torlyx.com/features
How I'd troubleshoot a “Not Secure” website
If someone handed me a website showing this warning, I wouldn't start reinstalling SSL.
I'd check it in this order.
1. Check the exact browser error.
Is it NET::ERR_CERT_DATE_INVALID? ERR_CERT_COMMON_NAME_INVALID? A simple “Not Secure” indicator? The difference matters.
2. Inspect the certificate.
Check the expiration date, issuer, and hostnames covered by the certificate.
3. Test the HTTP redirect.
Run:
curl -I http://example.com
Look for a 301 or another intentional redirect to HTTPS.
4. Test HTTPS directly.
Run:
curl -I https://example.com
Make sure you're getting the response you expect.
5. Check the browser console.
Look for mixed-content warnings and blocked HTTP resources.
6. Check every important hostname.
Don't only test example.com.
Check www, shop, app, api, and any other public subdomain customers actually use.
7. Check the certificate from outside your own network.
A corporate proxy, antivirus product, CDN, or reverse proxy can sometimes change how certificates are presented. Chrome documents cases where HTTPS interception by enterprise proxies causes certificate-authority errors.
8. Set up monitoring once it's fixed.
Because fixing an expired certificate today doesn't stop it expiring again next year.
That's the part most small teams miss.
They fix the incident and go back to normal until the next incident.
A monitoring system should catch the problem before customers do.
If you want a quick external check of your site's security and configuration, you can run a free scan before digging through server settings yourself.
FAQ
Why does my website say Not Secure when I have an SSL certificate?
Having a certificate installed isn't enough. The certificate can be expired, issued for the wrong hostname, untrusted, or the page can still load resources over HTTP.
How do I fix a Not Secure website?
First identify the exact browser error. Then check the certificate, HTTP-to-HTTPS redirect, mixed content, hostname coverage, and TLS configuration. Don't replace the certificate until you know which part is actually failing.
How do I know if my SSL certificate is working?
Open the HTTPS version of your site and inspect the certificate details in your browser. You can also run curl -I https://yourdomain.com from a terminal and use an external TLS checker to inspect the certificate and server configuration.
If your site is showing “Not Secure” today, open it in Chrome, check the exact error, and run curl -I https://yourdomain.com before changing anything.