Your Connection Is Not Private Error: How to Fix It

What is the "your connection is not private" error and what should you do first?

The "your connection is not private" error is a full-page browser warning. It means the browser cannot trust the encrypted connection between you and the site. Close the page, check your device clock and your network, then try again. So do not enter passwords or card details.

First, do not panic. In most cases this warning points to a simple setting or a certificate problem, not to an attack. However, clicking "proceed anyway" before you understand the cause is a bad habit.

Put simply, this guide covers both sides. If you are a visitor, you will rule out causes such as the device clock, public Wi-Fi and antivirus software, one by one. If you own the site, you will find and fix lasting causes such as an expired certificate, a name mismatch or a missing intermediate certificate.

First, learn which side the problem is on. So you can tell in a few minutes, and the sections below show how.

Why does the your connection is not private warning appear?

When a browser connects to a site, it asks the server for a digital certificate. The certificate proves that the site really belongs to that domain name. It also carries the key that encrypts the connection.

The browser checks three things. First, the certificate must not be expired. Second, it must be issued for the exact domain you opened. Third, the browser must trust the organization that issued it. If any one check fails, the your connection is not private warning appears.

For the basic idea, the MDN documentation on Transport Layer Security is a good starting point. It explains how a certificate binds a domain name to a key. We also covered the general concept in our guide to SSL certificates, so we will not repeat it here.

One more distinction matters. This warning signals a trust problem with the certificate. If the browser and the server cannot agree on a protocol or cipher, you see a different error, which we explain in our cipher mismatch article.

What do the Chrome certificate error codes mean?

At the bottom of the warning screen, a small error code appears. It also helps you guess the cause. The table below summarizes the three codes people see most often.

Exact wording can change between browser versions. For current meanings, check Chrome Help. In addition, the Chrome page on fixing connection errors lists general troubleshooting steps.

Note: a code alone does not give a final diagnosis. The same code can come from different causes. Still, it tells you which side to inspect first.

Is the your connection is not private error on your device or on the site?

In practice, separating the two saves time. First, open the same site on your phone using mobile data. Then try another browser or another device. The results show where the problem sits.

• If the site opens fine on mobile data, the problem is probably your Wi-Fi network or your computer.
• If you see the same warning on every device and network, the problem is probably the site's certificate.
• Likewise, if it happens in only one browser, extensions, cache or browser settings are involved.
• Finally, if it happens on only one site, run a certificate check on that site.

To test a site from the outside, our SSL checker does the job. You enter the domain, and then the tool shows the certificate end date and the names it covers. That gives you a second opinion that does not depend on your own device.

This quick check also prevents pointless setting changes. For example, if the site is at fault, tweaking your device only wastes time.

How do you fix the your connection is not private error as a visitor?

The order below starts with the most likely and cheapest fix. Also, reload the page after each step.

1. Check the address. A typo can send you to a different site.
2. Set your device date and time to automatic.
3. On public Wi-Fi, switch to mobile data or finish the network's login page.
4. Open the page in a private window to rule out extensions and cache.
5. Update your browser and operating system. Old devices may not recognize newer certificate authorities.
6. Turn off the HTTPS scanning feature of your antivirus for a moment, test, and then turn it back on.
7. If nothing works, tell the site owner. The problem is probably on their side.

The logic is simple. First, rule out the common causes on your side. Then accept that the site is at fault and report it.

Still, none of these steps requires you to switch off your protection for good. If you change a setting for a test, restore it afterward.

Why do the device date and time cause a connection is not private error?

Certificates have a start and an end date. Your browser checks that range against your device clock. If the clock is wrong, even a valid certificate looks expired or not yet valid.

In practice, this happens most on old computers, phones with drained batteries and devices that sat unused for a long time. Likewise, a manually changed time zone can cause it. For example, if the date jumped back a year, almost every HTTPS site shows a warning.

