What Is PKI: Certificate Authorities and the Chain of Trust

Public key cryptography gives you a neat trick: a key pair where one key encrypts what only the other can decrypt, and one key signs what the other can verify. It solves the problem of proving a message came from a specific key. It does not, on its own, solve the harder problem: proving that a particular key actually belongs to the bank, the website, or the person you think you are talking to. Anyone can generate a key pair and claim any name.

Public key infrastructure, PKI, is the system that closes that gap. It is the arrangement of authorities, certificates, and rules that lets two strangers who have never met establish who each other is, using a trusted third party to vouch for the link between an identity and a public key. Every padlock in your browser rests on it.

The core problem: binding a key to an identity

A public key is just a large number. It carries no name, no proof of ownership. If a server hands you a public key and says "this is example.com", you have no reason to believe it. An attacker could hand you their own key and make the same claim.

PKI solves this with a certificate: a document that states "this public key belongs to this identity" and is digitally signed by a trusted authority. The signature is the important part. If you trust the authority and you can verify its signature, you can trust the binding it asserts, even though you have never contacted that authority directly for this specific certificate.

Certificate authorities and the chain of trust

The trusted authority is a certificate authority, a CA. But you do not trust every CA equally, and you certainly do not trust a random CA that just signed a certificate. Trust is anchored at a small number of root CAs whose certificates ship pre-installed in your operating system and browser. These roots are the foundation. If you trust nothing else, you trust them.

Root keys are far too valuable to use for everyday work. Signing millions of certificates directly with a root key would expose it constantly. So roots are kept offline and used rarely, only to sign intermediate CAs. The intermediates do the daily issuing. The result is a chain:

Link	Role	Key handling
Root CA	Trust anchor shipped in your device	Kept offline, used to sign intermediates only
Intermediate CA	Issues certificates day to day	Online, replaceable if compromised
End-entity certificate	The server or client certificate	Held by the site or service owner

Each certificate in the chain is signed by the one above it. The server's certificate is signed by an intermediate; the intermediate is signed by the root; the root signs itself and is trusted because it is in your device's trust store. This is the chain of trust. Its shape has a practical benefit: if an intermediate is compromised, the CA can revoke and replace it without ever touching the offline root, so the whole trust store does not have to change.

How validation actually works

When your browser receives a server's certificate, it checks far more than the name. It walks the chain:

Read the server certificate and find who issued it.
Fetch or receive that issuer's intermediate certificate and verify the issuer's signature on the server certificate.
Repeat up the chain until it reaches a certificate signed by a root already in the trust store.
Along the way, check that every certificate is within its validity dates, that the name matches what you are connecting to, and that none have been revoked.

If every signature checks out and the chain terminates at a trusted root, the certificate is accepted. If any link fails, the connection is refused. This is what the padlock represents: a chain that validated all the way to a root your device trusts.

Why the offline root matters

The single most protected object in a certificate authority is the root private key. It is generated and stored in hardware, kept physically offline, and used only in rare, tightly controlled ceremonies to sign intermediates. If a root key leaked, every certificate chaining to it would be suspect and the root would have to be pulled from every device on earth, which is close to catastrophic. Keeping the root offline and delegating daily work to replaceable intermediates is the design that makes recovery from a compromise possible.

Revocation: the hard part

Certificates have expiry dates, which handles the normal case. But sometimes a certificate has to be distrusted before it expires: a private key leaks, a server is decommissioned, a certificate was issued in error. For that, PKI needs revocation, a way to say "stop trusting this certificate now".

There are two classic mechanisms:

Certificate Revocation Lists (CRLs). The CA publishes a list of revoked certificate serial numbers. Clients download it and check. The list grows large and is only as fresh as the last download.
Online Certificate Status Protocol (OCSP). The client asks the CA in real time whether a specific certificate is still good. This is fresher but adds a network round trip, and it can leak which sites you visit to the CA.

Both have real problems. CRLs get big and stale. OCSP is slow, privacy-leaking, and if the client fails open when the OCSP server is unreachable, an attacker who blocks the check defeats revocation entirely. Revocation is the genuinely unsolved-in-practice corner of PKI.

