“Your Connection Is Not Private”: What It Means and How to Fix It

A full-page warning, a red padlock, and the words “Your connection is not private”. If it is your own website, it is costing you visitors right now — most people will not click past that screen, and they should not have to.

The good news is that the message is specific if you know how to read it. The browser tells you exactly which check failed; it just does so in a code buried under a “Advanced” link.

Read the error code first

Click “Advanced” on the warning page and you will find a code. It narrows the problem from “something is wrong with SSL” to one specific cause.

If every site shows the warning, it is your device

Certificates are valid between two dates, so a wrong clock makes a perfectly good certificate look expired or not yet valid. This is the single most common cause when the problem follows you from site to site.

• Check the date and time first. On Windows, Settings → Time & Language, and switch on “Set time automatically”. On a Mac, System Settings → General → Date & Time. A clock that is out by even a day will do it.
• Try a private window. This rules out an extension or a cached certificate.
• Try a different network. Public and hotel Wi-Fi often intercept connections at a captive portal, which produces exactly this warning.
• Pause a VPN or antivirus that inspects HTTPS. Several security products insert themselves into encrypted connections and can break the chain.

Never click through the warning to enter a password or card details. On your own router’s admin page it is reasonable; on anything handling real data it is not.

If it is your own site, here is what each cause looks like

The certificate expired

By far the most common. Most certificates now last 90 days and renew automatically — which is exactly why they catch people out. Auto-renewal fails silently for ordinary reasons: a cron job stopped, a firewall rule blocked the validation request, or the domain moved and the challenge no longer resolves.

The trap is that renewal and installation are two separate things. A certificate can renew successfully and still not be the one your server is handing out, because the web server was never reloaded. If your checker still shows the old expiry date after a successful renewal, reload nginx or Apache.

The certificate does not cover the address

A certificate issued for example.com does not automatically cover www.example.com, and neither covers shop.example.com. Each name has to be listed on the certificate, or you need a wildcard.

This usually appears after adding a subdomain, or when visitors reach you on the www version while the certificate only names the bare domain. Issue a certificate covering both, and redirect one to the other so there is a single canonical address.

The chain is incomplete

The most confusing failure, because it often works in your browser and fails for everyone else.

Certificates are trusted through a chain: yours is signed by an intermediate, which is signed by a root your device already trusts. Your server must send the intermediate along with your certificate. Desktop browsers frequently have the intermediate cached from another site and fill the gap silently — so it looks fine to you and breaks on a colleague’s phone or in an API call.

If the site works for you but not for others, this is almost always why. Install the full chain file your certificate authority provided, not just the certificate itself.

Mixed content: padlock gone, no warning page

Slightly different symptom. The page loads but the padlock is missing or struck through, because an image, script or stylesheet is still being requested over http://. Browsers will often block those resources outright, which is why a site can look broken immediately after moving to HTTPS. Fix the asset URLs rather than disabling the warning.

Where the warning appears in each browser

The underlying problem is identical everywhere, but the wording and the route to the detail differ enough to be confusing when you are following instructions written for a different browser.

Chrome and Edge

“Your connection is not private”, with the NET::ERR_CERT_ code shown immediately under it. Click Advanced for the proceed link. To inspect the certificate itself, click the icon to the left of the address, then Connection is not secure → Certificate is not valid, which opens the full detail including the validity dates and the issuer.

Firefox

“Warning: Potential Security Risk Ahead”, and the codes are different — SEC_ERROR_EXPIRED_CERTIFICATE or SSL_ERROR_BAD_CERT_DOMAIN rather than the Chrome equivalents. Firefox is worth keeping around for one specific reason: it maintains its own certificate store rather than using the operating system’s. If a site fails in Firefox but works in Chrome, that often points at a chain problem Chrome is papering over.

Safari

“This Connection Is Not Private”, with noticeably less detail than the others. Safari leans on the macOS and iOS trust store, so a certificate that fails only in Safari is frequently a chain or trust issue rather than an expiry.

On a phone

Mobile browsers show the least information, which makes diagnosis hard on the device itself. If a site warns on a phone but loads on a desktop, suspect an incomplete chain before anything else — desktop browsers often have the missing intermediate cached from another site, and phones usually do not. Checking the domain with an external tool is far quicker than trying to read certificate details on a small screen.

How to check a certificate without a browser

If you have terminal access, one command gives you the dates straight from the server:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

The -servername flag matters on shared hosting: without it the server does not know which site you are asking about and may hand back a different certificate entirely, which produces a confusing mismatch that is not really there. Running this from a different machine than the web server is also the quickest way to confirm whether a chain problem is real or just your own cached intermediate.

Stopping it happening again

• Watch the expiry date, not the renewal job. The job can report success while the server keeps serving the old certificate. Check what the server actually presents.
• Reload the web server after renewal. Put it in the renewal hook so it is never forgotten.
• Cover every hostname you use. Bare domain, www, and any subdomain that faces the public.
• Test from outside your own browser, which may be hiding a chain problem with a cached intermediate.
• Check before a launch or a campaign, not after traffic arrives.

Why it matters beyond the warning screen

An expired certificate does not just look unprofessional. Browsers block the page outright rather than showing a small icon, so for most visitors the site is simply down. Search engines cannot crawl it. Any API or webhook pointed at the domain starts failing, usually without a clear error, because most HTTP libraries refuse an invalid certificate by default and report it as a connection problem.

So a lapsed certificate tends to surface as several unrelated-looking problems at once: traffic drops, integrations break, and forms stop submitting. Checking the expiry date is a thirty-second job that explains all of them.

A quick checklist

1. Does the problem happen on other sites too? If yes, check your device clock first.
2. Click “Advanced” and read the error code.
3. Run the domain through a checker to see the real expiry date, issuer and chain.
4. If expired, renew — then reload the web server and verify what it now serves.
5. If it is a name mismatch, reissue covering every hostname you use.
6. If it works for you but not others, install the full chain.
7. Re-check from outside your own browser to confirm.