Your Connection Is Not Private: Reading the Error Instead of Clicking Through

This warning means the browser could not verify that the certificate presented belongs to the site you asked for, and the small error code underneath it tells you exactly why, which is the part almost nobody reads.

The interstitial is deliberately alarming and deliberately vague, because it is written for people who should not proceed. But there is a short code beneath the message, and that code turns a generic scare into a specific, usually mundane, diagnosis: an expired certificate, a wrong clock, a missing intermediate, or a captive portal.

This covers what each code means, what a visitor can do, and what a site owner should check.

Table of contents

• Find the code first
• If you are the visitor
• If you own the site: the name mismatch
• If you own the site: expiry and the incomplete chain
• Making this stop happening
• How this fits the rest of the stack
• FAQ

Find the code first

Before anything else, get the specific error. It is under the headline text, and on some browsers you need to expand the advanced section to see it.

The five you will actually encounter:

• ERR_CERT_DATE_INVALID: the certificate is outside its validity window. Either it expired, or your device’s clock is wrong.
• ERR_CERT_COMMON_NAME_INVALID: the certificate is valid but does not cover this hostname. Usually the apex versus www mismatch.
• ERR_CERT_AUTHORITY_INVALID: the browser does not trust whoever signed it. Self-signed, an internal authority, or a missing intermediate certificate.
• ERR_CERT_REVOKED: the certificate was revoked before expiry. Rare and worth taking seriously.
• ERR_CERT_SYMANTEC_LEGACY and similar named-authority errors: the issuing authority lost browser trust. Historic but still appears on neglected sites.

The distinction that matters most is between a problem on your device and a problem on the server. A date error where your clock is wrong is yours. A name mismatch is the site’s. Establishing which side owns it saves everyone time.

If you are the visitor

Work through these in order, because the first two resolve the large majority of cases and take seconds.

1. Check your clock. A device with the wrong date sees every valid certificate as expired or not yet valid. This is the single most common cause on a phone that has been off, a fresh virtual machine, or a device with a dead battery.
2. Try the same site on another network. If it works on mobile data and fails on the office network, something on that network is intercepting traffic, which is normal for corporate proxies and not normal in a coffee shop.
3. Look for a captive portal. Public networks intercept the first request to force a login page, and that interception breaks TLS. Visit any plain HTTP address and see whether a login page appears.
4. Try a private window. This rules out an extension interfering with connections.
5. Check whether your antivirus inspects HTTPS. Several security products install a local root certificate and decrypt traffic. When that goes wrong it produces exactly this warning.

On the question of clicking through: do not, on any site where you will type something. The warning means you cannot verify who you are talking to, and a password entered past that screen may be going anywhere. For a site where you only read public content, the risk is lower but the guarantee is still absent.

Be especially careful on a public network. That is the exact environment where interception is plausible rather than theoretical.

If you own the site: the name mismatch

The most common owner-side cause is a certificate that does not cover the hostname visitors are actually using.

Typically the certificate was issued for example.com and someone visits www.example.com, or the reverse. Both need to be in the Subject Alternative Name list, because the legacy Common Name field is ignored by modern browsers.

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

Reissue covering both names, then redirect one to the other so there is a single canonical hostname. Do the redirect after the certificate covers both, not before, or the redirect itself hits the warning.

The same problem appears on subdomains. A wildcard certificate for *.example.com covers api.example.com but does not cover the bare example.com, and it does not cover a.b.example.com either, because wildcards match one label only.

If you own the site: expiry and the incomplete chain

Expiry is self-explanatory and entirely preventable. What is worth saying is that the automation failing silently is the normal failure mode, not the exception.

The usual causes: the renewal challenge cannot reach the server because a redirect forces HTTPS on every path including the challenge path, the renewal timer was never enabled, or the certificate renewed on disk and the web server was never reloaded.

# Is the renewal timer actually scheduled?
systemctl list-timers | grep -i certbot

# Does a dry run succeed?
sudo certbot renew --dry-run

Monitor expiry from outside your own infrastructure and alert at 21 days, not at 2. A check running on the same machine as the certificate will not tell you when that machine is the problem.

The incomplete chain is the subtler one, and it produces the most confusing support conversations. Your server must send its own certificate plus every intermediate. Browsers often paper over a missing intermediate by filling it in from a cache built visiting other sites, so the site works for you and fails for a colleague, a mobile app, or a fresh CI runner.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>&1 \
  | grep -E 'Verify return code|s:|i:'

You want the leaf, then one or more intermediates, and a final Verify return code: 0 (ok). Anything else is a chain to fix regardless of what your own browser shows.

Making this stop happening

The target is that certificates are not something anyone on the team thinks about, and getting there means deleting manual steps rather than doing them more reliably.

• Automated issuance and renewal, with the web server reload wired into the same hook so a renewed file is actually served.
• External expiry monitoring with a three-week warning.
• One certificate covering both apex and www, so the canonical redirect never hits a mismatch.
• An exception in your HTTPS redirect for the challenge path, so renewals can validate.
• HSTS only once you are confident, starting with a short duration.

On a managed platform none of this is a project. Attaching a custom domain to a RunxBuild service provisions and renews the certificate as part of the domain setup, which removes the timer, the reload hook and the expiry alarm in one step. The custom domains and certificates docs cover the records involved.

How this fits the rest of the stack

Certificate handling costs nothing in money and a surprising amount in attention, and attention is the expensive kind of cost. When sizing a deployment it is worth knowing which pieces arrive handled, and the RunxBuild hosting calculator covers the priced parts while the certificate comes with the domain rather than as separate work to schedule and monitor.

Useful related references:

• Private Methods in Python: There Are None, and That Is Fine
• Begin OpenSSH Private Key: Format, Generation, and Conversion
• SSH Using a Private Key: The -i Flag Is the Wrong Long-Term Answer
• Database connection limits on RunxBuild

FAQ

Is it safe to click through this warning?

Not on any site where you will enter information. The warning means the browser cannot verify who is on the other end, so a password typed past that screen may be going to an interceptor. On a public network in particular, treat it as a stop rather than a speed bump.

Why does the error only happen on one device?

Almost always a device-side cause: a wrong system clock, an antivirus product inspecting HTTPS traffic, a browser extension, or a network intercepting connections. Test the same site on a different network to separate the device from the site.

What does ERR_CERT_COMMON_NAME_INVALID mean?

The certificate is valid but does not list the hostname being visited. The usual case is a certificate issued for the bare domain while the visitor used the www prefix, or the reverse. Reissue covering both names, then redirect one to the other.

Why does my site work in my browser but fail for others?

Most likely an incomplete certificate chain. Your server is not sending the intermediate certificate, and your browser fills it in from a cache built while visiting other sites. A fresh client has no such cache and fails. Check with openssl s_client and the showcerts flag.

How do I stop certificates expiring?

Automate issuance and renewal, wire the web server reload into the renewal hook, exempt the challenge path from your HTTPS redirect, and monitor expiry from outside your own infrastructure with an alert three weeks ahead. The common failure is not forgetting to renew but automation failing silently.