Public Key Infrastructure

Public Key Infrastructure (PKI) is the framework of policies, procedures, hardware, software, and roles needed to create, manage, distribute, use, store, and revoke digital certificates. PKI is what makes HTTPS, email encryption, code signing, and countless other secure communications trustworthy at scale.

---

The Trust Problem

Asymmetric cryptography gives us public and private keys — but how do you know that a public key truly belongs to the person or organisation claiming it?

Without PKI:

• An attacker could publish a fake public key claiming to be your bank
• You would encrypt your credentials with the attacker's key, thinking it was the bank's
• This is the man-in-the-middle problem

PKI solves this by binding public keys to verified identities through digital certificates issued by trusted third parties.

---

Core Components of PKI

Component	Role
Certificate Authority (CA)	Issues and signs digital certificates; the root of trust
Registration Authority (RA)	Verifies the identity of certificate applicants on behalf of the CA
Digital Certificate	A digitally signed document binding a public key to an identity
Certificate Revocation List (CRL)	A list of revoked certificates published by the CA
OCSP (Online Certificate Status Protocol)	Real-time check of a certificate's revocation status
Certificate Store / Trust Store	The collection of trusted root CA certificates on a device or browser

---

X.509 Certificates

The X.509 standard defines the format for digital certificates used in TLS/SSL, email, code signing, and more.

Key Fields in an X.509 Certificate

Field	Description
Version	X.509 version (typically v3)
Serial Number	Unique identifier assigned by the CA
Signature Algorithm	Algorithm used to sign the certificate (e.g., SHA-256 with RSA)
Issuer	The CA that issued and signed the certificate
Validity Period	Not Before and Not After dates
Subject	The entity the certificate identifies (e.g., CN=www.example.com)
Subject Public Key	The public key bound to the subject
Extensions	Additional fields: Subject Alternative Names (SANs), Key Usage, Extended Key Usage
Signature	The CA's digital signature over the certificate contents

Certificate Types (Validation Levels)

Type	Validation	Visual Indicator
DV (Domain Validation)	CA verifies domain ownership (automated)	Padlock icon
OV (Organisation Validation)	CA verifies the organisation's legal identity	Padlock + organisation name in certificate details
EV (Extended Validation)	Rigorous verification of legal, physical, and operational existence	Padlock (green bar removed by browsers in 2019)

---

The Certificate Chain of Trust

PKI uses a hierarchical trust model:

Root CA (self-signed, stored in trust store)
    │
    ▼
Intermediate CA (signed by Root CA)
    │
    ▼
End-Entity Certificate (signed by Intermediate CA)
    (e.g., www.example.com)

How Chain Validation Works

1. The browser receives the server's end-entity certificate and any intermediate certificates
2. It verifies the signature on each certificate up the chain
3. It checks that the chain terminates at a trusted root CA in the browser's trust store
4. It verifies the certificate has not expired
5. It checks revocation status (CRL or OCSP)
6. If all checks pass, the connection is trusted

Why Intermediate CAs Exist

• Root CA private keys are extremely valuable and kept offline in HSMs (hardware security modules)
• Intermediate CAs handle day-to-day certificate issuance
• If an intermediate CA is compromised, only that CA's certificates are revoked — the root CA remains trusted

---