In practice, the fix is quick. Open your system date and time settings and turn on the automatic option. Choose the right time zone too. Then close the browser completely and reopen it.

If only one site shows a date error and your clock is right, the certificate itself is the problem. In other words, the site's certificate may really have expired. As a visitor, you can only warn the owner.

Why does public Wi-Fi trigger this warning?

Many cafe, hotel and airport networks show a login page before they let you online. Until you finish that page, HTTPS requests can fail halfway. The browser then sees a response from the network instead of a real certificate, so it warns you.

Some networks also step into the traffic to inspect it. Corporate networks often do this, for example. Still, if you see an unexpected certificate warning on a public network, be careful, because someone may really be interfering with the connection.

So the safe path is clear. Finish the network login page first. If the warning stays, switch to mobile data. If the problem disappears there, the Wi-Fi network was the cause.

Above all, avoid sensitive logins on such networks, such as banking, email or ad accounts. If you must, use mobile data. Moreover, clicking through the warning is the most dangerous choice in exactly this situation.

Can antivirus software, proxies and VPNs cause this error?

Yes, they can. Some security tools scan HTTPS traffic by re-signing it with their own certificate. If the browser does not trust that certificate, it shows an error. This is common when the software is outdated or its certificate was never installed in the browser.

Corporate proxies and some VPN apps work in a similar way. For example, if you see the error on a work network, talk to your network administrator. You should not add certificates on your own, and doing so is often wrong.

• Turn off the HTTPS or SSL scanning option of your antivirus for a short test.
• If a VPN or proxy is on, switch it off and reload the page.
• Update the security software to the latest version.
• If this fixes the issue, follow the vendor's guidance instead of changing the setting for good.

In short, these tools sit in the middle, and the error comes from the certificate they create. The right fix is to update or configure the software. Leaving your protection switched off is not a fix.

Why is it risky to click past the your connection is not private warning?

The warning screen usually offers an advanced option and a link to proceed anyway. When you click it, the browser takes you to the site knowing it could not verify the certificate. The connection may still be encrypted, but you cannot be sure the other side is the real site.

Put simply, that difference matters. Someone in the middle can present a fake certificate and read the traffic between you and the site. Your password, card number and form data all travel inside that traffic.

Therefore, follow one rule: never click past the warning on a page that asks for a login, a payment or personal data. Proceeding may be reasonable only on your own local test site, when you know exactly what you are doing.

If you own the site, never tell visitors to click past the warning. That teaches them a bad habit. The right answer is to fix the certificate, so act quickly instead of leaving the problem to your customers.

How do you diagnose the your connection is not private error as a site owner?

First, note the error code and inspect the certificate from the outside. The order below starts with the most common cause. We use example.com as the sample domain.

1. Look at the certificate end date. If it has passed, you need to renew.
2. Check which domain names the certificate covers. Both example.com and www.example.com should be on the list.
3. Test the certificate chain. If an intermediate certificate is missing, some devices fail and others do not.
4. Confirm that the DNS records of the domain point to the right server.
5. Make sure the new certificate is really installed and active on the server. Often the certificate was issued but the web server was never reloaded.
6. If you use a CDN or a firewall, check their certificate settings as well.

You can do most of these checks in seconds with the SSL checker. For DNS records, the DNS lookup tool helps. Together they show whether the problem sits in the certificate or in the routing.

We recommend following this order as a team. Renewing a certificate does not fix a wrong domain name. Acting before you find the cause wastes time.

What do you do when the certificate has expired?

Above all, this is the most common cause. However, a certificate does not last forever. When it ends, the browser shows NET::ERR_CERT_DATE_INVALID. The certificate authority sets the validity period, and it can change over time, so check the current value from the official source.

First, find out where the certificate came from. It may have come from your hosting panel, your domain provider or a free certificate authority. Then start the renewal in the same place.

1. Note the end date and the provider of the current certificate.
2. Renew or reissue the certificate in the provider's panel.
3. Install the new certificate on the server and reload the web server if needed.
4. Clear the browser cache and test the home page and a few inner pages.
5. Confirm the new end date with a certificate checker.

