Fixing the “Your Connection Is Not Private” SSL Certificate Error in Every Browser

You open a website you visit every day, and instead of the page Chrome throws up a stark white screen with a red warning triangle: “Your connection is not private”, followed by a cryptic code such as NET::ERR_CERT_DATE_INVALID. Many people panic, assuming a virus infection or a hacked website. In reality, this screen is the browser's normal defense mechanism kicking in after it detected something wrong with the site's SSL certificate. This guide walks through what the error actually means, the codes you will encounter most often, the causes on both the visitor side and the website-owner side, and concrete fixes for each. Unlike our companion article on server-side SSL troubleshooting, this one focuses specifically on the browser error screen itself.

What This Error Actually Means

Before loading any page over HTTPS, the browser performs a TLS handshake. The server must present an SSL/TLS certificate, and the browser validates three things: (1) is the certificate still within its validity period, (2) does the domain name on the certificate match the domain being visited, and (3) was the certificate issued by a Certificate Authority (CA) the browser trusts. If any single check fails, the browser refuses to establish the encrypted connection and shows the full-page warning instead of the website.

The crucial point to understand is that this error does not mean your computer is infected, and it does not necessarily mean the website was hacked. It only means the browser could not confirm that the connection is safe. The root cause may sit on the website, somewhere on the network, or on the visitor's own device. Each browser words it slightly differently: Chrome and Edge say “Your connection is not private”, Firefox says “Warning: Potential Security Risk Ahead”, and Safari says “This Connection Is Not Private”, but the underlying mechanism is identical in all of them.

Common Error Codes and What They Mean

Below the warning text, the browser prints an error code, and that code is your single most valuable diagnostic clue. Match it against this table first.

Notice that the “invalid date” group is the only one where the cause can sit entirely on the visitor's side. The codes about domain names and issuers almost always require a fix on the website.

Visitor-Side Causes and How to Fix Them

If you are the visitor rather than the site owner, work through this checklist in order. It is sorted from most to least common cause.

1. Wrong Date and Time on Your Device

The number-one cause of NET::ERR_CERT_DATE_INVALID is a drifted system clock, because the browser compares the certificate's validity window against your local time. If your machine thinks it is the wrong year, a perfectly valid certificate suddenly looks expired. On Windows go to Settings > Time & Language and enable Set time automatically. On macOS open System Settings > General > Date & Time and enable Set time and date automatically. Do the same on phones by enabling network-provided time. Computers with a failing CMOS battery, or devices that stayed powered off for a long period, drift especially often.

2. Public Wi-Fi With a Captive Portal

Hotel, airport and coffee-shop Wi-Fi networks usually run a login page (captive portal) that intercepts all traffic until you accept the terms. While you are not signed in, the portal answers HTTPS requests with its own certificate instead of the real site's certificate, which instantly triggers the warning. The fix is to open a plain HTTP page such as http://neverssl.com to force the login page to appear, complete the sign-in, and then return to the site you wanted.

3. Antivirus HTTPS Scanning

Some antivirus products ship an HTTPS scanning or SSL inspection feature that inserts itself as a man-in-the-middle: it decrypts your traffic with its own certificate and re-encrypts it. If the product's root certificate is not correctly installed in the browser's trust store, every single website starts throwing NET::ERR_CERT_AUTHORITY_INVALID. Temporarily disable the HTTPS scanning feature and retest. If the warnings disappear, update the antivirus to its latest version or reinstall its certificate following the vendor's documentation.

4. Stale Cache and SSL State

Browsers sometimes remember a previously broken certificate even after the site has fixed it. Clear the browser cache (Ctrl+Shift+Delete, choose Cached images and files). On Windows you can additionally clear the OS-level SSL state under Internet Options > Content > Clear SSL state, then restart the browser. A faster diagnostic trick is to open the site in an Incognito/Private window, which bypasses the existing cache: if the site loads fine there, the culprit is your cache or an extension.

5. Extensions and Corporate Networks