The industry's answer has increasingly been to sidestep the problem: issue short-lived certificates. If a certificate is only valid for a matter of days, the damage window from a leaked key is small and revocation matters far less, because the certificate expires almost as fast as you could revoke it. Automation makes frequent reissuance practical.

A CA that validates badly poisons the whole system

PKI's trust flows from CAs checking identity correctly before they sign. If a CA issues a certificate for a domain to someone who does not control it, that certificate is fully valid in every browser, and the real owner may never know. This is exactly why Certificate Transparency was built, to make every issued certificate public so mis-issuance can be caught. Trust in PKI is only as strong as the weakest trusted CA's validation process.

Putting PKI to work

Protect private keys above all. The entire system assumes the private key stays private. Store keys in hardware where you can, limit who can touch them, and never commit them to a repository.
Automate certificate issuance and renewal. Manual certificate management leads to expired certificates and outages. Automated issuance also makes short-lived certificates feasible.
Prefer short-lived certificates. They shrink the value of a stolen key and reduce your dependence on revocation infrastructure that does not work well.
Run a private CA for internal identity. For internal services and mTLS, issue from your own CA rather than a public one, so you control exactly which certificates your systems trust.
Monitor Certificate Transparency for your names. Since CAs can mis-issue, watch the public logs so you learn about any certificate created for your domains.
Understand your revocation posture. Know how your clients check revocation and whether they fail open or closed, because a revocation check that fails open is barely a control at all.

The anatomy of an X.509 certificate

The certificate format that carries all of this is called X.509, defined in RFC 5280. It helps to know what actually sits inside one, because every validation rule maps to a field you can inspect. A certificate is a structured document with a fixed set of parts, and each part exists to answer a question the relying party will ask.

The subject field names who the certificate is for. For a website this is expressed through the subject and, more importantly today, the Subject Alternative Name extension, which lists the domain names the certificate covers. Modern clients read the names from the SAN extension and ignore the older common name field, so a certificate that lists a name only in the common name and not the SAN will be rejected by current browsers.

The issuer field names the CA that signed the certificate. During validation this field tells the client which certificate should sit one level up the chain, because the issuer of the leaf must be the subject of the next certificate.

The public key is the whole point of the document: the key the certificate binds to the subject. The validity period gives a not-before and a not-after date, outside which the certificate is invalid regardless of anything else. The serial number uniquely identifies the certificate within the issuing CA, and it is the value that appears on revocation lists when a certificate is pulled early.

A set of extensions carries the operational rules. Key usage and extended key usage state what the key may be used for, for example server authentication, client authentication, or code signing. Basic constraints marks whether a certificate is a CA that may sign other certificates, and how deep a chain below it may go. Authority Information Access points to where the issuer certificate and the OCSP responder can be found. CRL distribution points name where the revocation list lives. A client that validates properly reads and enforces these extensions rather than treating the certificate as a plain name-to-key pair.

Finally the signature covers everything above it. The CA hashes the certificate body and signs the hash with its private key. Anyone with the CA's public key can recompute the hash, verify the signature, and confirm that not a single field was altered after signing. This is why tampering with any part of a certificate invalidates it: the signature no longer matches.

A worked example: issuing and validating a TLS certificate

Walking one certificate from birth to use makes the moving parts concrete.

Key generation. The site operator generates a key pair on their server. The private key never leaves the machine. The public key will go into the certificate.
Certificate signing request. The operator builds a certificate signing request, a small signed blob that contains the public key and the requested names, and sends it to the CA. The request is self-signed with the matching private key, which proves the requester holds the private key for the public key inside.
Domain validation. Before signing, the CA has to be satisfied that the requester controls the names. For a standard domain-validated certificate this is automated: the CA asks the requester to place a specific token at a known path on the web server, or to publish a specific DNS record, and then checks for it. Control of the domain is the only thing a domain-validated certificate asserts.
Issuance. Satisfied, the CA fills in the certificate fields, sets the validity dates, adds the extensions, and signs the body with an intermediate CA key. The signed certificate goes back to the operator.
Logging. The CA submits the certificate to Certificate Transparency logs and receives signed timestamps that it can staple into the certificate, so the issuance is publicly recorded.
Installation. The operator installs the leaf certificate and the intermediate certificate on the server. When a browser connects, the server presents both, which lets the browser build the chain up to a root it already trusts.
Validation. The browser walks the chain, checks every signature, confirms the dates are current, confirms the connecting name is in the SAN list, and checks revocation status. If all pass, the handshake completes and the padlock appears.

