Why browsers show "Not Secure": causes and fixes

A browser shows "Not Secure" when a page is served without valid HTTPS encryption — either because it's loaded over plain HTTP, it mixes HTTP and HTTPS resources, or its TLS certificate is expired, misissued, or doesn't match the domain. The fix is almost always to serve the entire page over HTTPS with a valid, correctly-scoped certificate and no insecure sub-resources.

What actually triggers the warning

The core trigger is simple: any page loaded over plain HTTP instead of HTTPS (HTTP layered over TLS, Transport Layer Security) is unencrypted and unauthenticated, so the browser flags it. Since Chrome 68 in July 2018, Google marks all plain HTTP pages as "Not secure" in the address bar — not just ones with login forms, which was the earlier, narrower policy. Firefox shows a crossed-out padlock for HTTP pages and escalates to a clearer warning when the page has a password field. Safari shows "Not Secure" text next to the address bar, with extra emphasis when there's a text or password input.

Browsers also warn on HTTPS pages when the certificate itself is the problem — expired, self-signed, issued for the wrong hostname, or not properly logged in Certificate Transparency logs (a public record system Chrome requires for trusted certificates). And a third category catches sites that technically use HTTPS but load some resources over HTTP anyway: mixed content.

The four real causes

Cause	What the browser sees	Typical fix
No HTTPS at all	Page served over plain HTTP	Install a certificate, redirect HTTP → HTTPS
Mixed content	HTTPS page loading HTTP scripts/images/iframes	Update hardcoded http:// URLs to https://
Expired certificate	TLS cert past its notAfter date	Renew and reinstall the certificate
Misissued/mismatched certificate	Wrong domain (CN/SAN mismatch), self-signed, or untrusted CA	Reissue for the correct hostname(s) from a trusted CA

Each of these produces a slightly different browser message, but they all stem from the same root idea: the browser can't guarantee the connection is encrypted end-to-end and genuinely belongs to the domain it claims to.

Why "HTTPS but still Not Secure" happens

This is the case that confuses most people, because the site clearly has a padlock or a certificate installed, yet still gets flagged. It's almost always mixed content: the HTML is served over HTTPS, but a stylesheet, script, image, or iframe is hardcoded to http:// instead of https:// or a protocol-relative URL. Browsers block or downgrade those insecure sub-resources rather than trust them. Active mixed content — scripts, iframes, stylesheets, and fetch/XHR requests — is blocked outright, which is why a page can lose its styling or break entirely the moment it moves to HTTPS. Passive content like images and media is usually still loaded, but it's enough to strip the padlock and show "Not Secure."

How to find and fix mixed content

1. Open the browser console (DevTools → Console). Mixed-content warnings name the exact offending http:// URLs.
2. Fix each reference — switch http:// to https:// where the resource supports it, or use a root-relative (/path) or protocol-relative (//host/path) URL so it inherits the page's scheme.
3. Check the usual hiding places — hardcoded links in templates, older CMS content, email and marketing embeds, ad and analytics tags, and third-party widgets.
4. Add a backstop — the Content-Security-Policy: upgrade-insecure-requests header tells the browser to silently rewrite any remaining http:// sub-resource to https://, so one missed URL doesn't break the padlock.

When the certificate is the cause

The most common recurring reason a site goes "Not Secure" isn't a bad build — it's a certificate that lapsed:

• Expired — a manual certificate nobody tracked, or an auto-renewal that quietly failed. Renew and reinstall it, and make renewal automatic (ACME / Let's Encrypt) wherever you can.
• Incomplete chain — the certificate is valid, but the server doesn't send the intermediate, so some browsers and clients reject it. Reinstall the full chain.
• Wrong hostname or untrusted issuer — a self-signed cert, or one issued for example.com while serving www.example.com. Reissue for the exact hostnames (all of them, in the SAN list) from a trusted CA.

Don't wait for a customer to tell you

"Not Secure" is a trust and SEO problem — Google treats HTTPS as a ranking signal, and browsers show the warning to every visitor — but you usually hear about it from a customer, not before. So the real fix is to watch for it. InfraNest discovers every TLS certificate across the domains and servers you connect, tracks each expiry with alerts weeks ahead, grades the configuration A–F, and flags the misconfigurations — a missing intermediate, a wrong hostname, an approaching expiry — before a browser turns the padlock into a warning. Green stays green.