Fix “Your connection is not private”: SSL certificate errors

"Your connection is not private" (or "Warning: Potential Security Risk Ahead" in Firefox, "This Connection Is Not Private" in Safari) means the browser checked your site's SSL certificate and something failed. It blocks the page rather than risk sending visitors' data to the wrong server.

The good news: there are only a handful of causes, the error code tells you which one, and each has a clear fix. This guide walks through them in order of how often they happen.

Visiting someone else's site? Jump to If you're a visitor. The rest of this guide is for the people who run the site.

Step 1: Find the exact error

On the warning page, click Advanced (Chrome, Edge) or look under the explanation (Firefox). You'll see a code. Match it here:

Then confirm what the server is actually sending. Enter your domain in our free SSL checker: it shows the expiry date, the names covered, the full chain, revocation status and TLS versions in one report, so you can see every problem at once, not just the first one the browser hit.

From a terminal, this shows the dates, subject and issuer of the certificate your server presents (replace example.com):

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Expired certificate

Codes: NET::ERR_CERT_DATE_INVALID, SEC_ERROR_EXPIRED_CERTIFICATE

The most common cause by far. Every certificate has a "not after" date, and the moment it passes, browsers refuse it.

If only one person sees the error, check their computer's date and time first. A clock set months off makes a valid certificate look expired or not yet valid.

If everyone sees it, renew and reinstall:

1. Renew the certificate.

   • Let's Encrypt with Certbot: run sudo certbot renew. If renewal fails, the output says why; the usual causes are a DNS record that no longer points at the server, a firewall blocking port 80, or a changed web root.
   • Hosting panel or managed platform (cPanel, Plesk, Vercel, Netlify and similar): use its SSL page to reissue. Most also show why automatic renewal failed.
   • Commercial certificate: order the renewal from your provider, complete validation, and download the new certificate together with its intermediate bundle.

2. Install it and reload the web server. A renewed certificate does nothing until the server loads it. This step is skipped surprisingly often.

   sudo systemctl reload nginx     # Nginx
   sudo systemctl reload apache2   # Apache on Debian/Ubuntu (httpd on RHEL/Fedora)
   

3. Update every place the certificate lives. Load balancers, CDNs, other servers behind the same domain, mail servers and API gateways each hold their own copy. The certificate visitors see is the one at the outermost layer, often the CDN or load balancer.

4. Check again with the SSL checker and confirm the new expiry date.

Then find out why it lapsed. If renewal was meant to be automatic, something broke it, and it will break again. sudo certbot renew --dry-run tests the whole renewal without changing anything.

Name mismatch

Codes: NET::ERR_CERT_COMMON_NAME_INVALID, SSL_ERROR_BAD_CERT_DOMAIN

The certificate is valid, but not for the address in the browser. Common reasons:

• www versus the bare domain. A certificate for www.example.com doesn't cover example.com, and the other way round.
• A new subdomain such as shop.example.com that was never added to the certificate.
• Wildcards cover one level only. *.example.com covers shop.example.com, but not example.com itself or eu.shop.example.com.
• The wrong certificate is served. On a server hosting several sites, a missing or misnamed site configuration makes it fall back to another site's certificate.

To see which names your certificate covers:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Fix: reissue the certificate with every name you need. With Certbot, list all of them and accept the prompt to expand the existing certificate:

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com

If the names are right but the wrong certificate is served, check that the site's server_name (Nginx) or ServerName/ServerAlias (Apache) matches the address exactly.

Untrusted certificate

Codes: NET::ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_UNKNOWN_ISSUER, MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

The browser can't link your certificate to an authority it trusts. Three usual causes:

The intermediate certificate is missing

Certificate authorities sign your certificate with an intermediate certificate, and your server must send that intermediate along with your own. If it doesn't, the chain is broken.

This one is sneaky: many desktop browsers quietly fetch or remember the missing intermediate, so the site looks fine in your browser while apps, curl, API clients and some phones reject it.

Count the certificates your server sends (a correct setup sends at least two):

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"

Fix: configure the full chain file, not just your own certificate. With Let's Encrypt that's fullchain.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

On Apache 2.4.8 and later, point SSLCertificateFile at the full-chain file too. For a commercial certificate, append the provider's intermediate bundle after your certificate in the same file, then reload the server.

The certificate is self-signed

Self-signed certificates (common on test servers, routers and freshly installed software) aren't trusted by any browser. Fix: replace it with a certificate from a public authority. Let's Encrypt issues them free.

Something is intercepting the connection

If the error appears only on certain networks or computers, the issuer named in the warning may be a company firewall, an antivirus product that scans HTTPS, or a public Wi-Fi login page. That's a visitor-side issue, not a problem with your certificate.

Revoked certificate

Codes: NET::ERR_CERT_REVOKED, SEC_ERROR_REVOKED_CERTIFICATE

The authority that issued your certificate has cancelled it: because the private key was reported as exposed, because it was issued in error, or because you (or someone with access to your account) asked for it.

Fix:

1. Request a new certificate with a new private key. Don't reuse the old key; if revocation was due to a leak, the old key is compromised.
2. Install it and reload the server, as for an expired certificate.
3. If you didn't expect the revocation, ask your provider why, and review who has access to your servers and certificate account.

Our SSL checker shows whether a certificate is revoked and when it happened.

Outdated TLS settings

Codes: ERR_SSL_VERSION_OR_CIPHER_MISMATCH, SSL_ERROR_NO_CYPHER_OVERLAP, SSL_ERROR_UNSUPPORTED_VERSION

The browser and server couldn't agree on a secure way to talk. Usually the server only offers versions that browsers have dropped (TLS 1.0 and 1.1) or very old encryption settings.

Fix: enable TLS 1.2 and 1.3.

# Nginx
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (TLS 1.3 needs Apache 2.4.36+ with OpenSSL 1.1.1+)
SSLProtocol -all +TLSv1.2 +TLSv1.3

Reload the server, then use the SSL checker to confirm which versions it accepts.

Why there's no "proceed anyway" button

If your site uses HSTS (HTTP Strict Transport Security), browsers won't let visitors click past a certificate error at all. That's by design: HSTS promises the site is always served securely. It also means a certificate problem takes the site fully offline for everyone until it's fixed, which is one more reason to catch expiry early.

If you're a visitor

If you see this warning on a site you don't run:

1. Check your device's date and time. A wrong clock is a common cause.
2. On public Wi-Fi, open any plain http:// site first to get the network's login page, then try again.
3. Try another network or device. If the error disappears, something on your original network or computer (a firewall or antivirus HTTPS scanning) is involved.
4. Don't enter passwords or payment details while the warning is showing.
5. Let the site owner know. They may not have noticed yet.

Stop it happening again

Nearly every certificate error on a site that used to work comes down to something changing unnoticed: a renewal that silently failed, a new subdomain, a server that never reloaded. An outside check catches all of them before your visitors do.

CertHalo checks your certificates on a schedule and emails you before they expire (60, 30, 14, 7, 3 and 1 day ahead) and the moment one changes, stops matching its name, loses its chain or is revoked. Monitor 3 certificates free, no card needed.