The important detail is where trust actually enters. The browser never contacted the CA to ask about this specific site. It trusts the root that ships in its store, and every other link is a signature it can verify offline using keys it already holds or receives in the handshake.

What domain validation does and does not prove

A domain-validated certificate proves one thing: at issuance time, the requester could place a token on the server or in DNS for that name. It says nothing about who the requester is, whether the business is legitimate, or whether the site is safe. A padlock means the connection is encrypted and the name matches a valid certificate. It never meant the site is trustworthy, and reading it as a safety signal is the single most common misunderstanding of what PKI provides.

PKI beyond the web

TLS for websites is the most visible use of PKI, and it is far from the only one. The same machinery of certificates and chains underpins several other trust problems.

Mutual TLS. In ordinary web TLS only the server presents a certificate. In mutual TLS the client presents one too, and the server validates it against a CA it trusts. This is how services inside a network authenticate each other without shared passwords, and it is the backbone of many zero-trust and service-mesh designs. Each service holds a certificate issued by an internal CA, and identity is proven by the certificate rather than by a network location.

Code signing. Software publishers sign their binaries with a private key whose certificate chains to a root the operating system trusts. When you run an installer, the platform verifies the signature and shows the publisher name, which lets the system refuse or warn on unsigned or tampered code. The trust model is identical to the web: a CA vouches that a signing key belongs to a named publisher.

Secure email. S/MIME uses certificates to sign and encrypt email, binding a key to an email address so recipients can verify the sender and confidentiality.

Device and user identity. Enterprises issue certificates to laptops, phones, and users so that network access, VPNs, and applications can authenticate the holder cryptographically. A device with a valid certificate from the internal CA is recognized; one without is not.

In every case the pattern repeats: bind a key to an identity, anchor trust in a root, and validate by walking a chain of signatures. Learning the web case teaches you all of them.

How PKI evolved

The X.509 format dates to the late 1980s, and the model of hierarchical certificate authorities has been remarkably durable. What changed over time is the operational discipline around it, driven by repeated painful lessons.

Early web PKI relied heavily on the identity checking of individual CAs, with little external oversight. When CAs mis-issued certificates, whether through compromise or careless validation, the ecosystem often learned about it slowly, if at all. A single trusted CA issuing a certificate for a domain it should not have could enable interception that was invisible to the victim.

The response was structural. Certificate Transparency introduced public, append-only logs of every certificate a participating CA issues, so mis-issuance can be detected by anyone watching the logs, including the real domain owner. Browser and operating system vendors tightened the requirements a CA must meet to stay in the trust store, and they have removed CAs that failed to meet them. Baseline requirements standardized validation practices across CAs. Maximum certificate lifetimes were repeatedly shortened, both to limit the damage window of a leaked key and to force the automation that makes short lifetimes practical.

The trajectory is toward less standing trust in any single CA and more external verification, shorter-lived certificates, and heavy automation. The cryptographic core stayed the same while the governance around it grew much stricter.

Common misconceptions

A padlock means the site is safe. It means the connection is encrypted and the certificate is valid for the name you visited. A phishing site can hold a perfectly valid certificate for its own lookalike domain. The padlock is about the channel, not the honesty of the other end.

Self-signed certificates are broken. A self-signed certificate is not chained to a public root, so browsers warn on it, but the cryptography works. Inside a controlled environment where you distribute your own root, self-signed and private-CA certificates are entirely legitimate. The warning is about trust anchoring, not about the certificate being defective.

