Chapter 1
Symmetric encryption: one shared key
Symmetric encryption scrambles data with one secret key, and only someone who holds that same key can turn the scrambled data back into readable text.
The PKI Handbook
26 chapters in 8 parts, from your first secret key to post-quantum cryptography. Every chapter starts in plain words, then goes as deep as you want. No account needed.
26 of 26 chapters published in this early edition. Each chapter matches one level of the game.
I
Part I: Secrets
Keeping a message private: shared keys, key pairs and agreeing a secret in public.
Chapter 2
The key-distribution problem
A shared secret key must reach each partner without anyone else seeing it, and every pair needs its own key, so sharing secret keys does not scale.
Chapter 3
Key pairs: public and private keys
A key pair is two keys: a public key anyone may have and a private key only you hold, so strangers can encrypt to you without sharing a secret first.
Chapter 4
Key exchange and hybrid encryption
Two parties can agree a shared secret over an open network without ever sending it, then derive fast symmetric keys from it to protect the actual data.
II
Part II: Proof
Proving a message is unchanged and really from its sender: hashes and signatures.
Chapter 5
Hashes and fingerprints
A cryptographic hash turns any data into a short, fixed-size fingerprint; any change gives a completely different fingerprint, and you cannot run it backwards to get the data.
Chapter 6
Digital signatures
A digital signature is a value only the private-key holder can compute for a message, and anyone with the public key can check that it matches that exact, unchanged message.
Chapter 7
Whose key is it? Binding identity to keys
Encryption and signatures only help if you use the right person's public key, so something you already trust must vouch that a key belongs to a name.
III
Part III: Certificates
Binding a name to a public key: X.509, names, requests and validation.
Chapter 8
Anatomy of an X.509 certificate
An X.509 certificate is a public, signed record that ties one public key to names for a fixed period, and you can read every field with openssl.
Chapter 9
Names and jobs: SANs, wildcards, key usage and the CA flag
A certificate is valid only for the names in its Subject Alternative Name list, and only for the jobs that its key usage, extended key usage and CA flag allow.
Chapter 10
Asking for a certificate: key generation and the CSR
You generate a key pair, keep the private key, and send the CA a certificate signing request (CSR) carrying only your public key and the names you want.
Chapter 11
Proving you own the name: DV, OV, EV and CAA
Before issuing, a CA checks that you control each name, using a file, a DNS record or a TLS response, and reads CAA records; OV and EV check the organisation.
IV
Part IV: Trust and HTTPS
Trust stores, chains, cross-signing and the TLS 1.3 handshake.
Chapter 12
Who do we trust? CAs, trust stores and self-signed certificates
Every client trusts only the root certificates in its own trust store, so a certificate is accepted only if its chain ends at one of them; being self-signed earns nothing.
Chapter 13
Certificate chains and path validation
Servers must send their leaf and intermediate certificates; clients link them by name and key identifier up to a trusted root and check every signature, date and constraint.
Chapter 14
Two roads to the same root: cross-signing and root expiry
Cross-signing gives one CA key two certificates from different issuers, so a chain can reach either an old or a new root; clients must pick a path that is valid.
Chapter 15
The TLS 1.3 handshake
In one round trip, client and server agree fresh keys with ECDHE, the server proves it holds the certificate's key by signing the handshake, and both confirm nothing was altered.
V
Part V: When trust breaks
Revocation, Certificate Transparency and what famous failures taught us.
Chapter 16
Taking it back: CRLs, OCSP and stapling
Revocation lets a CA cancel a certificate before it expires, but many clients check late, softly or not at all, so short lifetimes now do much of the work.
Chapter 17
Certificate Transparency
Certificate Transparency records every publicly trusted TLS certificate in public, append-only logs, so anyone can spot a certificate for their name that they never asked for.
Chapter 18
Famous failures and what changed
Real PKI failures, from a hacked CA to expired certificates, follow one pattern: a weak point breaks trust, someone notices, and the rules or practices change.
VI
Part VI: Running PKI
Inventory, renewal, ACME, guarding keys and running a CA of your own.
Chapter 19
Inventory, expiry and renewal
Every certificate expires and lifetimes keep shrinking, so you need an inventory, an owner for each certificate, monitoring of what servers really send, and automated renewal.
Chapter 20
ACME and the 47-day schedule
ACME lets software prove control of a name, then fetch, renew and install certificates automatically: the only practical way to live with very short certificate lifetimes.
Chapter 21
Guarding the keys: HSMs and key ceremonies
A CA is only as trustworthy as its private keys, so they live in certified hardware, are created in witnessed ceremonies and are used only under multi-person control.
Chapter 22
A CA of your own: private two-tier PKI
A private CA lets you issue certificates for internal systems under your own rules, built safely as an offline root plus an online issuing CA with clear policies and templates.
VII
Part VII: Beyond the browser
Mutual TLS, code and document signing, and device identity.
Chapter 23
Both sides show ID: mutual TLS
In mutual TLS the client also proves who it is, with a certificate and a signature from its private key, so both ends are authenticated before any data flows.
Chapter 24
Signed and sealed: code and document signing
A code or document signature proves who signed a file and that nobody changed it since; a trusted timestamp keeps that proof valid after the signing certificate expires.
Chapter 25
Machines with passports: device identity
A device certificate, installed at the factory with its private key locked in secure hardware, lets a machine prove what it is and who made it, for its whole life.
VIII
Part VIII: The future
Post-quantum cryptography and what changes next.
Chapter 26
Post-quantum cryptography
A large quantum computer would break RSA and elliptic-curve cryptography, so key exchange is already moving to ML-KEM, and signatures and certificates come next.
A
Appendices
Reference pages to keep open while you work.
Glossary: PKI terms in plain words
Every PKI and TLS term used on this site, from ACME to X.509, each with a one-line answer, a fuller explanation and the chapter that teaches it.
Cheat sheet: the certificate commands you actually need
Tested OpenSSL, curl, keytool, Windows and Kubernetes commands for everyday certificate work, grouped by the task you are trying to do.
File formats: PEM, DER, PKCS #12 and friends
The formats are wrappings of the same data: DER is binary, PEM is DER in Base64, PKCS #12 bundles a key with its certificates, and PKCS #7 carries certificates only.
Timeline: how PKI got here
From the first public-key papers in the 1970s to ever-shorter certificate lifetimes and post-quantum key exchange: the milestones and incidents that shaped how certificates work today.
Standards index: the rules behind every chapter
The RFCs, CA/Browser Forum documents, root program policies, NIST standards and EU rules that this handbook relies on, each with what it covers and where to read it.