“Your Connection Is Not Private” Error: How to Fix It

The headline never changes. The error code sitting underneath Chrome’s Advanced button does. That code is the only part of the page telling you whether to fix your own device or wait for the site owner. Most guides skip straight to “clear your cache.” Read the code first instead.

Quick answer: Check your device clock. A clock that’s wrong by more than a few hours makes every certificate on the web look invalid, and it’s a 30-second fix. If the clock is right and only one site throws the warning, the problem is that site’s certificate. It has expired, doesn’t cover the address you typed, or is missing part of its chain. Nothing you change in your browser will fix that one.

Last reviewed: Error codes, browser behavior and certificate rule changes verified against Chrome, Mozilla, Let’s Encrypt and CA/Browser Forum sources this month.

Fix It in Five Steps

In a hurry? Work down this list in order. Most people are back on the site before step four.

• Step 1. Check your clock. A wrong date breaks every certificate on the web at once.
• Step 2. Read the code. Click Advanced. The NET::ERR line names the real failure, and each code points somewhere different.
• Step 3. Try another device. Load the same address on your phone over mobile data, with Wi-Fi off.
• Step 4. Rule out your software. Switch off HTTPS scanning in your antivirus, then retest in a private window.
• Step 5. Still broken everywhere? Then it’s the site’s certificate, and owners should jump to the fixes below.

How We Checked This

Two tests decided what made it into this guide. A step had to change something the browser actually checks during the TLS handshake. Or it had to narrow the cause down far enough to tell you who fixes it. Everything else got cut. That’s why you won’t find “restart your router” here, and why cache clearing appears with a warning attached rather than as step one.

Sources were ranked in a fixed order. First the people who write the rules, then the people who write the browsers, then the certificate authority behind most affected sites. Validity limits come from the CA/Browser Forum ballot text. Browser behavior comes from Google’s and Mozilla’s own security announcements. Renewal policy comes from Let’s Encrypt’s change log. Vendor blogs and forum threads were read to spot recurring patterns, never used as the source of a number or a date.

Two limits, stated plainly. We didn’t run synthetic tests across every browser build and operating system pairing. The exact wording on your screen may differ by a version or two. And we left out permanent bypasses such as flag-based origin whitelisting in Chrome. Those work. They also convert a temporary warning into a permanent hole, on every site, forever.

What the Warning Actually Means

Your browser refused to finish an encrypted connection. That’s the entire message. It isn’t a virus alert, and it doesn’t mean someone is attacking you right now.

Here’s what happened in the split second before the page failed. Your browser opened a TLS handshake, the short negotiation where the server proves its identity and both sides agree on encryption. The server sent back a certificate. Your browser then ran three checks on it. Is today’s date inside the certificate’s validity window? Does the certificate cover the exact hostname you typed? And does it chain back to a root your device already trusts? Fail any one of the three and you get the warning page. There’s no partial credit.

The date check causes most of the confusion, because it uses your device’s clock as its reference point. Your browser has no independent sense of what time it is. Set a laptop to 2019 and every certificate on the internet becomes invalid at once, because none of them existed yet.

Worth knowing where the modern web sits: more than 95% of pages loaded in Chrome now arrive over HTTPS. That’s why Google is changing Chrome’s defaults. Chrome 147 turned on “Always Use Secure Connections” for Enhanced Safe Browsing users in April 2026. Google has scheduled Chrome 154 to extend that default to every user in October 2026. Careful here: that’s a separate warning page for sites with no certificate at all. Same anxiety, different problem.

Read the Error Code First

Chrome prints the code at the bottom of the warning and repeats it after you click Advanced. Firefox, Edge, Brave and Opera use their own labels for identical failures. Here’s what each one is telling you.

