Pinning and mTLS¶

The public CA system answers "is this name vouched for by someone my machine trusts?" Sometimes that's too loose. Any of the dozens of CAs in your trust store can vouch for any name — so a single compromised or coerced CA can mint a cert for your domain. Pinning and mTLS are the two ways you tighten that.

What this page will cover¶

Certificate pinning¶

• What it is — refusing to accept any valid chain except the specific cert (or key, or CA) you expected. "I don't care that the chain validates; I care that it's this key."
• Why — defeats a rogue-but-trusted CA, and a man-in-the-middle holding a technically-valid cert.
• Why it's a loaded gun — the failure mode is self-inflicted outage. You pin a key, the key rotates, you forgot to ship the new pin, and now your own app refuses to talk to your own server. Mobile apps have bricked themselves this way. The page will cover backup pins and why HPKP (the browser version) was deprecated for exactly this reason.
• Where it still makes sense — mobile apps talking to a known backend, embedded devices, anything where you control both ends and the endpoints rarely change.

Mutual TLS (mTLS)¶

• The flip — ordinary TLS proves the server's identity to the client. mTLS makes the client prove itself too: both sides present certs, both sides walk a chain.
• Where it lives — service-to-service auth inside a perimeter. This is the workhorse of zero-trust networking and service meshes (Istio, Linkerd) where every pod proves its identity to every other pod with a short-lived cert.
• Your own CA — mTLS usually means running a private CA whose root you install into your own trust stores. This is the legitimate version of the "self-signed" warning from the main page: not un-vouched-for, but vouched-for by a root you chose to trust. The page will cover issuing, rotating, and revoking those internal certs without a 2am outage.
• In Kubernetes — how a service mesh issues and rotates workload certs automatically, and why "the cert is short-lived and auto-rotated" is the security property that makes mTLS-everywhere practical instead of a maintenance nightmare.

Why it's here¶

If you're building inside a cluster, you'll meet mTLS whether you chose it or not — the mesh does it for you, and the day it breaks, you need to know it's a trust chain problem, not a network problem. And the first time someone proposes pinning, you want to know the failure mode before you ship it, not after.

See also: The TLS Handshake for the exchange both of these modify, and ACME and Automated Issuance for how the short-lived certs that make mTLS practical get minted.