"Your connection is not private": the SSL certificate warning

What the error means

The browser connected to the server, the server presented its certificate, and the browser refused to trust it. Chrome shows "Your connection is not private" with an error code below; Firefox "Warning: Potential Security Risk Ahead"; Safari "This Connection Is Not Private". The site is not hacked and your computer is not infected; the certificate the server sent does not pass the checks a browser makes.

The error code tells you which check failed:

• NET::ERR_CERT_DATE_INVALID: the certificate has expired, or its start date is in the future (or the visitor's clock is wrong).
• NET::ERR_CERT_COMMON_NAME_INVALID: the certificate is for another name, for example for www.example.com but not for example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: the browser cannot trace the certificate to a trusted authority: self-signed, an unknown issuer, or a missing intermediate certificate.
• NET::ERR_CERT_REVOKED: the certificate was revoked by its issuer.
• SSL_ERROR_BAD_CERT_DOMAIN and SEC_ERROR_EXPIRED_CERTIFICATE are Firefox's versions of the name and date errors.

Common causes

1. The certificate expired. Let's Encrypt certificates run 90 days; the automatic renewal failed for weeks and nobody noticed until the day it ran out. Paid certificates expire after a year and the renewal mail went to an old address.
2. Renewed, but not reloaded. certbot wrote the new certificate to disk, but the web server still serves the old one from memory, because the reload hook is missing.
3. Wrong name. The certificate covers example.com but visitors arrive at www.example.com, or a new subdomain was added without a certificate.
4. Missing intermediate certificate. The server sends only its own certificate, not the chain. Desktop browsers often fill the gap from cache; phones and apps fail.
5. A clock problem. On the visitor's computer, a wrong date makes every certificate look expired or not yet valid. On the server, a wrong clock breaks renewal.
6. A CDN or proxy in front with its own certificate that expired or does not cover the name, while the origin is fine.

If you are a visitor

Check your computer's date and time first; a dead CMOS battery or a disabled time sync makes every site fail. Then try another network. If the warning appears for one site only and on every device, the site's certificate is the problem and the owner must fix it. Clicking through "Proceed to site (unsafe)" is fine for a site you know, not for anything with a login or a payment.

If it is your site: check first

Run the SSL Checker. It shows the expiry date, the names the certificate is valid for, and whether the chain is complete, from outside, without any browser cache. Then, on your own server:

# what does the server actually send?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# what is on disk?
sudo certbot certificates

# is the server clock right?
timedatectl

If the dates on disk are newer than the dates the server sends, you have case 2: renewed but not reloaded.

Fixes on your own server

1. Renew with certbot

sudo certbot renew
# or, if renew says "not yet due" but the served certificate is old:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # or apache2

If renewal fails, the output says why. The usual reasons: port 80 is blocked or redirected somewhere certbot does not expect (the HTTP-01 challenge needs /.well-known/acme-challenge/ to be reachable over plain HTTP), the DNS record points at another server, or a rate limit was hit after many failed attempts. Fix the cause and run sudo certbot renew --dry-run until it passes.

2. Make the reload automatic

# Debian/Ubuntu: certbot installs a timer; check it
systemctl list-timers | grep certbot

# add a deploy hook so the web server picks up the new certificate
echo 'systemctl reload nginx' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. Add the missing name

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

The --expand flag replaces the existing certificate with one that covers all listed names.

4. Fix the chain

With certbot, point the web server at fullchain.pem, never at cert.pem:

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

Apache: SSLCertificateFile with fullchain.pem. With a purchased certificate, download the intermediate ("CA bundle") from the issuer and append it to the certificate file. Test with sudo nginx -t, reload, then check the chain with the SSL Checker.

5. Fix the clock

sudo timedatectl set-ntp true
timedatectl

A server whose clock is off by more than a few minutes fails certificate validation in both directions.

6. Shared hosting or site builder

Most hosts issue and renew Let's Encrypt certificates from the control panel ("SSL/TLS", "Security", "Let's Encrypt"). Open it, check that the certificate covers both example.com and www.example.com, and click renew or reissue. If the panel says the certificate is valid but browsers disagree, the host has a reload or chain problem on their side.

When it is your host's problem

Hello, since about 06:00 UTC browsers show "Your connection is not private" (NET::ERR_CERT_DATE_INVALID) for my website example.com. The control panel shows a valid certificate, so the web server seems to serve an old one. Could you reload the certificate on the server and check the automatic renewal for my domain?

Preventing the next one

An expired certificate is the one outage with a known date. SSL certificate monitoring warns you before the expiry, and again if the chain or the name is wrong; 5 checks are free. On your own server, a quick fix renews the certificate where certbot is set up and reloads the web server, at a fixed price; a deep fix sets up renewal where there is none yet.