Certificate Pinning (public key pinning, SSL pinning)

With certificate pinning, a client stores the expected certificate or, more commonly, a hash of a SubjectPublicKeyInfo (SPKI) for a host, and rejects connections whose chain does not match, even if that chain is otherwise valid and trusted. It is mostly used in mobile apps and IoT clients that talk to their own APIs. Browsers tried dynamic pinning through HPKP (RFC 7469), but it was removed from Chrome in Chrome 72 because misconfigured pins could lock sites out.

Why it matters

Pinning narrows trust from every CA in the trust store to the keys you choose, so a misissued certificate or a locally installed corporate root cannot intercept the app's traffic. That is also why pinned apps fail behind SSL inspection. The risk is bricking: if the pinned key changes and no backup pin exists, every installed client stops connecting until it is updated. With maximum certificate validity at 200 days from 2026-03-15 and falling to 47 days from 2029-03-15, pinning a leaf certificate is fragile. Pinning a CA's intermediate is not stable either; Let's Encrypt moved its issuance to new hierarchies in 2026. Pin SPKIs of keys you control, always ship a backup pin, and consider Certificate Transparency monitoring as a lower-risk alternative.

Example

Compute a base64 SHA-256 SPKI pin, the format used by Android's Network Security Config and by the former HPKP header:

openssl x509 -in cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -binary | openssl enc -base64

Common misconceptions

• Pinning the leaf certificate is the safest choice. It breaks at every renewal unless the key is reused; pin keys rather than certificates, and keep a backup.
• HPKP still protects websites. Mainstream browsers no longer enforce HPKP headers.
• Pinning replaces normal certificate validation. It is an extra check on top of chain and hostname validation, not a substitute for them.