• NET::ERR_CERT_DATE_INVALID: today’s date falls outside the certificate’s validity window. Two very different causes: the certificate expired, or your clock is wrong. Chrome usually separates them for you. When it can tell the device is at fault, it swaps in a page headed “Your clock is ahead” or “Your clock is behind”.
• NET::ERR_CERT_AUTHORITY_INVALID: the chain doesn’t reach a root your device trusts. Self-signed certificate, missing intermediate, or security software re-signing your traffic. Firefox calls the same failure SEC_ERROR_UNKNOWN_ISSUER, Edge shows DLG_FLAGS_INVALID_CA.
• NET::ERR_CERT_COMMON_NAME_INVALID: the certificate is valid, just not for the address you asked for. The hostname isn’t in the certificate’s SAN list (Subject Alternative Name, the list of hostnames one certificate covers). The everyday version of this is a certificate that covers example.com while you typed www.example.com.
• NET::ERR_CERT_REVOKED: the certificate authority pulled this certificate before its expiry date, usually after a key compromise or a validation problem. Always the site’s job.
• NET::ERR_CERT_VALIDITY_TOO_LONG: the certificate was issued for longer than the current rules permit. Rare, and always upstream of you.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED: the certificate arrived without enough proof that it was logged in public certificate transparency logs. Chrome requires two signed timestamps for certificates valid 180 days or less, three for longer ones, from at least two log operators.
• MOZILLA_PKIX_ERROR_MITM_DETECTED: Firefox has worked out that something on your own machine is intercepting encrypted traffic. Nearly always antivirus HTTPS scanning.

Three of those seven can point back at your own machine: the date code, the authority code, and Firefox’s MITM code. The other four belong to the site. That single split saves you from trying visitor fixes on a server problem, which is where most wasted hours go.

Which Side Is Broken: A 60-Second Test

Before touching any setting, work out which side of the connection is at fault. Three questions get you there faster than any fix.

Every site, or just one? Every site means your device. A clock that’s drifted, a security product intercepting traffic, or a damaged root store. One site means that site, unless your browser is holding a stale HSTS entry or an extension is interfering.

Does it happen on other devices? This is the sharpest test available and it takes 20 seconds. Turn Wi-Fi off on your phone, load the same address over mobile data. Different device, different network, different operating system. Still broken? The certificate is broken, and no amount of cache clearing on your laptop will change that.

Are you on public Wi-Fi? Airports, hotels and cafes run captive portals that intercept your first request to make you accept terms or pay. Chrome often recognizes this. It replaces the certificate warning with a page reading “Connect to Wi-Fi”, telling you the network may want a login first. Sign in to the network first, then reload. Nothing is wrong with the site.

Fixes When the Problem Is Your Device

Fix the clock, and check the year while you’re there

Certificate dates are validated in UTC, so a wrong time zone by itself rarely triggers this. A wrong date does, instantly and on every site.

• Windows 11: Settings, then Time & language, then Date & time. Switch on Set time automatically and click Sync now.
• If sync fails: open Command Prompt as administrator and run w32tm /resync. The reply “The computer didn’t resync because no time data was available” usually means UDP port 123 is blocked on your firewall or network.
• macOS: System Settings, General, Date & Time, then enable Set time and date automatically.
• iPhone and Android: Settings, then Date & time, then Set automatically. Phones drift after a flight or a SIM swap more often than people expect.

One cause people miss entirely: a desktop PC with a dead CMOS battery. It resets its clock at every power cut, often to a date years in the past. Does the warning return each morning and vanish after a manual sync? That’s a hardware battery worth about USD 2, not a browser problem.

Test in a private window, then read the result properly

Open the same URL in an incognito or private window. This isn’t a fix, it’s a diagnostic, and the outcome tells you a lot. If the page loads cleanly, an extension or stored browser state is involved. If it fails identically, the problem sits below your browser profile: the clock, the system root store, or the site itself.

Turn off HTTPS scanning in your security software

Norton, Bitdefender, Kaspersky, ESET, Avast, AVG and Sophos all ship a feature that inspects encrypted traffic. It works by installing its own root certificate on your machine, decrypting every HTTPS connection, then re-signing it before your browser sees it. When that root isn’t properly trusted, or the product updates badly, every site starts throwing authority errors. Firefox names the culprit outright with MOZILLA_PKIX_ERROR_MITM_DETECTED.

The fix is to disable the HTTPS or SSL scanning feature specifically, not to uninstall your antivirus. In most products it sits under web protection or web shield settings. Reload the site afterwards. If the warning disappears, you’ve found it.

Clear the right thing, which usually isn’t your cache

Cached pages and cookies rarely cause certificate errors, despite being the internet’s favorite advice. What does cause them is stale HSTS state. That’s a stored instruction telling Chrome to use HTTPS for a domain and to refuse any exception.

