Intermediate18 min

PKI & Certificates

How asymmetric keys and a chain of trust let strangers prove identity.

By the end of this lesson, explain certificate chains, TLS identity, and mutual TLS for service identity.

How deep?
How the pieces actually move.

Public Key Infrastructure (PKI) is how two parties who have never met can trust each other's identity. A certificate binds a public key to a name and is signed by a Certificate Authority (CA). If you trust the CA, you trust every certificate it signs — a transitive chain of trust.

First, the whole system

First, see the whole system. Then we’ll open it up.

Chain of trust

Chain of trust

  1. A root CA signs an intermediate CA, which signs a leaf certificate for a service.
  2. A client that trusts the root therefore trusts the leaf via the chain.
flowchart TB
  root[Root CA] -->|signs| inter[Intermediate CA]
  inter -->|signs| leaf[Leaf cert: service.example.com]
  client[Client] -->|trusts root| root
  client -->|therefore trusts| leaf

In TLS, the server presents its certificate chain; the client verifies the signatures up to a trusted root and checks the name matches. Mutual TLS (mTLS) adds the reverse: the client also presents a certificate, so both sides authenticate. mTLS is the backbone of service-to-service identity in meshes.

Abstraction leak

This is where the abstraction starts leaking.

The hard part of PKI is not signing — it's rotation, revocation, and clock. Certificates expire (an outage if you forget to renew), revocation (CRL/OCSP) is famously unreliable, and a wrong clock rejects valid certs. Short-lived certs sidestep revocation by expiring before it matters.

Expired or misissued certificate

Trigger
A certificate lapses, or a CA is tricked into issuing one for a name it shouldn't.
Symptom
Sudden connection failures (expiry) or silent impersonation (misissuance).
Blast radius
Outage across everything that trusts the cert, or MITM of the affected name.
Mitigation
Automate renewal; short lifetimes; CAA records; certificate transparency monitoring.

Deep dive: Clock Skew

Operational complexity

Long-lived certs are easy to issue but hard to revoke and dangerous when leaked. Short-lived certs (hours) need automation but make revocation almost free. Modern workload identity chooses short-lived + automated.

Why do short-lived certificates reduce the need for revocation?

A certificate that expires in hours limits the window a leaked one is usable, so it self-revokes before CRL/OCSP would matter.

Certificates prove a service's identity on the wire. How do dynamic workloads get certificates automatically, without humans?

Next: Workload Identity →