Part 5 · 2 chapters · ~12 min

PKI and Certificates

What a certificate is (X.509 fields, subject alternative names, key usage), certificate authorities and trust stores, chains and intermediates, domain validation and ACME, Certificate Transparency, revocation and why it struggles, private CAs for internal mTLS, and certificate pinning trade-offs.

9

Chains of trust

code
openssl s_client -connect api.bank.example:443 -servername api.bank.example -showcerts </dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
# subject=CN = api.bank.example
# issuer=C = US, O = Let's Encrypt, CN = R11
# notBefore / notAfter: a 90-day window
# X509v3 Subject Alternative Name: DNS:api.bank.example, DNS:bank.example
CERTIFICATES AND CHAINS
who vouches for a public key, all the way to a root you already trust
root CAin the OS/browser trust storeintermediate CAsigned by rootleaf certificateapi.bank.example, signed by intermediateCertificate Transparency logspublic, append-onlyACME (Let's Encrypt)automated issuancerevocationOCSP, CRLs, short lifetimes
swipe the figure sideways, or tap expand for full screen
1/5
the problem
A public key is just bytes. How does a browser know this key really belongs to api.bank.example? Someone trusted must vouch for it.
who says this key is theirs?a trusted third party vouches
10

Internal PKI and pinning

Internal services use a private CA (Vault PKI, cert-manager, a mesh CA) issuing short-lived certificates for mTLS (Mesh course, Auth part 6). Pinning (an app accepting only specific keys for your API) blocks interception by rogue CAs, but a botched rotation bricks every installed app version; if used, pin an intermediate or multiple backup keys, and keep a server-driven escape hatch.