Certificates and TLS

Why is my SSL certificate not trusted?

“Your connection is not private” is one message covering six unrelated faults, and the fix for each is different. The certificate itself is usually fine.

In roughly this order of frequency: the server is not sending the intermediate certificate, so the browser cannot build a chain to a trusted root; the hostname is not listed in the certificate’s Subject Alternative Names; the certificate has expired; the client or server clock is wrong; the certificate is self-signed; or the issuing CA has been distrusted. The first cause is by far the most common and has a distinctive signature — the site works in one browser and fails in another, or works on a desktop and fails on a phone — because some clients cache intermediates from previous visits and others do not.

Worked out 2026-09-11 (IST) · publicly trusted certificates and mainstream browser trust stores

Diagnosing from the error message

Browser message to cause
You see	Cause	Where to fix it
ERR_CERT_AUTHORITY_INVALID, "issuer is unknown"	Intermediate chain not served, or a private CA	Web server config — serve the full chain file
ERR_CERT_COMMON_NAME_INVALID	Hostname not in the SAN list	Reissue with every name you serve
ERR_CERT_DATE_INVALID, "expired"	Past notAfter, or the client clock is wrong	Renew; if only one machine complains, fix its clock
NET::ERR_CERT_REVOKED	The CA revoked this certificate	Reissue; find out why it was revoked
"Not secure" with no certificate error	Mixed content — HTTP assets on an HTTPS page	Page source, not the certificate
Works in a browser, fails in curl or an API client	Missing intermediate, cached by the browser	Web server config

The chain, and why it breaks

Trust is a chain of signatures: a root certificate that already ships inside the operating system or browser signs an intermediate, and the intermediate signs the certificate for your site. The browser has the root. It does not have the intermediate, and it will not go looking for one reliably, so your server must send it alongside the leaf.

What your server should send
Position	Certificate	Sent by your server?
Leaf	Issued for your host names	Yes
Intermediate	The CA's signing certificate	Yes — this is the one people forget
Cross-signed intermediate	For compatibility with older devices	Sometimes, if your CA supplies one
Root	Already in the client trust store	No — sending it wastes bytes and proves nothing

Certificate authorities usually ship two files: the certificate and a bundle, sometimes named fullchain.pem or ca-bundle.crt. Configuring the first without the second produces exactly this fault, and it is silent on the machine you tested from.

The one-minute triage

Check in this order
Check	What a good answer looks like
Is the certificate currently within its validity window?	notBefore in the past, notAfter comfortably in the future
Is the exact hostname visitors use in the SAN list?	Both apex and www, if you serve both
Does the server send an intermediate?	Chain length of at least two
Is the issuer a CA in public trust stores?	A recognised commercial or free CA, not your own name
Do the server and client clocks agree?	Within a few minutes; NTP running on both
Is a CDN or proxy terminating TLS instead?	Then the certificate to fix is the edge's, not the origin's

Lifetimes changed in March 2026 and change again in 2027 and 2029 — see how long an SSL certificate is valid for.

Sources: CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, including ballot SC-081v3 “Introduce Schedule of Reducing Validity and Data Reuse Periods” (passed April 2025); IETF RFC 5280 and RFC 6125.

Check your own numbers

Check the issuer, the chain, the SAN list and the validity window for any hostname.

SSL CheckerCertificate issuer, validity window, days remaining and chain.

Frequently asked

Why does it work in Chrome but not on my phone or in curl?

That is the missing-intermediate signature almost every time. Desktop browsers cache intermediate certificates they have seen before, and some will fetch a missing one using the Authority Information Access extension. A fresh device, a command-line client or a server-to-server API call has no cache and no fetching behaviour, so it sees a broken chain. Your certificate is fine; your server is serving only the leaf.

Is a self-signed certificate insecure?

The encryption is identical - the same algorithms, the same key sizes. What a self-signed certificate lacks is any third party attesting that you are who you claim, so a client cannot distinguish it from one an attacker generated. That is fine for a device on your own network where you install the certificate deliberately, and useless on the public internet where visitors have no way to verify it.

I renewed the certificate and it still shows as expired.

The new certificate is almost certainly not the one being served. Either the web server was not reloaded after the files were replaced, or it is reading a different path than the one you updated, or a CDN or load balancer in front of it holds its own copy that also needs renewing. Check what is actually presented on the wire rather than what is on disk - they disagree more often than you would expect.

What is a name mismatch, exactly?

A certificate lists the names it is valid for in its Subject Alternative Name extension. If a visitor arrives at a name not in that list, the browser rejects it even though the certificate is otherwise perfect. The classic case is a certificate issued for example.com only, then reached at www.example.com - those are different names, and a wildcard *.example.com covers the second but not the first.

Need domain and DNS checks inside your own product?

We build WHOIS, RDAP, DNS and SSL lookups as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.