Your connection is not private: what it means and how to fix it

Your connection is not private is the warning a browser shows when it cannot verify the site's certificate, so it stops before loading the page. Usually the fault is at the site: a certificate that expired, does not cover the name, or was installed without its chain. Sometimes it is the device or the network, and a few checks tell which. The browser's own code, under the message, names the exact problem. All browser codes are listed on SSL errors.

Quick facts

Browsers

Chrome and Edge, as Your connection is not private and Your connection isn't private; Safari, as This Connection Is Not Private

Firefox equivalent

Warning: Potential Security Risk Ahead

What failed

the certificate check, before any page content was requested

Who fixes it

usually the site owner; the visitor when the clock, network or security software is the cause

Is the site malicious?

usually not, but the browser cannot tell, which is why it stops

What the warning means

Before showing a page, the browser checks the site's certificate: that it covers the name in the address bar, that it is within its dates, and that it was issued by an authority the browser trusts. If any of those checks fails, the browser cannot confirm it is talking to the real site, and it stops rather than sending anything.

The sentence is accurate in a narrow way. The connection would still be encrypted, but nobody has verified who is at the other end, and an unverified connection is exactly what someone intercepting traffic needs. The browser cannot tell a forgotten renewal from an attack, so it treats both the same.

What the screen does not say is which check failed. That is the code beneath it:

• Chrome and Edge. The code appears in small text under the message, in the form NET::ERR_CERT_.... Select Advanced for a short explanation.

• Firefox. Select Advanced; the code appears as SEC_ERROR_..., SSL_ERROR_... or MOZILLA_PKIX_ERROR_....

• Safari. No code. Select Show Details for a sentence describing the problem.

How to fix it as a visitor

Work down this list. Each step takes under a minute, and the first that changes the result tells you the cause.

1. Reload the page. A captive portal or a network change can interrupt the first attempt.

2. Check the date and time on your device. Certificates are valid between two dates, and a device whose clock is wrong treats valid certificates as expired or not yet valid, usually on every site at once. Set the clock to update automatically.

3. If you are on public Wi-Fi, open any plain website first. Hotel, airport and café networks often hold connections until you accept their terms, and until then they answer instead of the site you asked for.

4. Try another network, such as mobile data instead of Wi-Fi. If the site works there, the first network is interfering.

5. Check security software and VPNs. Antivirus products that scan HTTPS traffic, and some VPNs and corporate proxies, replace the site's certificate with their own. If the warning appears on many unrelated sites, this is the likely cause; turn the HTTPS scanning off briefly to confirm, and on a work device ask whoever manages it.

6. Try a private window or another browser. If the site loads there, an extension or the browser's stored state is involved.

7. Update the browser and the operating system. An old device may not trust the authorities that newer certificates come from.

If the site fails the same way on a second network and a second device, the problem is at the site, and nothing on your side will clear it. The site owner has to fix the certificate.

Can you get past the warning?

Most browsers let you continue: Advanced, then Proceed in Chrome and Edge, Accept the Risk and Continue in Firefox, visit this website in Safari. Doing so does not repair anything. It tells the browser to use a connection whose other end it could not verify.

Do not continue on any page where you would sign in, pay or enter personal details. If you do continue, treat whatever you send as visible to someone else.

Some sites do not offer the option at all. A site that has told browsers to accept only verified HTTPS connections, a policy called HSTS, cannot be bypassed from the warning page. That is intended: the site has asked for exactly this.

How to fix it as the site owner

If visitors see this on your site, they all see it, and most will leave. Start with the code, because it names the problem:

Then check what the hostname actually serves, from a machine other than the server:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

The output answers the three checks in turn: the names covered, the issuer, and the dates. A certificate that looks correct on disk and wrong here was installed but is not being served, often because the server was not reloaded or because a load balancer or CDN in front of it holds its own copy.

If the output looks correct and visitors still see the warning, check the chain. A server that sends its own certificate without the intermediate fails for some visitors and not others, and works on the owner's browser because that browser already has the intermediate cached. See certificate chains.

When it is a different screen

This site can't provide a secure connection is a different failure: the connection broke before any certificate was checked. Its common code is ERR_SSL_PROTOCOL_ERROR. Firefox shows that kind of failure as Secure Connection Failed, and Safari shows Safari can't establish a secure connection. A page that loads with a broken or missing padlock is not this warning either; that is usually mixed content, an HTTPS page loading some resources over plain HTTP.

FAQ