FFoundationalGeneral
Public Key Infrastructure and Certificates
Public key infrastructure is the cryptographic foundation underneath every certificate-based system you will encounter, from HTTPS to Active Directory. This lesson covers asymmetric keys, what a certificate actually is, and why chains of trust let a stranger's public key be trusted without ever meeting them.
Why it matters
Every system that authenticates with a certificate, from a browser padlock to Kerberos PKINIT to an internal enterprise CA, is built on the same handful of PKI concepts. If you cannot explain what a certificate actually proves, you cannot credibly explain why forging or stealing one is dangerous. Interviewers and stakeholders alike will eventually ask "how does the system know that certificate is real," and a vague answer signals that the rest of your certificate-related knowledge is memorized rather than understood.
This matters even more once you move into domain-specific territory, where certificates stop being an abstract cryptography topic and become a live authentication credential. That territory assumes you already have the fundamentals in this lesson down cold. Without them, terms like "signed by a trusted CA" or "chain validation failed" are just words you repeat rather than mechanisms you can reason about under pressure.
Key Concepts
- Asymmetric key pair — a mathematically linked public key and private key; anything encrypted with one can only be decrypted with the other, and the private key must never leave the owner's control
- Certificate — a signed statement that binds a public key to an identity, such as a domain name or a user; it contains the subject, the public key, an expiry date, and a signature from the issuing authority
- Certificate authority (CA) — a trusted entity that verifies an identity claim and signs a certificate to vouch for the binding between that identity and its public key
- Chain of trust — the sequence of signatures from a leaf certificate up through one or more intermediate CAs to a root CA; validating a certificate means validating every signature in this chain
- Root of trust — a small, hardcoded set of root CA certificates that a system trusts unconditionally, usually shipped with the operating system or browser; every other certificate is trusted only because it chains back to one of these
Theory
Core idea
Public key infrastructure exists to solve two connected problems. The first is asymmetric cryptography itself: instead of one shared secret, each party holds a mathematically related key pair, a public key that can be handed to anyone, and a private key that never leaves the owner. Data encrypted with the public key can only be decrypted with the matching private key, and data signed with the private key can be verified by anyone holding the public key. That second operation, signing, is the one PKI leans on most.
The second problem is trust: if public keys can be freely shared, how does anyone know a given public key genuinely belongs to the party it claims to represent? A certificate answers that question. It is a small, signed document that states "this public key belongs to this identity," where the signature comes from a certificate authority, an entity whose job is to verify identity claims before vouching for them. The CA does not protect the message being sent; it protects the claim of ownership over the key.
Once you separate these two ideas, the encryption problem and the identity-binding problem, most of PKI stops being mysterious. Everything else, expiry dates, revocation, chains of intermediate CAs, is scaffolding built to keep that one binding, key to identity, trustworthy over time.
Mental model
Think of a certificate as a notarized document rather than a secret. A notary does not create your identity or your signature; a notary verifies who you are and then stamps a document attesting to that fact, so that a stranger reading the document later does not need to have met you. A certificate works the same way: the CA verifies an identity claim once, then signs a document (the certificate) that says "I checked, and this public key belongs to this identity." Anyone who trusts the notary's stamp can trust the document without redoing the verification themselves.
That trust does not stop at one notary. A notary's own authority might be certified by a state office, and the state office's authority by a federal one. This is the chain of trust: a leaf certificate is signed by an intermediate CA, the intermediate CA's own certificate is signed by another CA, and so on, until the chain reaches a root CA. Root CAs are not vouched for by anyone else; they are trusted by fiat, because the operating system or browser was configured in advance to trust them. That short, hardcoded list of root certificates is the entire foundation the rest of the system's trust rests on.
Validating a certificate means walking this whole chain, not just checking the one signature at the bottom. If any link in that chain is missing, expired, or signed by something outside the trusted root set, the validation fails, regardless of how correct the leaf certificate itself looks.
Common misunderstandings
- Treating encryption and identity verification as the same operation. Encrypting a message with a public key keeps its contents private; it says nothing about who you are talking to. Signing (and the CA process built on top of signing) is what proves identity. A certificate's core job is the second one, not the first.
- Thinking the certificate contains the private key. A certificate only ever contains the public key, the identity it is bound to, and a signature. The private key is never transmitted or embedded in the certificate; if it were, the whole scheme would be worthless.
- Assuming CA validation means the entity is trustworthy. A CA verifies control over an identity, such as ownership of a domain, not whether the organization behind that identity is honest or competent. A validly signed certificate for a malicious website is still a validly signed certificate.
- Believing self-signed certificates are inherently broken. A self-signed certificate provides identical encryption strength to a CA-issued one; what it lacks is a trusted third party vouching for the identity claim. That absence of external trust is exactly why systems warn about them, not any cryptographic weakness.
Real-world context
This foundation is invisible during normal operation and load-bearing the moment something goes wrong. Every HTTPS connection performs a full chain validation before a browser shows a padlock: it checks the leaf certificate's signature, walks up through any intermediate CAs, and confirms the chain terminates at a root already present in the trust store. When that chain breaks, an expired intermediate, a certificate for the wrong domain name, a root that is not recognized, the browser refuses to proceed silently and instead surfaces a warning, because silently trusting a broken chain defeats the entire purpose of the system.
Organizations that need certificates for internal systems, rather than public websites, typically run their own private CA instead of relying on a public one. That internal CA issues certificates the organization's own devices are configured to trust, which is exactly the model Active Directory environments build on when they deploy their own certificate infrastructure. The mechanics of how an organization stands up and governs that internal CA, and how those certificates end up being used as authentication credentials rather than just encryption material, are worth their own dedicated study once this cryptographic layer is solid.
The CA's private key is the single most sensitive asset in the entire system, because whoever holds it can sign a certificate claiming any identity. This is why production CAs typically keep their signing key in a hardware security module that never exposes the raw key material, and why a compromised CA is treated as a catastrophic, trust-ending event rather than an ordinary credential leak. Every certificate that CA ever issued becomes suspect the moment its signing key is in question.
Communication
Interview answer
Public key infrastructure solves a trust problem, not just an encryption problem. Asymmetric cryptography gives you a key pair where a private key signs and a public key verifies, and a certificate is a signed statement from a certificate authority binding a specific public key to a specific identity.
When a system validates a certificate, it is not just checking one signature. It walks the chain of trust from that certificate up through any intermediate CAs to a root CA that is already hardcoded as trusted. If every link in that chain checks out, the identity claim is accepted. If any link is missing, expired, or untrusted, validation fails.
The reason this matters practically is that the CA's signature is the entire basis for trusting the binding between a key and an identity. A CA's private key is one of the most protected assets in any PKI deployment, because compromising it means an attacker can mint a trusted certificate for any identity they want.
Follow-up questions
- What is the difference between encrypting data with a public key and signing data with a private key, and why does a certificate rely on the second one?
- If you receive a stranger's public key, what specifically makes it trustworthy versus just being a random number?
- What happens, step by step, when a browser encounters a certificate whose chain does not terminate at a trusted root?
- Why is a self-signed certificate considered less trustworthy than a CA-issued one, given that both provide the same encryption strength?
- Why do organizations protect a certificate authority's private key with hardware security modules rather than ordinary file storage?
