Certificate chain

The path from a certificate through intermediates to a trust anchor, and what path validation checks at every link: signature, validity, usage, revocation.

The ordered set of certificates that leads from the certificate in front of you, through one or more intermediates, to a trust anchor you already accept. Nothing about an X.509 certificate is trustworthy in isolation: it is trusted because a chain to a known anchor can be built and checked.

Checking a chain means more than following signatures. For every link a validator checks the signature, the validity period, the permitted key usage, any name constraints, and the revocation status through a CRL or OCSP - the path validation rules from RFC 5280. Both are still defined there, but they are no longer equal in practice: the CA/Browser Forum has made CRL publication mandatory and running an OCSP responder optional, and Let's Encrypt switched its responders off in August 2025 and now publishes revocation only as CRLs. Build a validator that can read a CRL; treat an OCSP answer as a bonus, not as the source you depend on. A signature validation service reports the outcome per link, which is why a validation report is longer than a yes or no.

What differs in the qualified world is where the chain ends. A browser ends at its own root store; a qualified check ends at the EU Trusted List, because that is where a Member State says which QTSP was supervised and for which service. Intermediates exist to keep the root out of daily use: the root key comes out for a key ceremony and goes back offline, and the intermediate does the issuing. The consequence is operational rather than cryptographic: an expired intermediate, a revoked issuing CA or a certificate that no longer points to where its issuer can be fetched breaks validation for everything below it.