"Your connection is not private": identifying which certificate fault you have

TL;DR: This warning is not one problem. Browsers show nearly identical wording for at least seven distinct faults, and the fix for each is different. The error code underneath the message — the part in small text that people skip — names which one you have.

Two of them deserve particular attention. An incomplete certificate chain works perfectly in desktop browsers, which cache intermediate certificates from other sites you have visited, and fails on mobile devices that have not. So the site looks fine to you and broken to a share of your visitors. And a wrong system clock produces this error on the visitor's device with nothing wrong on your server at all.

What the browser is actually checking

When a browser opens an HTTPS connection, it validates the certificate the server presents against several criteria. Failing any one produces the warning.

Validity dates. Is the current time between the certificate's not-before and not-after dates? Note that this depends on the visitor's clock, not yours.

Name match. Does the hostname in the address bar appear in the certificate's subject or subject alternative names? A certificate for example.com does not cover www.example.com unless both are listed.

Chain of trust. Can the browser build a path from your certificate through intermediate certificates to a root certificate it already trusts? Your server must supply the intermediates; browsers ship with roots, not intermediates.

Issuer trust. Is the root at the end of that chain in the browser's trust store?

Revocation status. Has the certificate been revoked?

The warning is intentionally alarming and deliberately hard to bypass, because the failure modes it protects against include interception. That is correct behaviour, but it means a trivial configuration fault presents to visitors as a security alarm, and most will leave rather than click through.

Which is why identifying the specific fault matters more than general advice about reinstalling the certificate.

Read the error code first

Below the warning text, browsers display a code. It is small, it looks like noise, and it is the single most useful piece of information available.

NET::ERR_CERT_DATE_INVALID — expired, not yet valid, or the client clock is wrong. NET::ERR_CERT_COMMON_NAME_INVALID — the hostname is not covered by the certificate. NET::ERR_CERT_AUTHORITY_INVALID — the chain does not reach a trusted root: incomplete chain, self-signed, or untrusted issuer. NET::ERR_CERT_REVOKED — the certificate was revoked. SSL_ERROR_BAD_CERT_DOMAIN — Firefox's equivalent of a name mismatch. ERR_SSL_PROTOCOL_ERROR — a handshake failure rather than a certificate fault, often a protocol or cipher mismatch. ERR_CERT_SYMANTEC_LEGACY or similar — a distrusted certificate authority.

Click through to the details view, which shows the certificate's issuer, subject, validity dates and the chain as the browser received it. That view answers most questions immediately.

Then test from outside your own machine. Free online SSL testing tools fetch your certificate from an independent network and report the full chain, validity, protocol support and configuration grade. This matters because your own browser may have cached intermediates that your visitors' devices have not, which hides the most commonly missed fault entirely.

Testing only from your own browser is how an incomplete chain survives for months.

Fault one: expired certificate

The most common cause and the most preventable.

Symptom: ERR_CERT_DATE_INVALID, and the certificate details show a not-after date in the past.

Why it happens. Manual certificates require renewal and reinstallation, and the reminder email goes to an address nobody monitors. Automated certificates renew themselves, but automation fails silently: a renewal hook that stopped working, a validation method that broke after a DNS change, a cron job removed during a migration, or a firewall rule blocking the validation request.

The fix for manual certificates: obtain a new one and install it, including the intermediate chain, then restart the web server. Verify externally afterwards.

The fix for automated certificates: trigger a renewal manually and read the output, which usually names the reason automation failed. Common causes are the HTTP validation path being blocked by a redirect or a security rule, DNS validation failing after a nameserver change, or the renewal timer no longer running.

The important follow-up: find out why the automation stopped rather than just renewing. A manual renewal that fixes today's outage without fixing the automation means the same outage in ninety days.

Prevention: external expiry monitoring that alerts weeks in advance, independent of your host's own tooling. Automated renewal handles this in normal operation, and monitoring catches the case where it silently stops. The free versus paid SSL comparison covers why automated short-lived certificates are more reliable in practice than long manual ones.

Fault two: name mismatch