If the domain itself expired, the picture is different. In that case you need to recover the domain, not the certificate. See our expired domain guide for the details.

How can a wrong domain name cause the error, including www and non-www?

The NET::ERR_CERT_COMMON_NAME_INVALID code says the certificate does not cover the name you opened. For instance, a certificate may cover only example.com while the visitor opens www.example.com. The reverse also happens.

Subdomains cause a similar problem. The certificate may cover the main domain but not blog.example.com or shop.example.com. If you run several subdomains, consider a multi-name certificate or a wildcard certificate.

• When you order the certificate, add both the bare domain and the www version.
• Remove DNS records of subdomains you no longer use.
• Pick one preferred address and redirect the other to it.
• When you add a new subdomain, update the certificate coverage.

Also, be careful with redirects. A redirect cannot run before the certificate check. So if a visitor opens the wrong address, the browser shows the certificate error before it ever sees the redirect. You can read about redirect types in our redirect article.

Why does a missing intermediate certificate break the site only on some devices?

Certificates work as a chain. An intermediate certificate signs your site's certificate. A root certificate that browsers already know signs the intermediate one. If the server does not send the intermediate link, some devices cannot complete the chain by themselves.

As a result, the situation is confusing. You open the site on your computer without trouble. Your customer's phone, however, shows NET::ERR_CERT_AUTHORITY_INVALID. This mismatch is the typical sign of a missing intermediate certificate.

The fix is to install the chain file your provider gives you, together with the certificate file. For instance, many panels ask for it in a field such as a certificate bundle. Find the relevant section in your panel and paste the full chain.

A self-signed certificate causes the same error. Instead, use such certificates only in test environments. On a live site, use a certificate from an authority that everyone trusts.

After that, test from a different device and a different network. That way a single cached device cannot fool you.

How do you set up automatic renewal and why does it break?

An expired certificate is the easiest problem to prevent. Most providers offer automatic renewal. Free certificate authorities also rely on automation. For the general approach, see the Let's Encrypt FAQ.

If automatic SSL is on in your hosting panel, renewal usually runs without your help. Nevertheless, automatic renewal can break too. The most common causes are these:

• The DNS records moved to another server, so the validation fails.
• A firewall or redirect rule blocks the validation request.
• The renewal job stopped working after a server version change.
• Notification emails go to an unused address, so nobody sees the warning.
• You changed providers, but the old certificate still sits on the site.

So trusting automation is not enough. You also need to monitor it. The next section suggests a simple routine.

Which checks should you run after renewing the certificate?

Installing the new certificate does not finish the job. A few short checks prevent a second error.

1. Open the home page, an inner page and a critical page such as login or checkout.
2. Test the www and non-www addresses separately.
3. Open the site on your phone using mobile data.
4. Confirm the end date and the completeness of the chain with a certificate checker.
5. Look for page resources that still load over plain http.

Still, the last item is a separate class of error. Even with a healthy certificate, the browser warns you when the page loads unencrypted resources. We explain this in our mixed content error article.

In addition, scan the site for broken links with the broken link checker. This is especially useful if you changed addresses during the renewal.

Does a certificate error affect SEO and visitor trust?

It does, but do not exaggerate. A browser warning makes visitors leave before they enter. Google also treats HTTPS as a signal in search. For details, read the Google Search Central documentation.

However, the real damage is lost trust. A visitor who sees the warning finds the site unreliable and often never returns. If you run ads, it is worse, because the budget you pay for clicks goes to waste.

Search bots can also hit certificate errors. If the problem lasts, crawling and indexing may suffer. The size of this effect varies by site, so we do not give a fixed number.

We suggest treating certificate checks as a routine item of technical SEO audits. In our SEO consulting work, we run these checks regularly.

Which methods really fix the your connection is not private error?

