That "Your connection is not private" warning is telling you something real. Here's what each SSL warning means, which ones you can safely dismiss, and which ones mean you should stop immediately.
You've seen it. You're browsing a site, about to enter a password or a credit card number, and your browser flashes a red warning: "Your connection is not private." Most people click through it. Most people shouldn't.
SSL certificate warnings are not browser quirks. They're security signals. The problem is that browsers have made clicking through warnings so easy that users treat them as obstacles rather than alerts. This article explains what the warnings actually mean, which ones you should take seriously, and how to fix them on your own sites.
When you connect to a site over HTTPS, your browser and the server perform a handshake. Part of that handshake involves the server presenting a digital certificate — a file that proves "this server is who it claims to be." The certificate is signed by a Certificate Authority (CA), a trusted third party that verifies the server's identity before issuing the certificate.
If anything in this chain breaks — expired certificate, wrong domain, untrusted CA, tampered content — the browser shows a warning. The warning isn't the problem; it's the symptom. Something in the identity chain failed, which means you can't be certain who you're actually talking to.
High Risk — This means the browser couldn't verify the server's identity at all. The certificate might be expired, self-signed (not issued by a trusted CA), or for a different domain. If you enter a password or personal data here, it's potentially visible to whoever is watching the connection — a man-in-the-middle attacker on the same network, for instance.
What to do: Don't enter sensitive information. Close the tab. If you own the site, check the certificate status immediately.
Medium Risk — The certificate was issued for www.example.com but you're at api.example.com, or the certificate has been issued to a different organization entirely. This often happens in internal environments where internal apps use certificates issued to hostnames that don't match the URL being accessed.
It might be legitimate — a dev environment with a self-signed cert, or an internal tool — but it might also be a phishing site using a stolen certificate or a lookalike domain with a fraudulently obtained cert.
Medium Risk — Certificates are issued for a fixed period, typically 90 days to a year. When they expire, the server still accepts connections, but the browser warns because an expired certificate hasn't been re-verified by the CA. Expired certificates often indicate neglect — if the admin forgot to renew the cert, what else did they forget?
Let’s Encrypt has made certificate renewal nearly automatic. There's no excuse for expired certs on public-facing sites in 2026.
Medium Risk — The page loaded over HTTPS but some assets (images, scripts, CSS) are being loaded over plain HTTP. This is called mixed content. The page looks secure, but the HTTP resources can be intercepted or modified. If the insecure resource is a JavaScript file, an attacker can inject malicious code into the page.
This one is subtle and common. A site can have a valid HTTPS certificate but still be serving malware through an HTTP asset. Check your browser developer tools — the console will show mixed content warnings.
High Risk — The browser has detected something that looks like a proxy or SSL-bumping intercept in the connection chain. This is sometimes legitimate — corporate security proxies do this to inspect encrypted traffic. But it's also how attackers intercept HTTPS sessions on compromised networks.
If you see this on a site you control and you don't run a proxy, someone may be performing a MITM attack against your users.
Users have been conditioned to click through SSL warnings. That's by design — browsers made "proceed anyway" easy because sometimes there's a legitimate reason. But this conditioning is actively dangerous. Here are the real attack patterns:
Don't wait for a customer to tell you your cert is expired. Use a monitoring service or set up automated renewal with Let's Encrypt via Certbot. For wildcard certs, ensure the renewal process includes all subdomains.
Run your site through a mixed content scanner. The easiest fix is to force all resources to load over HTTPS — set your Content-Security-Policy header to upgrade-insecure-requests. This automatically upgrades HTTP resource requests to HTTPS.
HSTS tells the browser to only ever connect to your site over HTTPS. Once set, the browser will refuse to make HTTP connections — no downgrade attacks possible. Set it with: Strict-Transport-Security: max-age=31536000; includeSubDomains
HSTS preload lists are maintained by browser vendors. Submitting your domain means browsers will refuse HTTP connections before ever visiting your site — maximum protection. Submit at hstspreload.org.
Use SSL Labs' free test at ssllabs.com/ssltest to get a full grade and breakdown of your TLS configuration. It checks certificate chain, protocol support, cipher strength, and more.
EdgeIQ tracks certificate expiration, mixed content, and TLS configuration issues across all your public-facing properties — so you fix problems before users see warnings.
View plans →