PKI and Certificate Chains

TL;DR: A certificate says "this public key belongs to this name", signed by a certificate authority (CA). Your device ships with a set of trusted root CAs. A server presents its leaf certificate plus intermediates, and the client builds a chain up to a trusted root, checking at each link the signature, the validity dates, that issuers are allowed to issue (basic constraints), and that the leaf's name matches the host. Certificate Transparency logs make every publicly trusted certificate visible so mis-issuance can be caught. Revocation exists but is unreliable, which is why certificate lifetimes keep shrinking.

The problem PKI solves

Signatures and key exchange work only if you have the right public key. On the web you connect to servers you have never seen, so you need a way to learn a server's public key from a source you already trust. Public key infrastructure is that source: a set of authorities, policies and data formats for vouching that a public key belongs to a name.

What a certificate contains

An X.509 certificate is a signed data structure. The fields that matter most for validation:

Building and checking the chain

Root CAs keep their keys offline and sign intermediate CA certificates, which sign the leaf certificates servers use. The server sends its leaf and intermediates; the client already has the roots in its trust store.

The checks, in order:

1. Chain building: find a path from the leaf through intermediates to a trusted root.
2. Signatures: each certificate's signature verifies with its issuer's public key.
3. Validity period: every certificate in the chain is currently valid.
4. Basic constraints: every certificate that signed another is marked as a CA, within any path-length limit.
5. Usage: the leaf's extended key usage allows server authentication.
6. Name: the host the client intended matches a SAN in the leaf.
7. Revocation, where checked, and Certificate Transparency proof, where required.

Use the platform's validation library. Most real-world certificate bugs are hand-written checks that skip one of these steps, or code that disables validation entirely.

The rules inside the chain

RFC 5280 (2008) is the profile that defines X.509 path validation for the internet, and a handful of its rules explain most real bugs.

• Basic constraints. Only a certificate with cA=TRUE may sign other certificates. Validation code that forgets this check lets any leaf certificate act as a CA for any name, which is one of the oldest and most damaging bug classes in TLS libraries.
• Path length. pathLenConstraint on a CA limits how many intermediates may follow it; 0 means it may sign leaves only, so an issuing intermediate cannot mint further sub-CAs.
• Name constraints. A CA certificate may carry a critical extension listing permitted and excluded name subtrees. Exclusions win over permissions, and the constraints apply to both the subject alternative names and the subject's distinguished name of every certificate below. A private intermediate constrained to .corp.example cannot issue a certificate a conformant client will accept for any other domain, even though every signature checks out.
• Name matching. RFC 9525 (2023), which replaced RFC 6125, bases service identity on the subject alternative name entries. Browsers stopped falling back to the Common Name years ago.
• Libraries that do not check names by default. OpenSSL validates the chain but checks the hostname only if the application asks (SSL_set1_host since 1.1.0, or the verify-param equivalent since 1.0.2). Code that builds TLS clients directly on such libraries and never sets the host accepts any valid certificate for any name.
• Serial numbers. CA/Browser Forum rules have required at least 64 bits of random output in public certificate serial numbers since 2016. The reason is history: in December 2008, researchers used a chosen-prefix MD5 collision against a CA that issued predictable serial numbers and timestamps to create a rogue CA certificate. Unpredictable serials make that kind of precomputed collision impractical, and MD5 is long gone.

Building the chain is a separate problem

Validation checks a chain; something has to build it first. Servers should send the leaf and every intermediate. Browsers may fetch a missing intermediate from the URL in the Authority Information Access field or use a cached copy, but most API clients and languages do not, so a server that sends only its leaf works in a browser and fails in a script. Cross-signing, where one intermediate is signed by two roots, lets a new root be trusted by old devices; when the older root expires, clients that build the path through it fail even if they also trust the newer one. The expiry of DST Root CA X3 on 30 September 2021 broke exactly those clients, including OpenSSL 1.0.x, whose chain building preferred the expired path.

Certificate Transparency

Any of the many trusted CAs can issue a certificate for any domain, so one compromised or careless CA can undermine everyone. Certificate Transparency (RFC 6962) requires publicly trusted certificates to be recorded in public, append-only logs built on Merkle trees. Browsers check for signed certificate timestamps (SCTs) proving a certificate was logged. Domain owners can then monitor the logs for certificates they did not request. CT does not prevent mis-issuance; it makes it detectable, which changes CA incentives.

Getting a certificate: what domain validation proves

A publicly trusted certificate for a name is issued after the CA checks that the requester controls the name, usually through ACME (RFC 8555, 2019). The common challenges:

Domain validation proves control of a name as seen from the CA's network, which is why routing and DNS attacks matter. Two controls narrow it:

• CAA records (RFC 8659) name the CAs allowed to issue for a domain, and CAs have been required to check them since September 2017. RFC 8657 extensions let a domain restrict issuance to a specific ACME account (accounturi) and to specific challenge types (validationmethods), so a hijacker who can answer HTTP-01 still cannot get a certificate if only DNS-01 from your account is allowed.
• Multi-perspective issuance corroboration makes CAs validate from several network vantage points in different regions. The requirement is four remote perspectives today and five from 15 December 2026, so a BGP hijack visible from one part of the internet is no longer enough.

Revocation, and why lifetimes are shrinking

When a private key is compromised, its certificate should be revoked. The mechanisms are weak in practice. Certificate revocation lists (CRLs) can be large and stale; OCSP lookups add latency and leak browsing to the CA, and clients often "soft fail", accepting the certificate if the check cannot complete. Let's Encrypt removed OCSP URLs from its certificates in May 2025 and shut down its OCSP responders on 6 August 2025, relying on CRLs and short lifetimes instead.

The industry's answer is shorter certificates, so a compromised key is useful for less time. In April 2025 the CA/Browser Forum approved a phased reduction of the maximum public TLS certificate lifetime, reaching 47 days by 2029 (checked November 2026). That makes automated issuance and renewal, for example with the ACME protocol, a requirement rather than a convenience.

Fleet arithmetic: why automation stops being optional

Take 2,000 public certificates renewed when two-thirds of their lifetime has passed.

At the 2029 limits, the DNS-01 credentials are used about 64 times a day. That makes them a crown jewel: whoever holds them can issue for every name they cover. Scope them to TXT records under _acme-challenge (or delegate that label by CNAME to a dedicated zone), store them in a secrets manager, and rely on CT monitoring plus CAA accounturi to catch misuse. ACME Renewal Information (RFC 9773) lets the CA suggest when to renew, which also lets it trigger early renewal during an incident. Let's Encrypt has offered certificates valid for about six days since January 2026 for operators who want to rely on expiry rather than revocation entirely.

Root programs and distrust

Browsers and operating systems decide which roots to trust, and their policies shape the whole ecosystem. Chrome's root programme policy removes roots whose keys are more than 15 years old on a rolling schedule, and requires hierarchies dedicated to TLS server authentication, which is why public CAs are dropping the client-authentication usage from server certificates; mutual TLS identities belong on a private CA. When a CA fails, browsers distrust it: Chrome removed trust in Symantec's PKI across Chrome 66 and 70 in 2018, and in late 2024 Chrome, Mozilla and Apple stopped trusting new Entrust certificates, with Chrome keying the cut-off to certificates whose earliest SCT was after 11 November 2024.

Private PKI

Organisations run their own CAs for internal services, device identity and mutual TLS. The same rules apply, with you as the root: protect the root key (offline or in an HSM), issue short-lived certificates automatically, constrain what each intermediate may issue, and decide carefully which systems trust your root. Adding a corporate root to every laptop's trust store means anyone who controls that root can intercept those laptops' TLS.

Worked example: a name-constrained private CA

A company runs an internal PKI for service-to-service TLS. The issuing intermediate carries:

• a critical name-constraints extension permitting DNS names under .corp.example and excluding all IPv4 and IPv6 address ranges;
• pathLenConstraint: 0, so it cannot create sub-CAs;
• a three-year lifetime, with the root kept offline in an HSM.

Leaves are issued automatically with 30-day lifetimes.

The design means a stolen intermediate key can only impersonate internal names, not the bank, and the root's compromise is the only catastrophe left, which is why it stays offline.

Misconceptions interviewers listen for

• "Validating a certificate means checking its signature." Path building, issuer rules, validity, name constraints, usage and name matching all have to pass.
• "Intermediates are trusted because the server sent them." They must chain to a trust anchor the client already holds.
• "Revocation is checked on every handshake." Browsers use pushed revocation data; most clients check nothing online.
• "Domain validation proves who the requester is." It proves control of a name from the CA's vantage points, which routing and DNS attacks can fool.
• "Our TLS library checks the hostname." Some only do so when the application configures it.

Primary references

References for the mechanisms discussed above, accessed 6 November 2026:

• RFC 5280: certificate path validation.
• RFC 9525: service identity checks.

How this shows up in interviews

"How is a certificate chain validated, and what goes wrong in practice?" tests whether you know validation is more than a signature check. Strong answers list the checks in order, call out hostname verification and basic constraints as the classic bugs, and explain why revocation is unreliable and how CT and short lifetimes compensate. For AI roles, connect it to agents and tool clients: any code that talks to model APIs or MCP servers with verification disabled has thrown all of this away.

Say it in 30 seconds: "A certificate binds a name to a public key and is signed by a CA. The client builds a chain from the server's leaf through intermediates to a root it already trusts, and checks every signature, the validity dates, that each signer is a CA, the key usage, and that the leaf's SAN matches the host. Certificate Transparency logs make mis-issuance visible. Revocation is unreliable, so lifetimes are shrinking toward 47 days and renewal has to be automated."