The table below matches common "fixes" with their causes. That way you avoid random trial and error.

The last column matters. Most of the behaviors to avoid look like they work in the short term. In fact, they hide the problem and raise the risk.

Which prevention habits do we recommend as a team?

In practice, most certificate problems are preventable. In short, you do not need complex tools; a few regular habits are enough.

• Add certificate end dates to a shared calendar and set reminders ahead of time.
• Send notification emails to a team address, not to one person.
• Turn on automatic renewal, but test that it works.
• Keep a list of which provider issued each certificate.
• Track domain renewal and certificate renewal on the same calendar.
• Verify the certificate separately after any server or hosting change.

Consider an online store as an example scenario. The certificate ends during a campaign week and the checkout page shows a warning. The loss is not only sales but also trust. A team with reminders would have seen it weeks earlier.

If you plan a migration or a hosting change, add the certificate step to your checklist. The security habits in our hacked WordPress guide are useful here as well.

When should you ask for help, and what should you avoid?

If you cannot find the cause with the steps above, write to your hosting provider or to the authority that issued the certificate. Share the error code, the domain and the steps you tried. This information also speeds up the fix.

Some paths are best avoided. Above all, do not trust messages from strangers who promise to fix the certificate right away. Do not share your server password or panel access with the first person who offers help. Also, do not install fake tools that claim to bypass certificate checks.

Methods that try to bypass security systems break the rules and expose you to bigger risks. For that reason, always use the provider's official channel.

If you notice anything else suspicious on your site, such as unknown pages or redirects, that is a sign of another problem. In that case, run a security review without waiting for the certificate.

In the end, the your connection is not private error is usually solvable. Once you find the right side, a few steps are enough. Acting fast and not ignoring the warning is the most important rule.

Why does the browser sometimes hide the proceed anyway option?

However, on some sites the warning screen has no proceed link. The usual reason is that the site told browsers to open it only over a secure connection. This mechanism is called HSTS, short for HTTP Strict Transport Security.

In that case, the browser does not let the user take the risk alone. If the certificate is faulty, there is no way into the site. Banks and large services use this protection often.

That said, the behavior can feel annoying. Actually, it protects you, because on such sites a certificate problem usually means a real fault or interference on the network.

Also, if you own the site, there is one more consequence. With HSTS, a certificate error becomes a hard wall for visitors. For that reason, take renewal and monitoring even more seriously. As a visitor, try again later or tell the owner through another channel.

What happens to the certificate after a domain or server move?

During a move, the certificate often stays on the old server. When DNS points to the new server, visitors see an error because the new server has no certificate yet. Moreover, a DNS change does not reach everyone at once, so some visitors reach the old server and others the new one.

For that reason, plan the certificate before the move. Prepare the certificate on the new server, or make sure it can be issued automatically. Then change DNS. If the order is reversed, a short period of warnings is unavoidable.

You can see where DNS points with the DNS lookup tool. Then confirm which server the certificate comes from with the SSL checker. Comparing the two results shows a mismatch quickly.

Also, do not shut down the old server right away. Instead, keep it as a backup until the certificate on the new server works. This simple step shortens the downtime a lot.

What quick checklist helps when a customer reports the error?

In practice, a customer sometimes notices the error before you do. Stay calm and work in order. The short list below keeps the first half hour productive.

1. Ask the customer for a screenshot and the error code.
2. Open the site on your own device and on mobile data to confirm the error.
3. Check the end date, the covered names and the chain with a certificate checker.
4. Ask whether hosting, DNS or CDN settings changed recently.
5. Fix the cause, then retest from several networks.
6. Give the customer a short, honest update; do not promise exact times as if they were guaranteed.

This order keeps you away from guess-based changes. Also, logging the incident makes the next one easier. For example, save the time, the cause and the fix in a short note.

Finally, decide in advance who is responsible. A certificate problem can appear at night or on a weekend. If everyone knows who looks at it, response time drops, and so does the loss of visitors.