Your browser refused to connect because it could not verify who it was talking to. Sometimes that is an expired certificate nobody renewed. Sometimes it is your own clock. Occasionally it is exactly what it looks like.
A certificate warning is your browser declining to proceed because the cryptographic identity of the server could not be verified. The connection reached the server, TLS began, and the browser stopped.
These are worth understanding individually, because they range from trivially benign to the one thing the whole system exists to prevent - And the browser cannot tell you which you are looking at.
The most common by a wide margin. Every certificate has a validity window, and the moment the end date passes browsers refuse the connection. Not a warning to click past by default: A full stop.
For a site, this is a total outage with a mundane cause. The server is running, the application is healthy, the content is served, and no standard browser will complete the handshake. It persists because renewal is often nobody's specific job, and because automated renewal silently failing looks exactly like automated renewal working until the day it does not.
Before blaming the site: If certificates fail on every site, your device clock is wrong. A certificate valid today looks expired to a machine that thinks it is next year, and it looks not-yet-valid to one that thinks it is last year. This is the single most common cause on devices whose battery has died, and on anything freshly reset.
The certificate is valid but was issued for a different name. Visiting example.com and receiving a certificate for www.example.com does it, as does a shared host serving the wrong site's certificate.
Usually a configuration mistake. It is also, though, precisely what an interception attempt looks like, which is why browsers treat it seriously rather than shrugging.
The certificate was signed by something the browser does not trust. Three quite different situations produce it.
A self-signed certificate. Normal on internal tools and development servers, and meaningless on the public web.
A missing intermediate. The server sent its own certificate but not the chain linking it to a trusted root. Frustratingly, this often works in some browsers and not others, because some clients will fetch the missing link and some will not. A site that works in Chrome and fails in Firefox is very often this.
Interception. Corporate networks that inspect TLS install their own root on managed devices; on an unmanaged device the same interception shows up as an untrusted issuer. On a public network this is the warning to take seriously.
The certificate was valid and has been deliberately revoked, usually because the private key was compromised. Rarer than the others and never worth bypassing.
Not strictly a certificate problem - The handshake itself failed. Typically no shared cipher suite or protocol version between client and server, which happens when a server is hardened to modern-only and an old client connects, or when an ancient server only offers protocols modern browsers have removed.
It also appears when something is intercepting connections badly, which is why antivirus products with HTTPS scanning are a common cause.
Browsers deliberately make bypassing awkward, and that design is correct.
Never bypass on a site where you will enter a password, payment details or anything private, on a public or unfamiliar network, or where the warning is a hostname mismatch you cannot explain. The warning exists precisely for the case where somebody is between you and the server.
Reasonable to bypass on your own development server with a self-signed certificate, or on an internal tool you administer and understand.
In between - A well-known site with an obviously expired certificate - The risk is low but the better move is simply to wait. Expired certificates are usually fixed within the hour, because the failure is total and unmistakable and somebody is already on it.
Not all certificate errors are between you and the site. If a CDN cannot validate the origin's certificate, the visitor sees a perfectly valid connection to the CDN and an error page from it - Cloudflare's 525 and 526 are exactly this. The TLS problem is one hop further in and there is nothing on the visitor's side to fix.
Automate renewal, then monitor it, because the automation failing silently is the actual risk. Alert at 30 and 14 days remaining rather than relying on the renewal job to complain.
Serve the full chain including intermediates - Testing in one browser is not sufficient, since clients differ in whether they will fetch a missing link. And do not forget internal certificates: An expired certificate on an internal service can take down a deployment pipeline at the worst possible moment, which is how a short outage becomes a long one.
Your device clock is almost certainly wrong. Certificate validity is checked against your system time, so a machine that thinks it is next year sees every valid certificate as expired. Correcting the date and time fixes it immediately.
Not on any site where you will enter a password or payment details, and not on a public network. The warning exists precisely for the case where something is between you and the server. It is reasonable only on your own development or internal systems where you know why the certificate is untrusted.
Usually a missing intermediate certificate. The server sent its own certificate but not the chain linking it to a trusted root, and browsers differ in whether they will fetch the missing link themselves. The site owner needs to serve the full chain.
Usually under an hour. The failure is total and unmistakable, so it is noticed quickly and the fix is a deploy. It lasts longer only when the expired certificate was also protecting the system needed to deploy the replacement.
What Cloudflare errors 520, 521, 522, 523, 524, 525 and 526 mean, and whether the fault is Cloudflare or the website behind it.
What ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT and ERR_CONNECTION_RESET mean, and how to tell which side caused each.
The real causes of website outages - Configuration pushes, BGP withdrawals, expired certificates and dependency cascades.
What a 500 Internal Server Error actually means, why it is always the server's fault, and the handful of cases where a visitor can work around it.
