Security

What is chain of trust?

A chain of trust is the sequence of signed certificates linking a server's leaf certificate through intermediate CAs to a root already in the trust store.

What is a chain of trust?

A device connecting to a website has usually never seen that site's certificate before, so it cannot trust it directly. Instead it follows a chain. The site's leaf certificate is signed by an intermediate CA, the intermediate's certificate is signed by a root CA, and the root certificate is already installed in the device's trust store. If every signature checks out and the chain ends at a trusted root, the device trusts the leaf. That sequence of signed links is the chain of trust, and the preinstalled root at the top is the root of trust.

How a client validates the chain

During a TLS handshake the server sends its leaf certificate plus its intermediate certificates. The root is not sent, because the client is expected to hold it already. The client then checks every link:

  • The signature on each certificate verifies with the public key in the certificate above it.
  • Each issuer is marked as a CA (basic constraints CA:TRUE) and is allowed to sign certificates.
  • The current time falls inside every certificate's validity period.
  • No certificate in the path has been revoked, according to CRL or OCSP data.
  • The leaf's Subject Alternative Name list contains the hostname the user asked for.

Any failure breaks the chain, and the browser shows a certificate warning instead of loading the page.

Example: a missing intermediate certificate

The most common chain problem is a server that sends only its leaf certificate. OpenSSL shows the difference clearly. With the intermediate supplied, openssl verify -CAfile root.pem -untrusted intermediate.pem portal.pem prints portal.pem: OK. Without it, nothing links the leaf to the root:

CN=portal.example.com

error 20 at 0 depth lookup: unable to get local issuer certificate

error portal.pem: verification failed

Desktop browsers often hide this mistake, because some fetch missing intermediates themselves and others ship lists of known intermediates. The site then looks fine in a browser while curl, Java and Python clients, many mobile apps and IoT devices fail. The fix is to install the full chain on the server: the leaf followed by its intermediates.

Why the chain is built in tiers

A root CA's private key is the most valuable secret in a PKI, so roots are kept offline and used only to sign intermediate CA certificates, which do the daily issuing. If an intermediate is compromised, the root revokes it and signs a replacement, and the root in every trust store stays the same. Adding a root to a trust store is powerful for the same reason: whoever controls that root can issue a trusted certificate for any name. TLS inspection proxies rely on this on purpose, and malware that installs its own root does it to intercept traffic, so an unexpected root deserves investigation.

The idea also applies to the boot process. With UEFI Secure Boot, the firmware checks the bootloader's signature and the bootloader checks the operating system loader, a chain anchored in keys stored in firmware.

Chain of trust vs. root of trust vs. web of trust

The root of trust is the single anchor accepted without proof: a root certificate in the trust store, or a hardware component such as a TPM. The chain of trust is the series of verifiable links that hang from that anchor. A web of trust, used by PGP, has no central root at all; users sign each other's keys and decide whose endorsements they accept.

Chain of trust on the CompTIA Security+ exam

The chain of trust belongs to SY0-801 objective 1.3, the objective on cryptographic solutions, which includes certificate authorities and the root of trust. "A site works in browsers but a script reports unable to get local issuer certificate" points to a missing intermediate. "Every company laptop shows an untrusted certificate error for an internal site" points to deploying the internal root CA to the trust stores. "Protect the root CA" points to keeping it offline and issuing through intermediates. Distractors include renewing the certificate, which fixes dates, reissuing it with new SAN names, which fixes name mismatches, and telling users to accept the warning, which trains them to ignore real attacks.

Studying for CompTIA (Security)?

ExamWizardz turns the official objectives into a guided study plan — with practice tests, realistic PBQs, and a readiness score. Start free.

Start studying free

Related terms