cybersecurity pki

PKI (PKI)

pki public-key-infrastructure certificates tls trust cryptography
Plain English

PKI is the invisible scaffolding that makes digital trust work. Every time you see the padlock in your browser, every time you SSH into a server and it does not ask for a password, every time you verify that a software download has not been tampered with - PKI is what makes that trust possible. At its core: someone (a Certificate Authority) you both trust vouches that a public key belongs to who it claims. PKI is the whole system: who the CAs are, what the certificates look like, how you check if one has been revoked, and how devices decide what to trust.

Technical Definition

Public Key Infrastructure is the framework that enables asymmetric cryptography to be used at scale for authentication, encryption, and signing.

Core components:

  • Root Certificate Authority: Self-signed trust anchor. Kept offline. Signs Intermediate CA certificates.
  • Intermediate CA: Online CA that issues end-entity certificates. Its certificate is signed by the Root.
  • End-Entity Certificate: Issued to a user, device, or server. Contains a public key, identity, validity period, key usage, and CA signature.
  • Certificate Revocation List (CRL): A signed list of revoked certificate serial numbers published by the CA at regular intervals.
  • OCSP (Online Certificate Status Protocol): Real-time revocation check. Client queries the CA’s OCSP responder with a certificate serial number; responder answers good/revoked/unknown.
  • Root Store: The set of CA certificates built into an OS or browser that are trusted by default. macOS, Windows, Firefox, and Chrome each maintain their own.

Certificate chain validation algorithm:

  1. Start with the presented certificate (leaf)
  2. Find the issuer certificate (Intermediate CA)
  3. Verify the Intermediate’s signature on the leaf cert
  4. Walk up the chain to the Root CA
  5. Verify the Root is in the local trust store
  6. Check validity dates and revocation status at each level
  7. Verify key usage extensions match the intended use

X.509 Key Usage Extensions:

Certificates carry extensions that constrain what the key can be used for:

  • digitalSignature - signing data
  • keyEncipherment - encrypting symmetric keys (RSA TLS)
  • keyAgreement - ECDH key exchange
  • keyCertSign - signing other certificates (CA only)
  • cRLSign - signing CRLs

Extended Key Usage (EKU) further constrains: serverAuth, clientAuth, codeSigning, emailProtection, timeStamping.

Private PKI vs Public PKI:

Public PKI (Let’s Encrypt, DigiCert) works for publicly routable domain names. It cannot issue certificates for 10.0.0.1, server.home.lab, or any private name. Private PKI gives you a CA whose trust you install manually on all your devices, with full control over issuance policies, naming, and lifetimes.

In the Wild

PKI is the foundation of secure internet communication. TLS (the “S” in HTTPS) relies on PKI to prove you are connected to the real bank’s server and not an impersonator. Code signing PKI lets your OS verify that software updates genuinely came from the vendor. Email signing (S/MIME) uses PKI to prove an email was not forged. In enterprise and homelab contexts, a private PKI unlocks hardware-backed authentication: your Certificate Authority issues certificates to YubiKeys, and every SSH connection, VPN tunnel, and web app login is verified against that CA. The real power of private PKI is that authentication becomes decentralized - the CA issues once and goes offline; the trust it established runs entirely on the certificates it signed.

← Back to Dictionary