Public Key Infrastructure and Certificates Brief
What It Is
Public key infrastructure solves two connected problems: asymmetric cryptography (each party holds a public key that can be shared freely and a private key that never leaves the owner) and trust (proving a public key genuinely belongs to the identity it claims). A certificate is a signed statement binding a public key to an identity; a certificate authority (CA) verifies the identity claim and signs the certificate to vouch for that binding.
The Notary Analogy
Think of a certificate as a notarized document, not a secret. A notary does not create your identity; it verifies who you are, then stamps a document attesting to that fact so a stranger reading it later does not need to redo the check. A CA works the same way: it verifies an identity claim once, then signs a certificate saying it checked and the public key belongs to that identity. That trust extends up a chain: a leaf certificate is signed by an intermediate CA, which is signed by another CA, until it reaches a root CA trusted by fiat.
Core Components
- Asymmetric key pair: public key can be shared with anyone; private key must never leave the owner's control
- Certificate: contains the subject identity, the public key, an expiry date, and the issuer's signature
- Certificate authority (CA): verifies identity claims and signs certificates to vouch for the identity-to-key binding
- Chain of trust: leaf certificate signed by an intermediate CA, signed by another CA, up to a root CA
- Root of trust: a small, hardcoded set of root CA certificates that a system trusts unconditionally
How Chain Validation Works
- Check the leaf certificate's own signature against the issuing CA's public key
- Walk up through each intermediate CA certificate in the chain, verifying its signature in turn
- Confirm the chain terminates at a root certificate already present in the trust store
- If any link is missing, expired, or signed by something outside the trusted root set, fail validation, even if the leaf certificate itself looks correct
Interview Phrasing
PKI 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 CA binding a specific public key to a specific identity. Validating a certificate means walking 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 checks out, the identity claim is accepted, and if any link is missing, expired, or untrusted, validation fails.
Common Misunderstandings
- Treating encryption and identity verification as the same operation: encrypting keeps contents private, signing is what proves identity
- Thinking the certificate contains the private key: a certificate only holds the public key, the bound identity, and a signature
- Assuming CA validation means the entity is trustworthy: a CA verifies identity control, such as domain ownership, not honesty or competence
- Believing self-signed certificates are inherently broken: they provide identical encryption strength, they simply lack a trusted third party vouching for the identity claim
Why It Matters Beyond Encryption
Every HTTPS connection performs a full chain validation before showing a padlock, and organizations running their own internal certificate infrastructure rely on the same chain-of-trust model to decide which devices and services they trust. The CA's private key is the single most sensitive asset in the whole system: whoever holds it can sign a certificate claiming any identity, which is why production CAs protect that key with a hardware security module and treat a compromised CA as a catastrophic, trust-ending event rather than an ordinary credential leak.
