Why Chrome Still Shows "Not Secure" After You Installed SSL (2026)
Installing an SSL certificate doesn't automatically make Chrome show the padlock. The certificate is only one piece — Chrome also requires that the page is accessed via HTTPS (not HTTP), that no resources load over HTTP (mixed content), and that the certificate chain is valid. If any of these fail, the "Not Secure" warning remains.
Why Does This Happen Even After a Successful Certificate Installation?
Chrome's security indicator isn't just "does a valid certificate exist" — it evaluates the full page load. A perfectly valid certificate installed on the server does not guarantee a secure page if the browser also loads even one resource (an image, script, or stylesheet) over plain HTTP, or if the page itself is still reachable and being viewed over HTTP because no redirect exists.
1. No server-side HTTP → HTTPS redirect
The certificate works fine when a visitor manually types https://, but typing the bare domain or clicking an old HTTP link still loads the insecure version, because nothing at the server tells the browser to upgrade the connection. Fix: add a 301 redirect at the web server level (see our HTTP to HTTPS redirect guide) — not a client-side JavaScript or meta-refresh redirect, which still briefly serves the insecure page first.
2. Mixed content
The page itself loads over HTTPS, but it references at least one resource — an image, a stylesheet, a script, an iframe — via a hardcoded http:// URL. Chrome blocks "active" mixed content (scripts, stylesheets) outright and shows "Not Secure" for "passive" mixed content (images) that still loads. Check DevTools → Console for explicit mixed-content warnings listing the exact offending URL.
3. Missing intermediate certificate
The end-entity certificate is valid, but the server isn't sending the required intermediate certificate(s) to complete the chain to a trusted root. Desktop Chrome sometimes tolerates this (cached intermediates or AIA fetching), but it's inconsistent — some clients will show a trust error instead of "Not Secure," and mobile/API clients often fail outright. See our certificate chain guide.
4. Browser or OS cached the old HTTP state
HSTS preload lists, cached redirects, or a cached "insecure" flag from a previous visit can persist even after the server-side fix is live. Force a hard reload (Ctrl+Shift+R / Cmd+Shift+R) or clear the site's cached data in chrome://settings/content/all before assuming the fix didn't work.
5. CDN or proxy terminating TLS incorrectly
If a CDN or reverse proxy sits in front of your origin server, the certificate the browser sees is the CDN's edge certificate — but if the connection from the CDN back to your origin is unencrypted or misconfigured, some CDNs will still surface warnings, and any origin-to-CDN mixed content gets baked into what's served to the browser regardless of the edge certificate being fine.
Diagnostic Checklist
Run the full diagnostic in one click
Our SSL Checker verifies your chain, and the Redirect Checker confirms HTTP is properly upgraded to HTTPS.