Proxy, VPN and some ad-blocking extensions can interfere with HTTPS connections; disable them one at a time to identify the offender. On corporate machines, IT departments often deploy SSL-inspecting proxies or firewalls, and warnings on certain sites can be expected behavior. In that case only your system administrator can resolve it — there is nothing to fix on the user side.

Website-Owner Causes: the 5 Most Frequent Cases

If multiple visitors report the error at the same time from different devices and networks, assume the problem is on your server. The most common cases, ranked by frequency, are these.

1. Expired Certificate

By far the most common cause, especially on sites where the certificate was installed manually and nobody remembered the renewal date. Let's Encrypt certificates are valid for only 90 days, while paid certificates typically last one year. Check the expiry date by clicking the padlock/tune icon next to the URL and viewing the certificate details, or use the openssl commands below. The permanent cure is automatic renewal — see our SSL renewal guide for the details.

2. Domain Name Does Not Match the Certificate

A certificate explicitly lists the domains it protects in its Common Name and Subject Alternative Name (SAN) fields. If the certificate was issued for example.com but a visitor types www.example.com and that name is not in the SAN list, NET::ERR_CERT_COMMON_NAME_INVALID appears immediately. The fix is to reissue the certificate covering both the www and non-www names, or use a Wildcard certificate for all subdomains. The same thing happens when you point a brand-new subdomain at your server and forget to extend the certificate to cover it.

3. Incomplete Intermediate Chain

Certificates work as a chain: from your site's certificate, through one or more intermediate CA certificates, up to a root CA the browser already trusts. If the server serves only the site certificate without the CA bundle (the intermediates), some browsers cannot assemble the chain and Firefox reports SEC_ERROR_UNKNOWN_ISSUER. The tell-tale symptom is that the site works on some devices but fails on others, because desktop browsers often have the intermediate cached while mobile browsers do not. Read the deep dive in our article on the SSL certificate chain.

4. Self-Signed Certificates

A certificate you sign yourself does encrypt traffic, but it proves nothing about identity, so browsers always flag it with NET::ERR_CERT_AUTHORITY_INVALID. Self-signed certificates belong in internal testing only. Any site open to the public needs a certificate from a trusted CA — either free Let's Encrypt or a commercial certificate such as RapidSSL.

5. Mixed Content and Other Configuration Issues

Even with a perfectly valid certificate, an HTTPS page that loads images, scripts or CSS over plain http:// gets its padlock downgraded to “Not secure” or has those resources blocked. It is not the full-page warning, but it damages trust just as much; our mixed content guide shows how to hunt these down. Likewise, leaving only obsolete TLS versions (1.0/1.1) enabled can make modern browsers refuse the connection with ERR_SSL_PROTOCOL_ERROR.

Fixing It as a Site Owner on DirectAdmin

For hosting accounts that come with DirectAdmin, issuing a new certificate or replacing an expired one takes less than five minutes.

1. Log in to DirectAdmin, select the domain, and open the SSL Certificates menu.
2. Choose the Free & automatic certificate from Let's Encrypt tab.
3. Tick every entry you need covered — in particular both example.com and www.example.com (skipping one of these is the single most common cause of COMMON_NAME_INVALID).
4. Click Save. DirectAdmin validates the domain automatically and installs the certificate together with the full chain in one step.
5. Return to the SSL Certificates page and confirm the new certificate is active. Renewal then happens automatically before expiry, with no cron job of your own required.

Remember to enable Force SSL with https redirect on the same page so every visit is pushed through HTTPS. A full walkthrough lives in our article on installing Let's Encrypt on DirectAdmin. If the warning persists after issuing the certificate, clear your browser cache or retest from another network — you may simply be seeing a cached failure.

Inspecting a Certificate With Your Browser

Before changing anything, look at the actual certificate data. No special tools are needed.

