Certificate Pinning
Certificate pinning hardcodes which keys or certificates a client trusts, blocking connections secured by fraudulently issued certificates for that host.
Definition
Certificate pinning is a client-side control that restricts a host to a known set of public keys or certificate hashes, so a certificate issued by any other authority, including a compromised or coerced CA, is rejected during the TLS handshake.
Context and scope
Use it in mobile apps, embedded devices, and high-value desktop clients that ship on a slow release cycle and talk to a small set of owned endpoints.
Common misconceptions
- Pinning the leaf certificate is safest; leaf certificates rotate frequently and will brick clients
- Pinning replaces certificate validation; it supplements a normal chain and hostname check
- Browser HPKP is a viable option; it was deprecated and removed
Anti-patterns
- Shipping a single pin with no backup key and no emergency rotation plan
- Pinning a certificate that expires sooner than the app's supported lifetime
- Pinning a third-party CDN or analytics domain the team does not control
Related concepts
Related examples
Authoritative source
https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
Pinning narrows trust
TLS trusts roughly 150 public certificate authorities. Any one of them can issue a certificate for a domain, by mistake or under pressure. Pinning replaces that broad trust with a short allowlist: the client accepts only the keys the operator shipped, even if the presented chain is otherwise valid.
How it works
The client computes a hash of the server’s Subject Public Key Info (SPKI) and compares it with embedded pins. If the key is not in the set, the connection fails before any HTTP request. Pinning the public key rather than the certificate lets the operator renew certificates with the same key without shipping an app update.
Robust deployments ship at least two pins: the current key and an offline backup key that is not yet in use. Rotation then becomes a staged process: deploy a new key alongside the old one, ship an app update with the new pin, wait for adoption, then retire the old key.
When to use it
Pinning fits mobile apps and firmware where the endpoint set is small, owned, and stable. It raises the cost of man-in-the-middle attacks using mis-issued certificates. It makes little sense for browsers or for third-party domains, where the operator cannot coordinate rotation with the client.
Trade-offs
The failure mode is severe: a wrong pin or a lost key bricks every installed client until an update ships. Pinning also breaks corporate TLS inspection, which some enterprises require. Certificate Transparency monitoring detects mis-issuance without that risk, so many teams use it as the primary control and reserve pinning for high-value mobile traffic.
Example and misconceptions
A banking app pins the SPKI hash of its API key plus a backup key held offline. When a CA mistakenly issues a certificate for the API host, the app refuses the connection and users are unaffected.
The common misconception is that pinning the leaf certificate is the strictest and therefore best choice. It is the most brittle; key pinning with backups is the durable pattern.
Related concepts: TLS, Mutual TLS (mTLS), and Zero Trust.