Certificate Errors on Every Website? Here Is the Fix

If every site you open shows “Your connection is not private”, NET::ERR_CERT_AUTHORITY_INVALID, NET::ERR_CERT_DATE_INVALID, or Firefox’s “Potential Security Risk Ahead”, the websites are not broken. Google, your bank, and a small business site do not all lose their certificates on the same morning. Something on your device or network is failing every certificate check, and the good news is that the list of things that can do that is short.

Work through the checks below in order. Most people are done at step one or two.

The two-minute diagnosis

1. Look at the date and time in the corner of your screen. If it is wrong, even by a day, that is the cause. Skip to the clock fix.
2. Click the padlock or “Not secure” label on any failing site, then view the certificate, and read the “Issued by” line. A public certificate authority such as Let’s Encrypt, DigiCert, GlobalSign, or Google Trust Services means the certificate is real and something is blocking trust. Your antivirus vendor, your employer, or a router or portal name means that software is intercepting the connection and presenting its own certificate.
3. Try a plain http:// address such as http://neverssl.com. If a Wi-Fi login page appears, you are on a captive portal.
4. Try another device on the same network. If the phone works over Wi-Fi, the computer is at fault. If nothing on the network works, the network is.

Whichever step gave you a signal, the matching fix is below.

Fix 1: The clock

Certificates are valid between two dates, and the browser compares them with your device’s clock. A clock set to 2019 makes every current certificate “not yet valid”; a clock set to 2031 makes every one “expired”. Chrome reports NET::ERR_CERT_DATE_INVALID in both cases.

Clocks go wrong more often than people expect: a dead motherboard battery, a laptop that was fully drained, a virtual machine restored from a snapshot, a Raspberry Pi with no real-time clock, or a manually set time zone that drifted.

Windows: Settings → Time & language → Date & time → turn on Set time automatically and Set time zone automatically, then click Sync now. macOS: System Settings → General → Date & Time → Set time and date automatically. Android / iOS: Settings → Date & time (or General → Date & Time) → automatic. Linux: sudo timedatectl set-ntp true and check timedatectl status.

Reload the page. If the clock keeps drifting back after a reboot, replace the CMOS battery.

Fix 2: Antivirus HTTPS scanning

Avast, AVG, Kaspersky, Bitdefender, ESET, Norton, and others can inspect encrypted traffic. To do that they sit between the browser and the site and present their own certificate for every domain. That works only while the browser trusts the antivirus root certificate. After an antivirus update, a browser update, a fresh browser profile, or the vendor’s root expiring, the browser stops trusting it and every site fails with NET::ERR_CERT_AUTHORITY_INVALID.

The tell is the “Issued by” line from the diagnosis: it names the antivirus product rather than a public authority.

Fix: update the antivirus first. If the errors persist, turn off the feature called “HTTPS scanning”, “Web Shield”, “Encrypted connections scan”, or “SSL/TLS protocol filtering”, reload, and confirm the sites load. You can leave it off; the browser’s own protections cover the same ground for most home users.

Fix 3: A Wi-Fi login page (captive portal)

Hotel, airport, café, hospital, and campus networks intercept every request until you accept their terms. The intercept presents the portal’s certificate under the name of whatever site you asked for, so every HTTPS site fails and only the portal’s own page works.

Fix: open http://neverssl.com or any plain http:// address, complete the login page, and retry. If the portal never appears, forget the network and reconnect, or ask staff for the portal address.

Fix 4: A corporate proxy or web filter

Employers and schools often decrypt HTTPS for content filtering, the same technique as antivirus. On a managed device the organisation’s root certificate is installed for you and everything works. On a personal device, or after the proxy’s certificate expires, every site fails. The issuer will be your organisation’s name or the filtering product.

Fix: on a managed device, contact IT; the proxy certificate needs renewing or redeploying. On a personal device, IT can give you the root certificate to install, or you can use mobile data for personal browsing. Nothing on the websites can change this.

Fix 5: An old operating system or certificate store

Certificates chain up to a root that the operating system must already trust. Windows 7, macOS before 10.12, Android before 7.1, iOS before 10, and old Linux or Docker images lack the roots used by the most common authorities. In particular, the Let’s Encrypt root ISRG Root X1 is not present on those systems, and Let’s Encrypt secures a very large share of the web, so “most sites fail, a few big ones work” is the typical pattern.

Fix: update the operating system. Where that is impossible:

• Windows: run Windows Update; root certificates ship through it.
• Linux: sudo apt update && sudo apt install --only-upgrade ca-certificates (Debian/Ubuntu) or sudo yum update ca-certificates (RHEL/CentOS).
• Old Android: install Firefox, which ships its own certificate store.

The same missing-root problem in scripts, containers, and CI jobs is covered in curl (60) SSL certificate problem: certificate has expired.

Fix 6: A VPN, DNS changer, or router problem

Free VPN apps and “ad blocking DNS” services answer some domains with their own server addresses, which cannot present a valid certificate. A router with hijacked DNS settings, which some malware does, has the same effect across every device in the house.

Fix: disconnect the VPN and retry. Set the device’s DNS back to automatic. If every device on the home network fails and the clock and antivirus are fine, log into the router, check that its DNS servers are your ISP’s or a known public resolver such as 1.1.1.1 or 8.8.8.8, and update its firmware.

Fix 7: Malware or a rogue root certificate

Adware that injects advertisements into pages does it by installing its own root certificate and intercepting HTTPS. Superfish on Lenovo laptops in 2015 was the famous case; the pattern still turns up in “free download” bundles. If the issuer on the certificate is something you do not recognise and is not your antivirus or employer, treat it as hostile.

Fix: run a full scan with a reputable scanner, uninstall unknown recently added programs, then remove the rogue root: on Windows, open certmgr.msc → Trusted Root Certification Authorities → Certificates and delete it; on macOS, open Keychain Access, find it under System, and delete it.

Fix 8: A broken browser profile or extension

If incognito mode works and the normal window does not, an extension is interfering; disable them and re-enable one at a time. If a different browser works, the failing browser’s profile is damaged; create a new profile and move bookmarks across. Chrome and Edge also keep an internal cache of certificate decisions that can be cleared by restarting the browser.

If you manage websites: the other side of this

Everything above is a single visitor’s problem. If a customer or client tells you your site shows a certificate error, do not assume it is their clock. Check the domain with the SSL certificate checker, which connects from an independent server and reports the real dates, issuer, and chain. If it flags a problem, the fix is on the server side: see Your connection is not private for the code-by-code breakdown and Certificate has expired: how to fix it on any platform for renewal steps.

To avoid finding out from a customer in the first place, SitesRadar’s free plan monitors one site’s certificate and emails you 30, 14, and 7 days before expiry, alongside uptime, broken links, and DNS changes.

FAQ

Why do some sites still work? Sites whose certificates chain to a root your device does trust, or whose servers send a full chain that works around a missing intermediate. It does not mean the failing sites are broken.

I fixed the clock and it still fails. Restart the browser; it may have cached the failed decisions. Then check the certificate issuer for antivirus or proxy interception.

Is it safe to click “Proceed anyway”? On a captive portal, use the http:// trick instead. Everywhere else, no: if something is intercepting every connection, clicking through hands it your passwords.

Could my ISP be causing this? Rarely, and only through DNS hijacking or a mandatory portal. Switching DNS to 1.1.1.1 or 8.8.8.8 rules that out quickly.