• Chrome/Edge: click the tune icon next to the URL > Connection is secure > Certificate is valid. You will see the issuer, the expiry date and the full SAN domain list.
• Firefox: click the padlock > Connection secure > More information > View Certificate, which shows the entire chain in one tab.
• Directly from the error page: in Chrome, click the error code text or the Advanced button for an explanation of exactly what failed, such as the date the certificate expired.

Note down three fields: Issued to (which domain), Issued by (which CA) and Valid from/to (the validity window). Those three values answer nearly every diagnosis.

Inspecting a Certificate With openssl

For technical users and server administrators, openssl reports far more detail and can be run from any machine.

# Show every certificate the server presents (check the chain)
openssl s_client -connect example.com:443 -servername example.com

# Show only the validity dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# List every domain in the SAN field
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

In the output of the first command, jump to the final Verify return code line. 0 (ok) means the chain is complete; 21 (unable to verify the first certificate) means the intermediate is missing; 10 (certificate has expired) speaks for itself. The -servername parameter is mandatory on servers hosting multiple sites (SNI) — without it you may be handed the certificate of a different site on the same machine.

Does It Behave Differently on Mobile?

The mechanics are identical, but three differences are worth knowing. First, very old phones may lack newer root certificates, so a site using a recently established CA fails on the phone while working fine on a desktop; the safe fix is an operating system update. Second, some apps embed an in-app browser that handles certificates differently from the system browser — open the same link directly in Chrome or Safari to isolate the problem. Third, a phone that stays connected to a captive-portal Wi-Fi network after the session expired will see warnings on every site; switch to 4G/5G and retest. If everything works on mobile data, the Wi-Fi network is the culprit.

Preventing It for Good: a Site-Owner Checklist

• Always enable automatic certificate renewal — never rely on calendar reminders alone.
• Issue certificates covering both www and non-www every time, and extend the certificate the moment you launch a new subdomain.
• After every install or renewal, verify with openssl or an external SSL checker rather than only your own browser, which may serve cached results.
• Confirm the Verify return code is 0 (ok) to prove the chain is complete.
• Set an expiry alert at least 14 days in advance to leave time for fixes.
• If you use a CDN or proxy such as Cloudflare, validate the certificate on both legs: browser-to-CDN and CDN-to-origin.

Frequently Asked Questions

Is the Your connection is not private error dangerous?

The warning itself is not a virus or an attack. It is the browser's built-in protection telling you it cannot verify the site's SSL certificate. The real risk only appears if you bypass the warning and then type passwords or card details into a connection that cannot be verified, so never click Proceed unless you fully trust the site.

Why do I see this error on every website I visit?

If every site triggers the warning, the problem is almost certainly on your device or network rather than the websites. The usual suspects are a wrong system date and time, a public Wi-Fi captive portal you have not signed into yet, an antivirus product with HTTPS scanning enabled, or a damaged local root certificate store. Enable automatic time sync and try a different network first.

What does NET::ERR_CERT_DATE_INVALID mean?

It means the certificate's validity dates do not match the current time. Either the certificate genuinely expired on the server side, or the visitor's computer clock is set to the wrong month or year. If your clock is correct and the error persists, the website simply forgot to renew its certificate.

Is it safe to click Proceed anyway?

Only when you know exactly what the site is and you will not enter any sensitive data, for example testing your own site on localhost or a home device. Never bypass the warning on banking, shopping or login pages, because the connection may be intercepted or spoofed and everything you type could be read by a third party.

My website shows this error to visitors. How do I fix it?

Check three things: whether the certificate has expired, whether the certificate names match the exact URL visitors use including www and non-www, and whether the intermediate chain is fully installed. On hosting with DirectAdmin you can issue a fresh Let's Encrypt certificate with automatic renewal from the SSL Certificates menu in a few minutes.

Should I use free Let's Encrypt or a paid SSL certificate?

Encryption strength is identical. Let's Encrypt suits most websites and renews automatically every 90 days. A paid certificate such as RapidSSL DV (around 1,000 THB per year) offers a longer validity period, a warranty, and installation support, which makes it attractive for business sites that want extra assurance.