Certificate Pinning in Mobile and Desktop Applications
Implement HPKP, TrustKit-style pinning, and understand the operational risks of pinning.
Why Certificate Pinning Exists
Standard TLS trusts any certificate signed by any of ~150 root CAs pre-installed in the OS. If any root CA is compromised or coerced, an attacker can obtain a certificate for any domain and intercept TLS traffic. Certificate pinning restricts trust to a specific certificate or public key, regardless of which CA signed it. A pinned application rejects connections to its servers unless the server presents the exact expected certificate or key. This protection is particularly valuable for mobile apps where users cannot inspect network traffic and corporate MDM solutions may install enterprise CA roots.
Pin Types: Certificate vs Public Key vs SPKI
There are three granularities of pinning: (1) Full certificate pin — the exact DER-encoded certificate must match. This is the most brittle: it breaks on any certificate renewal. (2) Public key pin — only the SubjectPublicKeyInfo (SPKI) bytes are compared. Survives certificate renewal if the same key pair is retained. (3) Hash of SPKI — store SHA-256(SPKI) rather than the raw key. This is the HTTP Public Key Pinning (HPKP) and Android Network Security Config approach. Public key / SPKI pinning is preferred: it survives CA rotation and certificate renewal while still detecting MITM with a different key pair.
All lessons in this course
- TLS 1.3: 0-RTT, Early Data, and Session Resumption
- Mutual TLS (mTLS) Implementation Patterns
- Certificate Pinning in Mobile and Desktop Applications
- TLS Performance: QUIC and HTTP/3