Expiration is the main protection. Expiration handles the routine case, but it is slow. A key that leaks today should be distrusted today, which is what revocation and short lifetimes are for. Treating a distant expiry date as security leaves a long window a leaked key can be abused in.

Bigger keys always mean better security. Beyond a sound modern key size, the weak point is almost never the key length. It is private key handling, CA validation quality, and revocation. An enormous key on a server whose private key sits in a world-readable file is not secure.

The CA can read my traffic. A CA signs your certificate, it does not hold your private key. Your private key stays on your server and is what decrypts and signs in the session. The CA vouches for the binding and has no access to the traffic.

Detection signals: spotting PKI trouble

Because PKI failures are quiet, monitoring is what surfaces them. Concrete signals worth watching:

Unexpected certificates for your domains in Certificate Transparency logs. A certificate you did not request, appearing in the public logs for a name you own, is a strong sign of mis-issuance or an unauthorized issuance path. Watching the logs for your names is the single highest-value PKI monitoring you can do.
Certificates nearing expiry without a renewal in progress. An expiring certificate on a production service is an outage waiting to happen. Alert well before the not-after date.
Chains that fail to build or include an unexpected root. A client suddenly presented with a certificate chaining to an unfamiliar root, or an internal service where a corporate proxy has substituted its own CA, changes who is trusted for that connection.
Revocation checks that fail open. If your clients silently accept certificates when the OCSP or CRL endpoint is unreachable, an attacker who blocks the check has defeated revocation. Knowing your clients' behavior here is a control audit in itself.
Weak or deprecated algorithms in a chain. A certificate signed with a hash or key type that has been retired is both a compatibility risk and a security one.
Private keys appearing where they should not. A private key committed to a repository, sitting in a backup, or copied to a developer laptop is a compromise of the one secret the whole system depends on. Scanning for key material in code and artifacts catches this.

Frequently asked questions

What is the difference between a certificate and a public key? A public key is just the key. A certificate is a signed statement that binds that public key to an identity, with validity dates and usage rules, vouched for by a CA. The certificate is what makes a bare key trustworthy to someone who has never met you.

Why does my browser trust some certificates automatically? Because they chain up to a root CA whose certificate ships pre-installed in your operating system or browser trust store. You trust the root implicitly, and every certificate that validates up to it inherits that trust.

What happens when a certificate expires? Clients reject it. The connection fails with an error, and for a website that usually means an outage until a new certificate is installed. Expiry is a safety limit, so the fix is renewing before the date, ideally through automation.

Can a certificate authority be removed from the trust store? Yes. Browser and operating system vendors have removed CAs that mis-issued certificates or failed to meet requirements. When a CA is distrusted, every certificate chaining to it stops being accepted, which is why CAs guard their standing carefully.

Why is the industry moving to short-lived certificates? Because revocation works poorly in practice. If a certificate is valid for only a short window, a leaked private key is dangerous for a short window, and the certificate expires almost as quickly as you could revoke it. Automation makes frequent reissuance painless, which removes the main objection to short lifetimes.

Is a private CA less secure than a public one? Not inherently. A private CA gives you full control over who your systems trust, which is exactly what you want for internal services and mutual TLS. Its security depends on how well you protect the private keys and run issuance, the same factors that govern a public CA.

What is Certificate Transparency and why should I care? It is a system of public logs recording every certificate participating CAs issue. You care because it lets you watch for certificates issued for your domains that you did not request, which is how mis-issuance gets caught early.

PKI is the machinery that lets trust scale to the whole internet. A short chain of signatures, anchored in a handful of carefully guarded roots, lets any two parties verify each other without prior contact. It has real weak spots: revocation is awkward and a careless CA can undermine it. Understood and operated well, it is the reason you can type a bank's address and be confident you reached the bank.

For how attackers abuse weak certificate handling, stolen signing keys, and trust in the certificate ecosystem, our exploit intelligence dashboard tracks the campaigns that turn PKI failures into real compromises.