Open chrome://net-internals/#hsts, scroll to “Delete domain security policies”, enter the affected domain, and delete. Do it for the one domain giving you trouble, not as routine housekeeping. Then reload. If you want to clear cookies too, use chrome://settings/clearBrowserData, but treat that as a second step rather than a first.

VPNs, custom DNS and corporate networks

A VPN that routes DNS through its own resolvers can land you on a different server than the certificate expects. Turn it off and reload before assuming the site is down. On a work laptop, TLS inspection is often company policy, with the corporate root installed by IT. In that case the warning means something in that setup broke, and your help desk owns the fix.

Should You Click “Proceed to Site (Unsafe)”?

Click Advanced and Chrome offers you a link to continue anyway. Sometimes that’s fine. Often it isn’t, and the honest answer depends on what you’re about to do on the page.

The reason to hesitate is specific. Your browser can’t distinguish between a certificate that expired last Tuesday and an active interception of your traffic. Both fail the same checks, both produce the same page. When you click through, you’re accepting that ambiguity on the site’s behalf.

A workable rule: never proceed on anything involving a password, a payment, or personal data. Banking, email, checkout, admin panels. Proceeding on your own development server with a self-signed certificate is a different matter entirely, and that’s what the option exists for.

No Advanced or Proceed option at all? That’s HSTS doing its job. The site told your browser, in advance, never to allow an exception. Clear the entry from chrome://net-internals/#hsts if the site is yours and you know why it’s failing. You’ll also see people recommending you type thisisunsafe on the warning page. It’s a bypass, not a repair, it doesn’t work on HSTS-preloaded domains, and it leaves the underlying problem exactly where it was.

Fixes When the Problem Is Your Site

If visitors are hitting this page, you’re losing nearly all of them at the door. Work through these in order.

Step one: look at what you’re actually serving

Click the icon to the left of the address bar, then “Connection is secure”, then “Certificate is valid” to open the certificate viewer. Check three fields: Issued to, Issued by, and the validity dates. That takes ten seconds and settles the expiry question outright.

From a terminal, run openssl s_client -connect example.com:443 -servername example.com -showcerts. The -servername flag matters more than it looks. Without it, a server hosting several sites on one IP address hands back its default certificate, and you end up debugging the wrong one. For an outside opinion including chain and protocol issues, run the free Qualys SSL Labs server test.

Cause 1: it expired, and nobody emailed you

Let’s Encrypt stopped sending certificate expiration warning emails on 4 June 2025. That service had been the last safety net for thousands of manually renewed sites. Read that date again if you run a site whose certificate renewal isn’t automated. The Let’s Encrypt announcement points subscribers to third-party monitoring instead, naming Red Sift Certificates Lite as a free option covering up to 250 certificates.

Renew the certificate, then immediately confirm why the renewal didn’t happen on its own. One trap to rule out: if the certificate viewer still shows the old expiry date after a successful renewal, your web server never reloaded. An expired certificate is a symptom. Broken automation is the disease, and it will produce this page again in a few months. Not sure where your certificates should come from? Our breakdown of free and paid SSL certificate providers covers which ones support automated issue and renewal.

Cause 2: the certificate doesn’t cover that hostname

A certificate for example.com does not automatically cover www.example.com. They’re separate hostnames, and both must appear in the SAN list. Same story for shop.example.com, mail.example.com and any other subdomain.

Reissue the certificate covering every hostname visitors can reach, then confirm your redirects send traffic to the one canonical version. On cPanel, AutoSSL covers the domains whose DNS actually resolves to that server. A subdomain pointed somewhere else drops out of coverage without warning.

Cause 3: the chain is incomplete

Your server has to send the intermediate certificate alongside your own. Miss it and some visitors see an authority error while you see nothing wrong. The classic version of this mistake is pointing Nginx at cert.pem instead of fullchain.pem.

Browsers paper over this inconsistently, which is what makes it so confusing to diagnose. Chrome’s certificate verifier will try to fetch a missing intermediate on its own. It uses the certificate’s AIA field (Authority Information Access, a pointer to where the issuer’s certificate lives). Firefox takes a different route. Mozilla preloads known intermediate certificates into the browser through its Remote Settings infrastructure, a feature introduced in Firefox 68. The goal was cutting unknown-issuer errors caused by misconfigured servers. So here’s your tell: when a site fails in one browser and loads in another, suspect the chain before you suspect the certificate.

