How certificate authorities and roots of trust work

A TLS certificate has an origin story. A service owner normally creates a key pair, sends a certificate signing request (CSR) containing the public key and requested names, proves control of the names, and receives a certificate signed by a certificate authority (CA). The client later validates that signature through a trust chain.

Root CA — trusted anchor in a client trust store │ signs ▼ Intermediate CA — usually signs subscriber certificates │ signs ▼ Leaf/server certificate — identifies api.example.com │ presented during TLS ▼ Client builds and validates a path to a trusted root

Who creates what?

Service owner: generates or receives an approved private key and keeps it protected. The corresponding public key and requested names go into the CSR.
Certificate authority: validates the requested identity or domain control, then signs a certificate containing the public key, names, validity period, constraints, and other extensions.
Server or managed edge: presents the leaf certificate and normally the required intermediate certificates during the TLS handshake.
Client: uses its trust store and path-building rules to decide whether a chain leads to an acceptable trust anchor.

Important: the CA does not need the subscriber’s private key to sign a normal CSR. The private key should remain with the service owner or approved key-management system.

Public and private certificate authorities

A public CA is recognized by common browsers, operating systems, or other published trust programs. A private CA is operated by an organization or provider for internal services and is trusted only where that organization’s root certificate has been deliberately installed.

“Remote CA” is not usually a separate trust category. An external CA may issue a public certificate, while a local or enterprise CA may issue an internal certificate. The deciding question is which root certificates the validating client trusts.

Root, intermediate, and leaf certificates

Root CA: a trust anchor distributed in a browser, operating system, device, or enterprise trust store. It is often self-signed and is normally not sent by the web server.
Intermediate CA: a delegated issuer signed by a root or another intermediate. It limits the exposure of the root key and is commonly sent by the server.
Leaf certificate: the endpoint identity certificate for a hostname. It is the certificate most people see when inspecting a website.

The structure is often drawn as a tree, but real path building can be more complicated. Cross-signing, alternate intermediates, different trust stores, and policy constraints can give clients more than one possible path.

Why a chain can work for one client and fail for another

The server omitted an intermediate that one client cached but another client does not have.
An enterprise client trusts a private root that public browsers do not recognize.
A public root was removed, expired, or constrained in one platform’s trust store.
A CDN, proxy, or load balancer serves a different leaf or chain than the origin.
Path-building or algorithm policy differs between operating systems and applications.

What Certificate Inspector can show

A remote scan can report the leaf identity, issuer information, names, validity, chain evidence, and the result of the configured scanner trust store. A locally uploaded certificate can reveal its fields, but a leaf file alone cannot prove that a remote client will build a trusted path. The inspector does not claim that its trust result represents every browser, private network, or enterprise policy.

Use the certificate chain guide for deployment troubleshooting, the hostname guide for SAN problems, and the deployment checklist after changing a certificate.

Last reviewed: October 2026. Trust stores, CA policies, browser behavior, and certificate profiles change over time; confirm consequential decisions against current platform and CA documentation.