SSL & Security

"Your Connection Is Not Private" — When It Is Safe to Continue

Updated 2026-08-29~8 min read

A full red warning page is alarming by design, and the standard response is to look for the "proceed anyway" link. Sometimes that is genuinely fine. Sometimes it is the worst thing you could do.

The difference is written in the small code underneath the message — NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_AUTHORITY_INVALID and the others. Each names a specific check that failed, and some of those failures are harmless while one of them is what an interception attack actually looks like. This guide teaches you to read that line.

Read the Code Under the Warning

The big red text is the same for every cause. The code below it is what tells you what actually went wrong.

CodeWhat it meansHow serious
NET::ERR_CERT_DATE_INVALIDCertificate expired, or your device clock is wrongUsually harmless — check your clock first
NET::ERR_CERT_COMMON_NAME_INVALIDCertificate is for a different domain nameSuspicious — could be misconfiguration or redirection
NET::ERR_CERT_AUTHORITY_INVALIDIssuer is not trusted by your deviceSerious — this is what interception looks like
NET::ERR_CERT_REVOKEDThe certificate was cancelled by its issuerSerious — it was revoked for a reason
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHMSigned with an obsolete algorithmOld and neglected — treat as untrusted
ERR_SSL_PROTOCOL_ERRORThe encrypted handshake failed entirelyConfiguration, usually not an attack
💡 The most important line is ERR_CERT_AUTHORITY_INVALID. It means something presented a certificate your device has no reason to trust — which is precisely what a man-in-the-middle looks like. Never click through this one on a network you do not control.

When You Can Continue, and When You Must Not

Two questions decide it: what does the site do, and whose network are you on?

It is reasonably safe to continue when you are on a network you trust, the code says the certificate merely expired, the site is purely informational, and you will not type anything into it. Reading a public article on a site with a lapsed certificate is a low-stakes act.

You must never continue when the page asks for a password, card details or personal data; when the code says the authority is invalid or the certificate was revoked; when you are on public Wi-Fi in a cafe, hotel or airport; or when the warning appears on a bank, payment or government site. In those cases the warning is doing exactly the job it exists for.

The awkward truth is that clicking through teaches you to ignore the one alert that stands between you and a credential theft. The habit is the real risk, more than any single click.

💡 A simple rule that costs you very little: if the page has a login box or a payment form, never click through. Ever. Find another route to that site.

If Every Site Shows It, the Problem Is Your Device

When the warning appears on every website rather than one, the certificates are not the problem — something on your machine is failing to validate them.

  • Check the date and time first. A clock that is wrong by more than a day makes every valid certificate look expired or not yet valid. Turn on automatic time synchronisation. This is by far the most common cause of the "suddenly every site is broken" version.
  • Restart, then try a different browser. If only one browser is affected, the problem is that browser's profile or an extension.
  • Turn off antivirus HTTPS scanning temporarily. Security suites intercept encrypted traffic to inspect it, and their own certificate can fail validation after an update.
  • Disconnect from any VPN or proxy and retry.
  • On a public network, check whether you have completed the captive-portal login. Hotel and airport Wi-Fi frequently intercepts traffic until you sign in, which produces exactly this warning.
  • Update your operating system. The list of trusted certificate authorities is shipped with the OS, and a very old system may not trust authorities that have been issuing certificates for years.
  • Clear the browser's SSL state, which discards cached handshake decisions that may be stale.

If It Is Your Own Site, Fix It Here

Seeing this on a site you run means every visitor is seeing it too, and almost all of them are leaving rather than clicking through. It is functionally an outage.

Start by checking whether the certificate has simply expired — this accounts for most cases and the fix is a renewal. The more useful follow-up question is why auto-renewal did not run: a redirect rule that broke the validation path, a firewall change, or a cron job that stopped after a server migration are the usual culprits. A certificate that lapsed once will lapse again unless you find that.

If the code says the authority is invalid, you have most likely installed only the certificate itself without its intermediate chain. Certificate providers supply a fullchain file precisely for this, and using the wrong file produces a site that works in one browser and fails in another.

If the code says the common name is invalid, the certificate does not cover the hostname people are actually using — most often it covers example.com but not www.example.com. Reissue it with both names, or use a wildcard if you have several subdomains.

Whatever the cause, verify the fix with an external SSL checker rather than by loading the site yourself. Your own browser may have cached a decision, and you want to see what a stranger sees.

Do not let an expired certificate cost you visitors

SSL certificates from ฿600/year with setup support — or free HTTPS included on every hosting plan.

Frequently Asked Questions

Is it ever genuinely safe to click "Proceed anyway"?

On a network you control, for a site you are only reading, when the code says the certificate expired — the practical risk is low. On public Wi-Fi, or on any page with a login or payment form, it is not safe regardless of the code, because that is the exact scenario the warning is designed to catch.

Why does it happen on every site all of a sudden?

Almost always a wrong system clock. Certificates are only valid between two dates, so a device that thinks it is 2019 will reject every certificate on the internet. Turn on automatic time sync and the problem usually disappears immediately.

My certificate is valid but visitors still see the warning. Why?

Usually an incomplete chain — you installed the certificate without its intermediate. Your browser may have cached the intermediate from another site and appear fine while everyone else fails. Install the fullchain file and confirm with an external checker.

How can I tell an attack from a misconfiguration?

The code and the context together. ERR_CERT_AUTHORITY_INVALID on public Wi-Fi, on a site that normally works fine, is the shape of an interception. The same code on your own freshly configured server is almost certainly a missing intermediate. When in doubt, switch to mobile data and try again — if the warning disappears, the network you were on was the problem.