Cause 4: a CDN or proxy sits in front

Cloudflare error 526 means Cloudflare completed a connection to your origin server and then rejected its certificate as expired, self-signed, or wrong for the hostname. It fires when your zone is set to Full (strict), which is the mode you want.

The common mistake is dropping the mode from Full (strict) down to Full to make the error disappear. That doesn’t repair anything. It tells Cloudflare to stop validating your origin certificate at all, so the leg between Cloudflare and your server stays encrypted but unauthenticated. Install a Cloudflare Origin CA certificate on the origin and keep strict validation switched on. Flexible mode deserves its own warning. It shows visitors a padlock while talking plain HTTP to your server, and it reliably produces redirect loops. Our illustrated Cloudflare setup guide for WordPress walks through the correct mode during setup.

Cause 5: renewal is failing quietly in the background

Automated renewal fails silently far more often than it fails loudly. Five causes account for most cases:

• A CAA DNS record that doesn’t list the certificate authority you’re using, which blocks issuance outright.
• Port 80 closed as a hardening measure. HTTP validation still needs it, even on a site that forces HTTPS everywhere.
• A forced HTTPS redirect catching the validation request before it reaches /.well-known/acme-challenge.
• A CDN or proxy answering the validation request instead of your server.
• One subdomain whose DNS no longer points at the server. A single failing hostname can block renewal for the entire certificate.

Check your renewal logs rather than guessing. On cPanel that’s the AutoSSL history in WHM, which records exactly which domain failed validation and why.

One thing this error is not: mixed content

If your page loads but shows “Not secure” in the address bar, that’s mixed content, meaning HTTPS pages pulling images or scripts over HTTP. Related topic, different symptom, and no full-page interstitial. Don’t spend an afternoon reissuing certificates over a hardcoded http:// image URL.

The Renewal Math That Will Break Sites in 2027

Here’s a calculation worth doing today, because it explains a wave of expired certificates arriving next year.

Right now the default Let’s Encrypt certificate lasts 90 days, and the standard advice has long been a renewal job every 60. That leaves 30 days of slack. Three consecutive failed renewals and your site is still online, still trusted, still fine.

That margin is about to shrink. Let’s Encrypt has published a schedule taking default certificate lifetimes from 90 days down to 45. Its first milestone has already landed: Let’s Encrypt’s opt-in tlsserver profile switched to 45-day certificates on 13 May 2026. The default moves next. On 10 February 2027 Let’s Encrypt’s classic profile starts issuing 64-day certificates. Run the same hardcoded 60-day job against a 64-day certificate and your slack drops from 30 days to 4. One missed run, one expired API token, one server reboot at the wrong moment, and visitors get the warning page.

Thirty days of margin becomes four. That’s the whole story, and it’s why Let’s Encrypt now tells subscribers that renewing at a fixed interval is no longer sufficient. Switch to ARI (ACME Renewal Information), where the certificate authority tells your renewal software when to renew instead of you deciding in advance. Certbot and most current ACME clients already support it. ACME is the protocol your server uses to request and renew certificates automatically.

The industry-wide limits move in the same direction. Since 15 March 2026 the maximum life of any publicly trusted TLS certificate has been 200 days, down from 398. That schedule comes from CA/Browser Forum ballot SC-081v3, and it drops to 100 days in 2027, then 47 in 2029. Do the subtraction on the old habit of an annual calendar reminder. Against a 200-day certificate, it now fires 165 days after the certificate already expired.

How to Stop It Coming Back

Match your situation to one of these four. Each one has a different answer, and picking the wrong one wastes weeks.

Shared cPanel hosting, no terminal. One WordPress site, everything through the control panel. Leave AutoSSL enabled, keep port 80 open, and check your CAA record lists the authority your host uses. Then set a calendar reminder every 60 days to open your own site in a private window and look at the padlock. Manual, unglamorous, and it catches the failure while you still have weeks of runway.

