Your site loads fine with a padlock. Visitors report security warnings. The cause is usually an incomplete certificate chain — here's how to spot and fix it. Your SSL Works in Chrome But Not for Visitors — Here's Why

A customer emails to say your site is showing a security warning.

You open it. Padlock. Green. Fine.

You reply asking them to clear their cache, they say it's still broken, and the conversation goes nowhere useful. Meanwhile everyone who hit that warning and didn't bother emailing you has already left.

This is one of the most common SSL problems on the web, and the reason it's so persistent is that the person best placed to fix it is the least likely to see it.

Why your browser lies to you

An SSL certificate isn't one file. It's a chain.

At the bottom sits your certificate, issued for your domain. Above it sit one or more intermediate certificates. At the top sits a root certificate belonging to a certificate authority your browser already trusts.

For a browser to trust your site, it has to walk that entire chain from your certificate up to a root it recognises. Break any link and trust fails.

Your web server is supposed to send the intermediates along with your certificate. If it doesn't, the chain has a hole in it.

Here's the trap. Browsers cache intermediate certificates. If you've previously visited any other site using the same certificate authority, your browser already has that intermediate sitting in memory — so it quietly fills the gap and shows you a padlock.

Your visitor's browser hasn't. It sees a certificate signed by something it can't verify, and throws a full-page warning.

So the sites most likely to have this bug are the ones whose owners browse the web a lot. You've cached half the internet's intermediates. Your customers haven't.

This also explains a symptom that confuses people: the site works on desktop but fails on an Android phone, or in an API call, or on a payment gateway callback. Those clients have thinner caches, or none at all.

Finding out in thirty seconds

Run your domain through an SSL certificate checker that reports on the chain specifically, not just the expiry date.

A proper check connects fresh, with no cached intermediates, and reports:

• Who issued the certificate and when it expires
• Which hostnames it covers
• Whether the chain is complete
• Which TLS versions your server negotiates

That third one is the answer to this problem. If it says an intermediate is missing, fix it — even though the site looks perfect in your own browser. Especially then.

Fixing it

The fix is almost always to serve a bundled certificate file rather than just the leaf.

Your certificate authority provides the intermediates when they issue the certificate — usually as a separate .ca-bundle or chain.pem file. Where it goes depends on your server:

• Apache — point SSLCertificateChainFile at the bundle, or on newer versions concatenate the intermediates into the file referenced by SSLCertificateFile
• Nginx — Nginx expects one file, so concatenate your certificate and the intermediates in that order into the file used by ssl_certificate
• cPanel, Plesk or a hosting panel — there's a "Certificate Authority Bundle" box in the SSL installer. Leaving it blank is what causes this
• Let's Encrypt via Certbot — use fullchain.pem, not cert.pem. This single mistake accounts for a large share of broken chains

Then restart the web server. A reissued certificate that isn't picked up because nobody restarted the service is its own common failure.

Re-run the checker afterwards to confirm.

The other errors your visitors see

If someone sends you a screenshot, the error code tells you which problem you've got:

 | Error | What it actually means | Fix | NET::ERR_CERT_DATE_INVALID | Certificate expired — or the visitor's device clock is badly wrong | Check the expiry. If it's still valid, ask them to check their system date
| NET::ERR_CERT_COMMON_NAME_INVALID | The certificate doesn't cover the hostname they're visiting | Reissue covering every hostname you serve, including www.
| NET::ERR_CERT_AUTHORITY_INVALID | Self-signed, or an authority the browser doesn't trust — often an incomplete chain | Serve the full chain, or replace with a publicly trusted certificate
| SSL_ERROR_BAD_CERT_DOMAIN | Firefox's wording for a hostname mismatch | As above
| ERR_SSL_PROTOCOL_ERROR | Server and browser can't agree on a TLS version or cipher | Enable TLS 1.2 and 1.3
| No warning, but no padlock | Mixed content — an HTTPS page loading HTTP assets | Update those asset URLs to https://

That last row deserves attention because nothing breaks. The page loads, no warning appears, and the padlock simply isn't there. It's easy to ship and never notice — and it removes precisely the trust signal you installed the certificate to get.

What this actually costs you

You'll read that broken SSL tanks your search rankings. That's overstated, and it's worth being precise about, because the truth is bad enough on its own.

HTTPS is a confirmed Google ranking signal, but a light one. It won't lift you above a competitor with better content, and its absence won't bury you.

The real damage is more direct:

• Visitors leave. The interstitial is deliberately alarming. Most people click back, not "proceed anyway."
• Crawling degrades. If Googlebot can't fetch your pages reliably, your existing rankings decay — not from a penalty, but because your content stops being recrawled and refreshed.
• Conversions stop dead. Nobody types card details past a security warning.

So a broken certificate does cost you traffic and revenue. It just does it by driving people away, not by triggering an algorithmic demotion. Fix it because of what your visitors see.

Making sure it doesn't happen again

Automate renewal. Let's Encrypt certificates last 90 days and renew unattended. Manual annual renewals are the single biggest cause of surprise expiry — someone leaves the company, the reminder goes to their inbox, and the site breaks on a Saturday.

Check from outside, not from your browser. Your browser is the least reliable witness you have. Use a tool that connects fresh.

Set a reminder 30 days out, even with automation. Automation fails silently sometimes.

Enable TLS 1.2 and 1.3, disable everything older. TLS 1.0 and 1.1 were dropped by all major browsers in 2020.

Add HSTS once you're stable. The Strict-Transport-Security header tells browsers to refuse HTTP for your domain entirely. Add it only after renewals have been reliable for a while — browsers cache the policy and it's awkward to undo. Confirm it's being sent with an HTTP header checker.

Check monthly, and before every launch. Same routine as your other pre-launch checks.

The next time someone reports a security warning on a site that looks fine to you, don't ask them to clear their cache. Check the chain.

Run a free SSL check on your domain →