Symptom: ERR_CERT_COMMON_NAME_INVALID, and the certificate details show a subject that does not include the hostname you requested.

The most common case in practice: a certificate covering example.com but not www.example.com, or vice versa. The site works on one and warns on the other, and whoever tested only used the working one.

Other cases:

A new subdomain added without extending the certificate, so shop.example.com presents the certificate for the main domain.

A wildcard certificate covering *.example.com being used for a deeper subdomain such as a.b.example.com, which wildcards do not cover, or for the bare domain, which wildcards do not cover unless explicitly included.

Multiple sites on one server where the wrong certificate is served by default because virtual host configuration is incomplete.

A CDN or load balancer presenting its own certificate for a hostname it has not been configured for.

The fix: issue a certificate covering every hostname visitors actually use. For most sites that means both the bare domain and www. For multiple subdomains, either a wildcard or a certificate listing each name in its subject alternative names.

Then normalise. Redirect one canonical form to the other so visitors consistently land on the covered hostname, which reduces exposure to this class of error and is good practice regardless, as covered in the HTTP to HTTPS migration guide.

Fault three: incomplete chain

The fault that hides from you and breaks for your visitors.

Symptom: ERR_CERT_AUTHORITY_INVALID, and external testing reports a missing or incomplete chain, while the site loads fine in your own desktop browser.

Why the asymmetry. Certificates are issued by intermediate authorities, which are themselves signed by roots. Browsers ship with root certificates but not intermediates. Your server is supposed to send the intermediate along with your certificate so the browser can build the full path.

If it does not, desktop browsers frequently succeed anyway, because they cached that intermediate from another site or fetch it automatically. Mobile browsers and apps often do neither, so they fail.

The result is a site that works perfectly on your laptop and shows a security warning on a share of mobile devices. Since most Indian traffic is mobile, this is not a minor edge case.

How it happens: installing only the certificate file when the provider supplied both a certificate and a chain or bundle file, pasting the wrong file into a control panel field, or a migration that copied the certificate but not the intermediates.

The fix: install the full chain. Providers supply either a separate intermediate bundle or a combined full-chain file. If your panel offers separate fields for certificate and CA bundle, both must be populated. Then restart the web server and re-test externally.

Always verify externally after any certificate installation. This is the fault that testing from your own browser will not reveal, and it is common enough that it should be a standing step rather than an occasional check.

Fault four: self-signed or untrusted issuer

Symptom: ERR_CERT_AUTHORITY_INVALID, with certificate details showing the issuer is the same as the subject, or an authority the browser does not recognise.

Self-signed certificates are generated locally without any authority vouching for them. They encrypt the connection but prove nothing about identity, so browsers reject them.

Legitimate uses: local development, internal tools behind a VPN, and testing. Never appropriate for a public site.

Common accidental cases: a host installing a temporary self-signed certificate at provisioning that was never replaced, a default server certificate being served because virtual host configuration is incomplete, or a staging configuration copied to production.

Untrusted issuers occur where a certificate authority has been distrusted by browsers, which has happened to several authorities over the years following compliance failures. Certificates from a distrusted authority stop working regardless of their validity dates.

The fix: replace with a certificate from a currently trusted authority. Free automated certificates from a widely trusted CA are the straightforward answer for the vast majority of sites.

Never instruct visitors to click through the warning. Beyond being poor practice, it trains people to dismiss exactly the warning that protects them from interception, and most will leave rather than comply.

Fault five: the visitor's clock is wrong

The case where nothing is wrong with your site at all.

Symptom: ERR_CERT_DATE_INVALID on a certificate that external testing confirms is valid, affecting one visitor or a small number rather than everyone.

Certificate validity is checked against the client device's clock. If that clock is substantially wrong — a phone with the date set incorrectly, a computer whose CMOS battery has died, a device restored from an old image — every certificate on the internet appears invalid to it.

The signal: a single user reports the error while the site works for everyone else and tests clean externally.

The fix is on their device: correct the date and time, and enable automatic time synchronisation.

Why this matters to you as a site owner: it is worth knowing because a support ticket saying "your site shows a security error" does not distinguish this from a real fault. Testing externally takes a minute and tells you whether to investigate your server or ask the visitor to check their clock.

