Certificate and PKI trust

Public-key infrastructure (PKI) is delegated trust with a long reach. A client honours any certificate that chains to a root it already trusts, and it trusts a small set of roots because they were shipped in its trust store. Everything downstream inherits that trust by chain: the intermediates, the end-entity certificates, and the sites and services they identify. The reach is both the point and the risk: a single trusted root, or anything it has vouched for, can vouch in turn for whatever an attacker wants named.

A trusted root vouches for everyone

A certificate authority in the trust store can issue a valid certificate for any name. When DigiNotar was breached in 2011, the attacker issued certificates for Google and others that browsers accepted without complaint, because the certificates chained correctly to a root the browsers trusted. Nothing in the clients failed. They honoured the signature of a CA that had been trusted to make exactly that statement, and the compromise of one issuer became the impersonation of sites that had no relationship with it.

The trust store is the real policy

What a device actually trusts is whatever sits in its trust store, and that list is editable. Adding a rogue root, whether by enterprise policy for inspection or by malware for interception, makes every certificate the attacker signs valid on that endpoint. Corporate TLS interception runs on precisely this: a private root pushed to managed devices so a middlebox can present its own certificates in place of the real ones. The mechanism does not care who pushed the root. The trust store is the policy, and whoever can write to it sets it.

Intermediates, cross-signing and unexpected paths

Roots delegate to intermediate CAs, and an intermediate signs end-entity certificates until it is revoked. A leaked or mis-issued intermediate stays a trusted issuer for as long as revocation lags, and revocation lags: OCSP (online certificate status protocol) checks are widely configured to soft-fail, so an unreachable responder means the certificate is accepted rather than refused. Cross-signing complicates the picture, since a certificate can chain to more than one root, and the path a client builds may not be the one the issuer intended. That is how a certificate keeps validating after a root everyone was watching has been distrusted.

Where PKI meets the other graphs

Certificate trust does not stay in its lane. Inside a Windows forest, AD CS (Active Directory Certificate Services) is a certificate authority the whole directory trusts, so a mis-templated CA issues login identities rather than website identities, and the directory’s trust graph and this one become one problem. Code-signing carries the same delegation into software supply chains, where a stolen signing key makes malicious code trusted by every system that honours the signer. A chain built to answer “is this the right server” ends up answering “is this the right user” and “is this the right program”, on the strength of the same delegated trust.

Revocation is the seam that does not hold

A certificate is trusted until it is revoked, and revocation is the part of the system that works worst. An authority publishes revocations through OCSP and certificate revocation lists, but a client that cannot reach the responder mostly carries on rather than failing closed, so blocking or delaying the check is very nearly unrevoking the certificate. Short-lived certificates were the industry’s answer, shrinking the window rather than mending the mechanism. Certificate transparency logs record almost every certificate issued and let a domain owner notice a mis-issuance after the fact, which turns revocation from prevention into detection: useful, and a step behind.

What is left is hygiene

The trust store is guarded by whoever can write to it, which on a managed fleet is the fleet’s managers and anything running as them. CAA (certification authority authorisation) records constrain which authorities may issue for a name, checked by the authority at issuance, though they touch new certificates only, not the trust a valid one already carries. Public-key pinning, which once let a site refuse any chain but its own, was deprecated for the damage a mistake did. What is left is hygiene: fewer trusted roots, watched transparency logs, shorter lifetimes. Each trims the reach; none removes the basic fact that a trusted issuer can still vouch for anything.