Certificate Pinning

Certificate pinning lets you declare: "I don't care what the CA system says. I only trust these certificates." It's a powerful statement—and a dangerous one.

The danger isn't theoretical. When browsers supported HTTP Public Key Pinning (HPKP), websites could instruct browsers to reject any certificate that didn't match their pins. Some sites configured this, then lost access to their private keys. Server crash. Backup failure. Human error. Suddenly their site was permanently inaccessible to every user whose browser had cached those pins. No recovery mechanism existed. The sites were simply gone.

Browsers removed HPKP. The security benefits didn't justify the operational catastrophe risk.

But pinning didn't die—it moved to mobile apps, where the tradeoffs are different.

Why Pinning Exists

Normal certificate validation trusts any certificate signed by any CA in your trust store. That's hundreds of organizations worldwide, each capable of issuing a certificate for any domain. If any one of them is compromised, coerced, or careless, attackers can get valid certificates for your domain.

This has happened. Government agencies have compelled CAs to issue surveillance certificates. CAs have been hacked. CAs have made mistakes.

Pinning says: I don't trust the collective. I trust myself. My application will only accept certificates I've explicitly approved, regardless of what the CA system says.

How Pinning Works

You embed a cryptographic fingerprint—typically a SHA-256 hash—of your expected certificate or public key into your application. When the app connects to your server, it receives the certificate, computes the hash, and compares it to the embedded pin. Match means proceed. Mismatch means reject, even if the certificate is otherwise perfectly valid.

This happens in addition to normal validation. Both must pass.

Three Flavors of Pinning

Certificate pinning pins the exact certificate. Most restrictive. Breaks every time you renew the certificate, requiring app updates before each renewal.

Public key pinning pins just the public key. Certificates can be renewed freely as long as you keep the same key pair. This is the sweet spot for most implementations.

CA pinning pins a Certificate Authority. Any certificate from that CA is trusted; certificates from other CAs are rejected. Less restrictive, but still dramatically narrows trust compared to accepting all CAs.

Mobile Apps: Where Pinning Lives Now

Mobile apps are the primary pinning use case today. The math works differently than it did for HPKP:

• You control both the app and the server
• You can push app updates to rotate pins
• Users who don't update eventually churn anyway
• The bricking risk is bounded (worst case: force users to update)

iOS apps implement pinning through URLSession delegate methods. Android apps use Network Security Configuration for declarative pinning or custom TrustManagers for programmatic control.

Banking apps, healthcare apps, and government apps commonly pin their API certificates. The additional protection against CA compromise or network-level attacks justifies the operational overhead—for them.

The Operational Reality

Pinning is a bet that you'll never lose your keys, never botch a rotation, never need to change infrastructure unexpectedly. It's a bet against Murphy's Law.

Every certificate rotation becomes a coordination exercise. End-entity certificate pins require app updates deployed before the certificate changes. Miss that window and your app breaks. Emergency key rotation—after a compromise, say—requires either having backup keys already pinned or pushing emergency app updates while users on old versions can't connect.

Infrastructure changes get complicated. New CDN? Different certificates. New hosting provider? Different certificates. Pins that worked yesterday might brick your app tomorrow.

Making Pinning Survivable

Pin backup keys. Always embed at least two pins: your current key and a backup you've never used. If disaster strikes, you can rotate to the backup without bricking anything.

Pin up the chain. Pinning your intermediate CA's public key instead of your end-entity certificate means you can renew certificates freely—any certificate from that intermediate works. You're still dramatically restricting trust compared to accepting all CAs.

Track expiration obsessively. Know when your certificates expire. Plan app updates months in advance.

Test rotation before production. Simulate certificate changes in staging. Verify your backup pins work. Don't discover problems when users start screaming.

Alternatives Worth Considering

Pinning isn't the only defense against CA compromise.

Certificate Transparency monitoring watches public logs for certificates issued for your domain. You'll know if someone gets a fraudulent certificate—it won't be secret. This doesn't prevent the attack, but it makes it detectable, often within hours.

CAA records tell CAs which authorities are allowed to issue certificates for your domain. Won't stop a compromised CA, but prevents accidental mis-issuance.

Short-lived certificates limit the damage window. A fraudulent certificate that expires in 24 hours is far less dangerous than one valid for a year.

For many applications, these provide better risk-to-complexity ratios than pinning. You get most of the protection without the operational landmines.

The Decision

Pinning makes sense when you control both client and server, have mature certificate management processes, and genuinely need protection beyond what CT monitoring and CAA records provide. High-security mobile apps connecting to dedicated backends are the canonical case.

Pinning doesn't make sense for websites (HPKP is dead for good reason), apps relying on third-party infrastructure you don't control, or teams without clear operational processes for certificate lifecycle management.

The question isn't whether pinning provides security benefits—it does. The question is whether those benefits justify the operational complexity and bricking risk for your specific situation.

For most applications, the answer is no. For some, it's absolutely yes. Know which one you are before you pin.