The related server-side case: if your own server's clock drifts significantly, certificate issuance and validation can fail, and log timestamps become unreliable for correlation during incidents. Ensure NTP is synchronising, which is part of the new VPS checklist.

Error code	Fault	Affects	Fix location
ERR_CERT_DATE_INVALID	Expired certificate	Everyone	Server: renew and fix automation
ERR_CERT_DATE_INVALID	Client clock wrong	One visitor	Visitor's device
ERR_CERT_COMMON_NAME_INVALID	Hostname not covered	One hostname	Server: reissue covering all names
ERR_CERT_AUTHORITY_INVALID	Incomplete chain	Mostly mobile	Server: install full chain
ERR_CERT_AUTHORITY_INVALID	Self-signed	Everyone	Server: obtain a real certificate
ERR_CERT_AUTHORITY_INVALID	Distrusted issuer	Everyone	Server: reissue from trusted CA
ERR_CERT_REVOKED	Certificate revoked	Everyone	Server: reissue, investigate why
ERR_SSL_PROTOCOL_ERROR	Handshake failure	Varies	Server: protocol and cipher config
Warning on one network only	Interception proxy	Users on that network	Network administrator

Fault six and seven: interception and mixed content

Interception. Corporate networks, some antivirus products and some public Wi-Fi deploy proxies that terminate TLS and re-sign traffic with their own certificate. On a managed corporate device that root is installed and everything works; on an unmanaged device it produces a warning.

The signal: the error occurs only on a specific network, and the certificate details show an issuer that is a security product or a company name rather than a public certificate authority.

Nothing to fix on your server. If this is genuinely happening on an untrusted public network rather than a managed corporate one, the warning is doing exactly its job and the connection should not be trusted.

Mixed content is a distinct issue that produces a broken padlock rather than a full warning page. An HTTPS page loading resources over plain HTTP causes browsers to block scripts and stylesheets and warn about images.

The signal: the page loads, but the padlock is struck through or replaced with a warning icon, and the browser console lists mixed content messages naming the offending resources.

The fix: update the HTTP references, which typically live in hardcoded theme files, plugin settings holding external URLs, custom CSS backgrounds, and third-party scripts. Add an upgrade-insecure-requests policy as a backstop, though it does not help where a resource genuinely does not exist over HTTPS.

This is covered in more depth in the HTTPS migration guide, since mixed content is most often a migration leftover.

Preventing certificate outages

Use automated renewal. Short-lived automated certificates renew without human involvement, which removes the most common failure entirely. Long manual certificates fail because someone has to remember, and eventually nobody does.

Monitor expiry externally. Independent of your host's tooling, with alerts weeks in advance. Automation covers normal operation; monitoring catches silent automation failure.

Verify externally after every certificate change. This is the standing habit that catches incomplete chains, which your own browser will not reveal.

Cover every hostname. Bare domain and www at minimum, plus every subdomain in use. Reissue when adding a subdomain rather than discovering the gap from a visitor.

Test on mobile, not only desktop, since chain problems present asymmetrically and most Indian traffic is mobile.

Keep server time synchronised so issuance and validation are reliable and logs correlate properly.

Document your setup. Which certificates exist, which hostnames each covers, how renewal happens, and where the automation lives. A certificate outage during a staff change is common precisely because nobody documented this.

Check after migrations. Certificates do not transfer between hosts automatically, and the new host usually needs to issue fresh ones once DNS points at it. A brief certificate warning immediately after a migration is normal; a persistent one is not.

FAQs

What does "Your connection is not private" mean?

It means the browser could not validate the site's certificate against one of its checks: validity dates, hostname coverage, chain of trust, issuer trust, or revocation status. The wording is nearly identical for all of these, so the error code beneath the message is what tells you which fault you actually have.

How do I find out which certificate error I have?

Read the error code below the warning text. ERR_CERT_DATE_INVALID means expired or a wrong client clock, ERR_CERT_COMMON_NAME_INVALID means the hostname is not covered, and ERR_CERT_AUTHORITY_INVALID means the chain does not reach a trusted root. Then test with an external SSL checker rather than relying on your own browser.

