Understanding a TLS certificate chain

A public certificate normally participates in a chain: the leaf identifies the service, an intermediate authority links it to a trusted root, and the client decides whether that path is acceptable. The server usually sends the leaf and needed intermediate certificates; the root is commonly selected from the client’s trust store rather than sent by the server.

Why one client works and another fails

Different clients can have different trust stores, cached intermediates, or path-building behavior. A server that omits an intermediate may appear healthy from one machine and fail for another. Private roots and enterprise-managed trust stores can create the opposite result: an internal client succeeds while a public browser rejects the path.

Deployment checklist

Install the current leaf certificate and the complete required intermediate chain.
Do not assume the root certificate belongs in the server bundle.
Test through the real CDN, proxy, load balancer, and origin paths.
Compare results from a public client and the organization’s managed client profile.
Document which trust store and path-validation assumptions support the service.

Scope note: Certificate Inspector reports what its configured scanner trust store accepted. That is useful evidence, but it is not a universal statement about every browser, operating system, or private network.

Last reviewed: September 2026. Chain behavior depends on the client and current trust-store policy.