What is certificate pinning and what are its trade-offs?

WHAT THIS TESTS: This question probes whether you understand the gap between default TLS and real-world trust chain vulnerabilities on mobile. Interviewers want to see that you know the device trust store is only as strong as its weakest CA, and that you have shipped enough network code to respect operational realities like certificate rotation and emergency patches.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, a crisp definition: certificate pinning means the app bundles or hardcodes an expected server certificate or public key hash and refuses to connect if the presented chain does not match, regardless of whether the system trust store accepts it. Second, the specific attack: man-in-the-middle via a fraudulently issued or compromised CA certificate, which would otherwise pass default validation. Third, the trade-offs: you gain protection against rogue CAs but lose flexibility, so legitimate certificate rotation will break older app versions and may force an emergency release or kill switch. Fourth, maintenance challenges: pinning requires a rotation strategy such as backup pins, a way to deliver updates out-of-band, and careful coordination with your server team to avoid bricking users on long-lived installs.

COMMON WRONG ANSWERS: Common wrong answers include claiming pinning prevents all MITM attacks without mentioning that it does nothing if the attacker controls the device or the pinned material itself. Another red flag is describing it as pure benefit with no cost; senior engineers should immediately mention certificate expiry, rotation, and the risk of locking users out. Confusing pinning with hostname verification or saying it replaces TLS entirely are also signs of shallow knowledge.

LIKELY FOLLOW-UPS: Interviewers often follow up by asking how you would rotate a pinned certificate without breaking existing users, how to implement backup pins, or how Network Security Config on Android differs from OkHttp certificate pinning. They may also ask what you would do if a private key matching a pinned certificate were compromised.

ONE CONCRETE EXAMPLE: Suppose your Android app pins the SHA-256 hash of your API server's leaf public key in OkHttp. Your CA is compromised and an attacker issues a valid cert for your domain; standard devices trust it, but your app rejects it because the public key hash does not match the pinned value. Six months later your server team rotates the key for routine hygiene. Users on the old app version now see SSL handshake failures and cannot refresh content. To mitigate this you should have shipped a backup pin in the original binary and used a staged rollout for the new pin before the old cert expired.