Why does my SSL work on desktop but fail on mobile?

Almost certainly an incomplete certificate chain. Your server should send the intermediate certificate alongside your own, but desktop browsers often succeed anyway because they cached that intermediate from another site. Mobile devices frequently have not, so they fail. Install the full chain and verify with an external SSL testing tool.

Why does my certificate cover example.com but not www.example.com?

Because a certificate only covers the hostnames listed in its subject and subject alternative names. Covering the bare domain does not automatically cover www, and a wildcard for *.example.com does not cover the bare domain unless explicitly included. Reissue covering every hostname visitors actually use.

My certificate is valid but one visitor still sees the error. Why?

Most likely their device clock is wrong. Certificate validity is checked against the client's system time, so a phone or computer with a substantially incorrect date will reject every certificate on the internet. Test your site with an external SSL checker to confirm it is valid, then ask them to enable automatic time synchronisation.

Why did my Let's Encrypt certificate expire when it should auto-renew?

Automation failed silently. Common causes are the HTTP validation path being blocked by a redirect or security rule, DNS validation breaking after a nameserver change, a renewal timer removed during a migration, or a firewall blocking the validation request. Trigger a renewal manually and read the output, then fix the automation rather than only the certificate.

Can I use a self-signed certificate on a public website?

No. Self-signed certificates encrypt the connection but no authority vouches for the identity, so every browser rejects them with a warning most visitors will not click through. They are appropriate for local development and internal tools behind a VPN. Free certificates from a trusted authority are the correct answer for public sites.

What is mixed content and how is it different from this error?

Mixed content is an HTTPS page loading resources over plain HTTP, which produces a broken padlock rather than a full warning page. The site still loads, but scripts and stylesheets loaded insecurely are blocked. It is a separate issue from certificate validation and is usually a leftover from an HTTPS migration.

Why does the error only appear on my office network?

Likely a TLS interception proxy, used by some corporate networks, antivirus products and public Wi-Fi, which terminates the connection and re-signs it with its own certificate. Check the certificate details: if the issuer is a security product or company name rather than a public authority, that is what is happening. Nothing to fix on your server.

Should I tell visitors to click "Proceed anyway"?

No. Beyond looking unprofessional, it trains people to dismiss the exact warning that protects them from connection interception, and most visitors will leave rather than click through. Fix the underlying certificate fault instead; every one of them has a straightforward remedy.

Do I need to reinstall my certificate after migrating hosts?

Usually yes. Certificates do not transfer between hosts automatically, and most hosts issue a fresh one once DNS points at the new server. A brief warning immediately after a migration while issuance completes is normal. A persistent one means the certificate was not issued or the chain was not installed.

How do I stop certificates from expiring again?

Use automated renewal with short-lived certificates, which removes human memory from the process entirely. Add external expiry monitoring that alerts weeks in advance, independent of your host's own tooling, so you catch the case where automation stops silently. Verify externally after any certificate change.

Conclusion

The warning looks like one problem and is at least seven, which is why generic advice to reinstall the certificate helps about a third of the time.

Read the error code. It is small, it is easy to skip, and it names the fault in three seconds. Then test with an external SSL checker rather than your own browser, because your browser has cached intermediates that your visitors' phones have not.

That last point is the one worth carrying away. An incomplete chain is invisible from a desktop and breaks the site for a meaningful share of mobile visitors, and since most Indian traffic is mobile, it is a real revenue problem hiding behind a site that looks perfect to you. Verifying externally after every certificate change turns that from a silent fault into a five-second check.

Expiry is the other big one, and it is entirely solvable with automated short-lived certificates plus independent monitoring. Automation handles the normal case; monitoring catches the day automation quietly stops.

And when a single visitor reports the error while everything tests clean, check their clock before you check your server.

HostCloud includes free SSL with automatic renewal and full chain installation on every plan, covering both the bare domain and www, on Indian infrastructure with HTTP/3 enabled. Plans from ₹99 a month at https://hostcloud.in.