A VPS with certbot in cron. Move off fixed-interval renewal to ARI-driven renewal now rather than in February 2027. While you’re in there, confirm your reload hook actually restarts the web server. A renewed certificate sitting on disk that Nginx never reloaded still serves the old expired one to every visitor.

Agency with 20+ client sites. Per-site cron jobs won’t scale, and you’ll find out which one broke from an angry client. Use external certificate monitoring that alerts on expiry from outside your infrastructure. Let’s Encrypt names Red Sift Certificates Lite, free for up to 250 certificates, which covers most agency portfolios without a line item.

Budget above USD 15/month. No appetite for any of this? Buy the problem away. Managed platforms handle issuance, renewal and reload hooks as part of the service. Our guides to managed hosting providers and hosts with the strongest built-in security compare who includes that, and who charges extra. Below that budget, run your own automation and accept that monitoring it is part of the job.

Frequently Asked Questions

Is it safe to click “Proceed to site (unsafe)”?

It depends entirely on what you do next. Your browser can’t tell an expired certificate apart from an active interception, so clicking through means accepting that uncertainty yourself. Never proceed on a login page, a checkout, or anything handling personal data. Reading a static article on a site whose certificate lapsed yesterday carries far less risk. And your own development box with a self-signed certificate is exactly what the option is for.

Why does “your connection is not private” appear on every website I open?

Because the fault is on your device, not on any of those sites. In order of likelihood: your system clock is wrong, or your antivirus is intercepting HTTPS traffic with an untrusted root certificate. The third option is a public Wi-Fi captive portal you haven’t signed into yet. Fix the clock first, since it takes 30 seconds and explains most cases where every site fails at once.

How do I fix it when there’s no Advanced or Proceed option?

That’s HSTS, a policy the site set in advance telling browsers never to allow an exception for it. Chrome is doing what it was told. If the site is yours, open chrome://net-internals/#hsts, use “Delete domain security policies” on that domain, and reload. If the site isn’t yours, there’s no browser-side fix and there shouldn’t be. Contact the site owner or wait for them to renew.

Does an expired SSL certificate hurt my Google rankings?

Google has said HTTPS is a lightweight ranking factor, and that it isn’t a requirement for indexing. The direct ranking effect is smaller than most SEO advice implies. The traffic damage is the real cost. Every visitor from search hits a full-page interstitial before your content renders, and the overwhelming majority leave. Treat it as a conversion emergency rather than a ranking one, and fix it within hours.

Why does the site load on my phone but not on my laptop?

Two devices, two different trust stores and two different sets of installed software. The usual culprits on the laptop are antivirus HTTPS scanning, a browser extension, a stale HSTS entry, or a clock that’s drifted. Your phone has none of those. If your phone loads the site over mobile data and your laptop doesn’t, stop investigating the site. Start with the laptop’s clock and its security software.

Will clearing my cache fix this?

Usually not, and it’s the most over-prescribed step in every guide on this topic. Cached pages and cookies don’t fail certificate validation. Stored HSTS entries and locally trusted root certificates do. Clearing your cache is harmless, and skipping to the clock check, the private-window test, and the HSTS deletion will save you time.

Can a VPN cause this error?

Yes, in two ways. Some VPNs resolve DNS through their own servers and send you to a different endpoint than the certificate was issued for. Others inspect traffic in a way that resembles interception. Disconnect the VPN and reload as a diagnostic. If the page loads clean without it, the VPN is your answer, and switching its DNS or protocol settings usually clears it.

Bottom Line

This error has exactly two owners, and the code under the Advanced button tells you which one you’re dealing with in about five seconds. Wrong on every site means your machine, and the clock is where you start. Wrong on one site across two devices and two networks means the certificate, and no browser setting will touch it.

For site owners, the deadline is already on the calendar. Certificate lifetimes are shrinking on a fixed schedule that ends at 47 days in 2029. Let’s Encrypt stopped emailing expiry warnings back on 4 June 2025. Nobody is coming to remind you. Automate renewal properly, monitor it from outside your own server, and this page becomes something that only ever happens to other people.

Once you’ve fixed the certificate, the next question is usually whether your current host is making this harder than it needs to be. Our hosting finder tool filters providers by what they actually include. Was a proxy layer behind your error? The guide to CDN hosting options explains how the edge certificate and the origin certificate work together.