How to Fix ‘Your Connection Is Not Private’ Error

This error appears when a browser tries to open a site over HTTPS but cannot verify the site’s SSL certificate. The browser refuses to establish a secure connection and shows a red warning instead, because any data exchanged over an unverified connection could be intercepted.

The exact wording changes by browser, and the small grey error code underneath the warning is your most useful clue:

• Chrome, Edge and Brave: “Your connection is not private” with codes such as NET::ERR_CERT_DATE_INVALID (expired or future-dated certificate), NET::ERR_CERT_AUTHORITY_INVALID (certificate from an untrusted issuer), NET::ERR_CERT_COMMON_NAME_INVALID (certificate hostname does not match), ERR_SSL_VERSION_OR_CIPHER_MISMATCH (server uses an outdated TLS version or cipher that Chrome has disabled), or NET::ERR_SSL_PROTOCOL_ERROR (generic SSL negotiation failure, often caused by a CDN misconfiguration).
• Safari: “This Connection Is Not Private,” usually shown when the certificate has expired or the domain on the certificate does not match the site you are visiting.
• Firefox: “Warning: Potential Security Risk Ahead” with codes like SEC_ERROR_UNKNOWN_ISSUER or MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT.

For brochure-style sites the warning is mostly a trust problem; most visitors will leave the moment they see it. For sites with login forms, contact forms, or a checkout, the browser will refuse to send any data, so the page is effectively unusable until the certificate problem is fixed.

The cause sits in one of two places, and it helps to know which before you start fixing:

• Visitor-side: a wrong system clock, an outdated browser, an aggressive antivirus, a public Wi-Fi captive portal, or a stale cached certificate on the visitor’s machine.
• Site-side: the SSL certificate has expired, was issued for the wrong hostname (for example covering example.com but not www.example.com), is self-signed, or is not installed correctly on the server or CDN.

The seven steps below start with the quickest visitor-side checks and then move into the WordPress and server-side fixes site owners need.

Start with the simplest fix: a hard reload. Browsers cache certificate handshakes, and a stale cached response is a surprisingly common cause of the warning even after the underlying problem is fixed. Close the tab, open a new one, and try the URL again. If that does not help, do a hard reload that bypasses the cache, Ctrl + F5 on Windows or Cmd + Shift + R on macOS. If you are testing your own WordPress site after installing a new SSL certificate, also clear any caching plugin (W3 Total Cache, WP Rocket, LiteSpeed Cache) and your CDN cache before reloading, otherwise the cached page can keep serving the old certificate response.

Open the same URL in a second browser or a second device on the same network. If the warning appears everywhere, the issue is on the website. If it shows up in only one browser, the problem is local, usually a stale cached certificate, a corrupted browser profile, or a browser extension intercepting traffic (this is common with antivirus and parental-control extensions). On mobile, try switching from Wi-Fi to cellular data: a captive portal on a hotel or airport network often serves its own login certificate and triggers the same warning even on sites that are perfectly configured.

Clear the browser cache and any saved SSL state. In Chrome and Edge, go to Settings → Privacy → Clear browsing data and tick “Cached images and files” plus “Cookies and other site data” for the last 24 hours. To purge stale certificates more directly on Windows, open Internet Options → Content → Clear SSL state. On macOS, deleting the cached certificate for the site from Keychain Access can also resolve mismatches. Reload the page after clearing, if the SSL was reissued recently, it should now validate cleanly without you needing to touch any other setting.

SSL certificates carry a “valid from” and “valid to” date. If your computer’s clock is wrong by more than a few hours, common after a battery swap, a long flight, or a fresh OS install, the browser will believe the certificate has not started yet, or has already expired, and throw the warning even on sites that are perfectly healthy. On Windows, right-click the clock and choose “Adjust date/time,” then toggle “Set time automatically” off and back on. On macOS, open System Settings → General → Date & Time and re-enable automatic time. Reload after the clock corrects itself.

Some antivirus products such as Kaspersky, Avast, ESET and BitDefender intercept HTTPS traffic to scan it. They do this by injecting their own certificate into the connection, which the browser does not always trust, especially right after an antivirus update. Temporarily disable HTTPS scanning or the “web shield” feature and reload the page. Do the same with any active VPN, since some VPN providers route traffic through a proxy that mismatches certificates. If the warning disappears, you do not need to remove the tool; just whitelist the affected site or lower its scanning level for that single domain.

If you are not sure which browser extension is causing the issue, go to your browser’s extension settings and disable all extensions at once, then reload the page. If the warning clears, re-enable extensions one at a time to identify the culprit. In Chrome, go to Settings > Extensions (or type chrome://extensions in the address bar) and toggle each one off. Parental control software, corporate security proxies, and ad-blocking extensions with HTTPS inspection enabled are the most frequent offenders.

If you are the site owner, the next step is to confirm the certificate itself is healthy. Click the padlock or “Not Secure” indicator in the address bar → Connection is secure → Certificate is valid, then check the issued-to domain, the expiry date, and the issuing authority. The most common site-side causes are an expired certificate (renew it via Let’s Encrypt or your host), a certificate that covers example.com but not www.example.com (reissue it with both names or add a redirect at the server level), and a certificate chain that is missing intermediate certificates after a server migration.

Run a full SSL diagnosis to catch problems the browser hides. Free tools like SSL Labs and Why No Padlock report misconfigured chains, weak protocols, mixed-content references, and CDN issues your visitors will see but you might not. If you are using Cloudflare or Bunny, make sure your SSL/TLS encryption mode matches your origin certificate. Flexible mode against an HTTPS origin, for example, can produce the warning intermittently for a subset of visitors. WordPress users should also verify that the WordPress Address (URL) and Site Address (URL) under Settings > General both start with https://, since a mismatch here causes the warning on every redirect.

One advanced case to be aware of: if your domain is on the HSTS preload list (check at hstspreload.org), browsers will refuse to load the site over HTTP under any circumstances and will not show a “proceed anyway” bypass option when the certificate has a problem. HSTS preloading is permanent and browser-enforced, so fixing the underlying SSL issue is the only path forward. If you need to remove a domain from the preload list, submit a removal request at hstspreload.org and wait for browsers to pick up the update, which can take several months.