Why your valid SSL cert still fails on some browsers

You renewed the certificate. Chrome on your laptop shows the padlock. Then a customer emails a screenshot from their phone: "Your connection is not private." You check again on your machine and everything looks fine.

This failure mode is confusing because "valid" is not a property of the certificate alone. Validity is a verdict each browser reaches on its own, using its own rules, its own trust store, and whatever certificates your server actually sent it. Two browsers looking at the same site can reach opposite conclusions, and both are following their rules correctly.

Browsers do not validate certificates the same way

When a browser connects to your site, your server hands over a certificate. The browser then has to build a chain of trust from that certificate up to a root certificate it already trusts, following the path validation rules defined in RFC 5280.

Every link in that reasoning can differ between browsers:

• The trust store differs. Firefox ships its own root store. Chrome uses its own root store on most platforms. Safari uses Apple's. Older Android versions use whatever shipped with the OS and never receive updates.
• The chain-building behavior differs. Some browsers will go fetch a missing intermediate certificate on their own. Others will not.
• The policy layer differs. Browsers add requirements on top of basic validation: Certificate Transparency logging, maximum certificate lifetimes, and distrust decisions against specific certificate authorities, each rolled out on its own schedule.

So the question is never "is the certificate valid?" It is "which validation step is failing in that specific browser?" The causes below cover nearly every real-world case.

Cause 1: the missing intermediate certificate

This is the most common culprit by a wide margin.

Your certificate was not signed directly by a trusted root. It was signed by an intermediate certificate, which was signed by the root. Browsers need the full chain to verify trust, and your server is supposed to send the intermediate along with your own certificate (often called the leaf certificate).

If your server only sends the leaf, behavior splits:

• Chrome and Safari can often recover. They use the Authority Information Access (AIA) field inside the certificate to download the missing intermediate on the fly, or they find it in a cache from a previous site that served it correctly.
• Firefox does not fetch missing intermediates over the network, but it ships with a preloaded set of common intermediates, so it frequently succeeds anyway.
• Older Android devices, many mobile apps, and most non-browser clients (curl, API consumers, payment webhooks, monitoring tools) do no fetching at all. They see an incomplete chain and fail hard.

This explains the maddening "works for me" pattern. Your desktop browser has either fetched or cached the intermediate, so the site loads. A first-time visitor on an Android phone gets the error. The misconfiguration is on your server the entire time; some browsers are just quietly papering over it.

The fix is server-side: serve the full chain. Most certificate issuers provide a "full chain" or "bundle" file for exactly this reason. On nginx, that bundled file goes in the ssl_certificate directive. On Apache, modern versions take the full chain in SSLCertificateFile.

Cause 2: outdated root stores on older devices

A certificate chain is only trusted if it terminates at a root the device already has. Devices that stopped receiving updates are frozen with the root store of their era.

The clearest historical example: in September 2021, the DST Root CA X3 certificate expired. Let's Encrypt certificates had chained to it for years. Devices that had received updates carried the newer ISRG Root X1 root and were fine. Android devices running versions older than 7.1.1 did not have that root and began rejecting millions of perfectly valid certificates overnight.

The same dynamic applies to old smart TVs, embedded browsers, kiosk systems, and any OS past its support window. Your certificate is valid; the device's idea of "trusted roots" is simply years out of date.

You cannot fix the client, but you can choose chains wisely. Some certificate authorities offer cross-signed chains that remain compatible with older devices. If a meaningful slice of your audience is on legacy hardware, that chain choice matters more than anything else in this article.

Cause 3: the browser has distrusted your certificate authority

Browsers occasionally stop trusting a certificate authority entirely, and they do it on independent timelines.

Symantec-issued certificates were distrusted across major browsers through 2018. More recently, in 2024, Chrome and Firefox both announced they would stop trusting new certificates issued by Entrust, each with its own cutoff date. A certificate issued by an affected CA after one browser's cutoff but before another's will literally be valid in one browser and rejected in the next.

If your certificate fails only in one browser family, and the chain checks out, look up your issuing CA's current standing with that browser's root program. The fix is reissuing from a CA in good standing across all major root programs.

Cause 4: Certificate Transparency requirements

Chrome and Safari require publicly trusted certificates to be logged in Certificate Transparency (CT) logs, with proof embedded as Signed Certificate Timestamps (SCTs). Firefox began enforcing CT more recently. A certificate that is cryptographically sound but missing the required SCTs will be rejected by enforcing browsers with an error like ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, while a non-enforcing client accepts it without complaint.

Any reputable public CA handles CT logging automatically today. Where this bites is internally issued certificates accidentally exposed to the public internet, certificates from regional or niche CAs, and very old certificates issued before enforcement deadlines.

Cause 5: the boring ones that still happen

Before assuming something exotic, rule these out:

• Hostname coverage. The certificate covers www.example.com but not the bare example.com, or vice versa. A wildcard like *.example.com covers one subdomain level only: app.example.com yes, staging.app.example.com no.
• TLS version mismatch. Modern browsers refuse TLS 1.0 and 1.1. If your server's protocol support is outdated, the handshake fails before the certificate is even evaluated, and users see what looks like a certificate error.
• The visitor's clock. A device with a wrong system date will see every certificate as expired or not yet valid. If exactly one user reports the problem and nothing reproduces it, ask them to check their device clock.
• Multiple servers behind one name. Load-balanced setups sometimes have one node serving a stale or incomplete chain while the others are correct. Failures appear random because they depend on which node answers.

How to diagnose it in five minutes

Work from the server outward:

1. Inspect what your server actually sends. Run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts. You should see at least two certificates: your leaf and the intermediate. One certificate means an incomplete chain, and you have found your answer.
2. Test from a clean client, not your daily browser. Your own browser's intermediate cache hides chain problems. A private window does not clear that cache; a different device on mobile data is a far more honest test.
3. Check both hostname variants. Test https://example.com and https://www.example.com separately. They can be served different certificates.
4. Note the exact error code. ERR_CERT_AUTHORITY_INVALID points at chain or trust store issues. ERR_CERT_COMMON_NAME_INVALID points at hostname coverage. The code narrows the search considerably.

Catch it before your visitors do

Chain completeness is exactly the kind of problem manual checks miss, because the browser you test with compensates for it. The AcuityScan SSL check validates your certificate the strict way: full chain verification, expiry, hostname coverage, and protocol support, without a cache to paper over gaps. Since HTTPS problems often travel with weak security headers, the HTTP headers tool is a worthwhile follow-up to confirm HSTS and friends are in place.

For the full picture, run a free scan at acuityscan.com. It runs 350+ checks across 8 modules, covering SSL alongside security headers, DNS, email authentication, performance, and accessibility, and returns specific findings with plain-English fixes.

TL;DR

• "Valid" is a per-browser verdict, not a property of the certificate. Different trust stores, chain-building behavior, and policies produce different results for the same cert.
• The most common cause is an incomplete chain: your server sends the leaf without the intermediate, and only some browsers compensate.
• Old devices fail on valid certificates because their root stores are frozen in time. Chain selection is your only lever there.
• Browsers distrust certificate authorities on independent schedules, so a cert can pass in Firefox and fail in Chrome, or the reverse.
• Missing Certificate Transparency logging fails in enforcing browsers and passes everywhere else.
• Diagnose with openssl s_client -showcerts from a clean client, and always test both the www and bare-domain variants.