Certificate authorities and chains

Who vouches for the issuer?

The clinic portal's certificate was signed by "Example TLS Issuing CA 2". To check that signature, Alex's browser needs the issuing CA's public key, and it needs a reason to trust that key. If the answer were another certificate, signed by another CA, the question would repeat. At some point the browser has to start from keys it already trusts.

Those starting points are root certificates, held in a trust store. Operating systems and browsers ship with a curated list of root CAs. To be included, a CA must meet the requirements of that platform's root program, which typically include regular independent audits and published rules for how it checks requests before issuing.

Following a chain

Root CAs rarely sign website certificates directly. Their private keys are too valuable to use every day, so they are usually kept offline and used occasionally to sign certificates for intermediate CAs. The intermediates do the daily work of issuing certificates to sites like the clinic's.

That creates a certificate chain. The clinic's certificate was signed by the intermediate. The intermediate's certificate was signed by the root. The root is in Alex's trust store.

When the portal's server starts a connection, it sends its own certificate and the intermediate certificate. The browser builds a path upward: it uses the intermediate's public key to check the signature on the clinic's certificate, then uses the root's public key from the trust store to check the signature on the intermediate. If each link verifies and the path ends at a trusted root, the chain is complete.

A common configuration mistake is sending only the server's own certificate. Some clients have seen the intermediate before, or can fetch it using the issuer address in the certificate, and connect without trouble. Others fail with an "unknown issuer" error. The fix belongs on the server: configure it to send the complete chain, not ask users or developers to trust the server certificate directly.

Trust anchors

A root certificate is signed by its own key. That self-signature proves nothing about trustworthiness, since anyone can create a self-signed certificate claiming any name. A root is trusted only because the platform chose to put it in the trust store. That is why roots are called trust anchors: the chain ends there by decision, not by proof.

That decision can be changed. Platforms remove roots from their stores when a CA repeatedly breaks the rules, and certificates chaining to those roots stop being trusted. The reverse is also possible. An organization can add its own root to managed laptops so they trust internal services. Malware, or a network inspection proxy, can add a root to make its own certificates acceptable for any site. Because a root in the store can vouch for any name, adding one is a significant security decision.

Keeping authorities in check

CA certificates carry constraints of their own. The basic constraints extension marks a certificate as a CA and can limit how many intermediate levels may appear below it. Name constraints can restrict a CA to issuing only for certain domains, which is useful when an organization is given a CA of its own.

Any trusted CA can technically issue a certificate for any name its constraints allow. If a CA is tricked or compromised into issuing a certificate for portal.harborclinic.example to someone else, the certificate would validate. Certificate Transparency makes that kind of mistake visible. CAs record the certificates they issue in public, append-only logs, and browsers require evidence of logging before accepting a publicly trusted certificate. The clinic can monitor those logs for certificates issued for its names and act on any it did not request.

Private PKI

Not every certificate needs to be trusted by the whole world. The clinic's internal services, its staff laptops, and the lab connection might use certificates from the clinic's own CA. This private PKI is trusted only by the systems configured to trust its root, which is exactly what the clinic wants for systems the public never visits.

Running a private CA means taking on the responsibilities a public CA would otherwise carry: protecting the root key, deciding who may request certificates for which names, issuing and renewing them, and revoking them when needed. The Advanced OAuth lessons on mutual TLS and the workload identity lessons use private PKI to identify applications and services rather than websites.

A chain that ends at a trusted root is necessary, but it is only one of the checks a client performs. Validating a certificate covers the rest.