Your Connection Is Not Private (SSL): How to Diagnose and Fix

The “Your connection is not private” warning in Chrome (or “Warning: Potential Security Risk Ahead” in Firefox) is one of the most ambiguous screens on the modern web. Behind a single friendly message, the browser hides more than fifteen distinct error codes — each pointing to a different root cause. Treating them all as the same problem leads to wrong attempts: renewing a certificate that is still valid, touching DNS when the problem is the clock, or worse, instructing the end user to click “Proceed” and expose the connection.

This guide is for those who operate their own server (VPS or bare-metal) and need to quickly identify the real problem, separate what is the server’s responsibility from what is the client’s, and apply the correct fix. The full process takes between 10 and 20 minutes, depending on the cause.

The fundamental premise: SSL errors are always specific. Before touching any configuration, you need to read the exact code the browser shows and decide on the diagnostic path.

Prerequisites

Identify the exact error code

Before touching anything, open the error page in the browser and click “Advanced” (Chrome) or “Technical details” (Firefox). You will see a code in the format NET::ERR_CERT_* or SEC_ERROR_*. That code is the starting point — each one requires different treatment.

The table below covers the most common ones:

Diagnose from the server side

Use openssl s_client to see exactly what the server is presenting to the browser. This command is the technical equivalent of “opening the page” — no cache, no extensions, no ambiguity.

openssl s_client -connect domain.com:443 \
  -servername domain.com \
  -showcerts < /dev/null

echo | openssl s_client -connect domain.com:443 \
  -servername domain.com 2>/dev/null | \
  openssl x509 -noout -dates -subject -ext subjectAltName

Fix incomplete chain issues

An incomplete chain is the most common configuration error on Linux servers. You generated the certificate, copied it to nginx, and everything seems OK — but the server is serving only the leaf, without the intermediate.

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

sudo nginx -t && sudo systemctl reload nginx

Fix date and clock issues

If the code is NET::ERR_CERT_DATE_INVALID, there are two possibilities: the certificate has actually expired (server) or the client clock is wrong (local). Differentiating is straightforward.

timedatectl status

sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd

date -u
echo | openssl s_client -connect domain.com:443 \
  -servername domain.com 2>/dev/null | \
  openssl x509 -noout -enddate

Verify the fix worked

After applying the fix, validate on three layers — server, public chain, and a real browser.

curl -sI https://api.ssllabs.com/api/v3/analyze?host=domain.com

Common troubleshooting

Error only appears on www but not the root (or vice versa)

Your certificate covers only one of the two. Reissue including both names. With certbot:

sudo certbot --nginx -d domain.com -d www.domain.com

The -d flag accepts multiple domains in a single request — they all go into the same certificate via SAN.

Error after installing antivirus or corporate proxy

Antivirus software that performs TLS inspection (Kaspersky, BitDefender, ESET) installs its own CA on the machine and re-signs all HTTPS traffic. If this CA is not in the browser trust store, every site breaks. Solution: disable SSL inspection in the antivirus or accept its CA manually. On corporate networks with proxies (Zscaler, Forcepoint), the IT team needs to distribute the company CA via group policy.

Automatic renewal stopped working

Check the certbot cron and the logs:

sudo systemctl status certbot.timer
sudo journalctl -u certbot --since "30 days ago"

Common causes: port 80 blocked by the firewall (HTTP-01 challenge fails), DNS pointing to the wrong IP after a migration, or Let’s Encrypt rate limiting (5 failures per hour per domain).

Next steps

After resolving the immediate error, it is worth hardening the TLS configuration to prevent recurrence. Consider enabling HSTS (HTTP Strict Transport Security) with Strict-Transport-Security: max-age=31536000; includeSubDomains — this forces the browser to use HTTPS for a year and eliminates downgrade attacks. Monitor certificate expiration with tools like Uptime Kuma or a simple cron that fires an alert 14 days before notAfter. For sites with serious traffic, enable OCSP stapling (ssl_stapling on in nginx) — it reduces first-connection latency and decreases dependency on the CAs.

If you are putting this into production, a Hostini VPS comes with certbot pre-installed and automatic renewal already configured — you just point DNS and run the issuance command.