Certificate Pinning.

Certificate pinning binds a specific TLS server to one or more cryptographic identities — a full leaf certificate, an intermediate, or a SubjectPublicKeyInfo (SPKI) hash — that the client trusts implicitly. During the handshake the client compares the server's chain against the pinned values and aborts on mismatch, even if the chain is signed by a publicly trusted CA. This defeats an attacker holding a fraudulent-but-valid certificate, such as one issued by a compromised or coerced CA (the 2011 DigiNotar and Comodo incidents that led to rogue Google certificates being the classic motivation).

Browser HPKP vs. app pinning

The web tried pinning via HTTP Public Key Pinning (HPKP, RFC 7469, 2015), a Public-Key-Pins response header. It failed in practice: a lost key, a routine rotation without updating pins, or a hostile "RansomPKP" injection could lock users out for the whole max-age. Chrome deprecated HPKP in 2017 and removed it in Chrome 72 (2018), ceding the role to Certificate Transparency logs. Pinning survives mainly in mobile apps talking to a fixed backend (Android Network Security Config, iOS NSPinnedDomains, OkHttp CertificatePinner).

flowchart TD
  A[Client opens TLS to api.example.com] --> B[Server presents certificate chain]
  B --> C{Chain validates against system CAs?}
  C -->|No| E[Abort: standard TLS failure]
  C -->|Yes| D{SPKI hash matches a pinned key?}
  D -->|Yes| F[Connection allowed]
  D -->|No| G[Abort: pin mismatch, block MITM/rogue CA]

Weaknesses and defences

Pinning is only as good as its backup pins — always pin a rollover key. On rooted/jailbroken devices, tools like Frida and objection hook the validation routine to strip pins, so pinning raises the bar for MITM interception but is not a substitute for device attestation. Modern guidance (OWASP MASVS) favours SPKI pinning with short-lived certs and a tested rotation plan.