Certificate Pinning Sounds Great Until You Brick Your App in Production

Cybersecurity

Pinning prevents MITM attacks, but a misconfigured pin or a forgotten cert rotation can brick every installed copy of your app overnight. Here's how to pin without putting yourself one bad day from a customer-incident hotline.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 25, 2024 · 7 min read

I worked with a fintech in 2023 that pinned the leaf certificate of their API. They rotated the certificate in production on a Thursday afternoon. The app stopped working for every customer simultaneously. The hotfix release took 72 hours to clear the iOS App Store review. They lost an estimated $2M in transaction volume and an unmeasurable amount of trust.

Certificate pinning is one of those security controls that is genuinely effective and easy to deploy in a way that ends careers. The mechanic is simple: the app refuses to trust any certificate except the one(s) you specify, even if the device trust store would otherwise accept it. The problem is operational: pins outlive certificates if you don't engineer the rotation, and once your app is shipped you can't quickly fix it.

What to Pin

The choices are leaf certificate, intermediate CA, or root CA. Each trades security for operational flexibility.

• Leaf certificate: strongest binding, but pin breaks on every certificate rotation (typically every 1-2 years, or 90 days with Let's Encrypt)
• Intermediate CA: rotation only when the intermediate changes (every few years), still blocks attacker-issued certs from random other CAs
• Root CA: longest stability, but trusts every certificate the root has ever issued, much weaker security guarantee
• Subject Public Key Info (SPKI) pin: bind to the public key rather than the certificate; survives certificate rotation as long as the key is reused

The pragmatic answer for most apps: pin the SPKI of the intermediate, and include backup pins. SPKI pinning means you can rotate the certificate (re-issue with the same key) without breaking the pin. Backup pins mean you've already shipped trust for a future key, so you can rotate keys with a planned switchover.

Implementation Mechanics

On iOS, use NSPinnedDomains in App Transport Security (iOS 14+) or roll your own with URLSessionDelegate. ATS pinning supports SPKI hashes and expiration dates per pin. On Android, use Network Security Configuration XML to declare pin sets. Both let you specify multiple pins per domain (primary plus backup) and expiration dates that auto-disable the pin.

Libraries worth using: TrustKit (iOS and Android), OkHttp's CertificatePinner (Android), Alamofire's ServerTrustManager (iOS). They handle the verification logic, expose hooks for failure reporting, and let you ship pinning with kill switches.

The Rotation Plan You Have to Build Before Shipping

1. Pin two keys at minimum: current and next. Never ship with one pin
2. Set pin expiration dates 90 days after the longest-supported app version's expected sunset
3. Build a kill switch, a remote config flag that disables pinning if you have to ship a fix
4. Schedule certificate rotation to the next key 30 days before the current pin expires
5. Push an app update that adds the third key before retiring the first one, always have N+1 pins active

The kill switch is controversial. If an attacker can disable pinning by tampering with the remote config flag, you've created a backdoor in your own security control. The mitigation is signing the kill switch config with a separate key, requiring two-person approval to flip it, and shipping the config over an independent channel. Worth the engineering investment because the alternative is being unable to recover from a pinning bug.

What Pinning Actually Defends Against

Pinning blocks attackers who can issue valid certificates from a real CA but don't control your specific pinned cert. That includes: nation-state actors with CA compromises (DigiNotar, Symantec history), enterprise MITM proxies that install their own root certs on managed devices, attackers exploiting a misissued cert via subverted DNS, and a wide class of mobile reverse-engineering attacks that rely on intercepting the API.

It does not block: attackers who compromise the actual server, attackers who steal the pinned certificate's private key, jailbroken/rooted devices where pinning libraries can be hooked. Frida and Objection can bypass pinning on rooted devices in seconds. Pinning raises the bar; it does not close the room.

When Not to Pin

Apps that mostly communicate with third-party APIs you don't control should think hard before pinning. You don't get to control when Salesforce rotates their cert. Apps with infrequent update cycles (medical devices, embedded apps, enterprise apps with long approval cycles) should consider pinning only the highest-sensitivity flows. The blast radius of a bricked release is proportional to how fast you can ship a fix.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.