Certificate Pinning

When you visit a website, your browser quietly checks the site’s digital certificate to make sure it’s safe. That’s how HTTPS works. But what if a hacker tricks your browser into trusting a fake certificate? 

Then you’d be utilizing certificate pinning. It’s basically like saying, “Only trust this exact certificate, no exceptions.” But with that power comes risk. One wrong move, and you could lock out your own users.

What Is Certificate Pinning?

Certificate pinning means hardcoding or “pinning” a specific SSL certificate (or public key) into your app or system. Instead of just trusting any valid certificate from a trusted Certificate Authority (CA), your app only trusts one exact certificate or key.

Here’s the logic:

“Even if someone issues a valid certificate for this domain, if it’s not the one I pinned, reject it.”

This protects against:

• Compromised CAs
• Fake or forged certificates
• Man-in-the-middle (MITM) attacks, even if they use valid HTTPS

‍

‍{{cool-component}}‍

‍

How Does Certificate Pinning Work?

There are two common ways to do it:

1. Public Key Pinning (PKP): You pin the public key used by the server's certificate. This lets you rotate the certificate (e.g. for expiry), as long as the public key stays the same.
2. Certificate Pinning: You pin the entire certificate itself, byte-for-byte. This is stricter but more fragile.

You implement it like this:

• In a mobile app: You embed the expected certificate or key into the app binary.
• In a browser (less common now): You use headers like Public-Key-Pins (HPKP), though this has been deprecated due to risks.

When your app makes an HTTPS request:

• It fetches the server certificate
• It compares the received certificate (or key) to the pinned one
• If they don’t match, the connection is blocked

Methods Used in Certificate Pinning

When you implement certificate pinning, you’re choosing what exactly to pin. And this choice matters; it affects how flexible your setup is when certificates need to be renewed or rotated.

Let’s break down the main pinning methods:

1. Full Certificate Pinning

You hardcode the entire SSL certificate into your app; byte for byte. That means only this exact certificate is trusted. Even a small change (like renewal) breaks the connection.

• Pros: Very strict, very secure.
• Cons: High risk of breakage. You'll need to push an app update every time the cert changes.

Use this only if you completely control the backend and have predictable certificate lifecycles.

2. Public Key Pinning (SPKI Pinning)

Instead of pinning the full certificate, you extract and hash the Subject Public Key Info (SPKI) part of the cert. This hash is what you pin.

• Pros: More flexible. You can renew or reissue the certificate, as long as the public key stays the same.
• Cons: Still requires care with key rotation. Not compatible with third-party APIs you don't control.

This is the most recommended method for mobile apps.

3. CA Pinning (Not Recommended)

Here, you pin the certificate authority (CA) instead of the individual cert or key.

• Pros: Certificates issued by the pinned CA are accepted.
• Cons: Becomes pointless if that CA is compromised (which pinning is supposed to prevent). Offers limited protection.

Modern security teams don’t recommend CA pinning, it weakens the entire point of pinning.

Why Certificate Pinning Fails (And Often Does)

You might think: “Why doesn’t everyone just use this?”
Because it’s risky,  very risky. Here’s why:

Certificate pinning failure can happen due to:

• Certificate renewal (your cert changes, and now your app refuses to connect)
• CA rotation or migration
• A pinned certificate expiring
• Clock skew (certificate appears invalid to the client)
• Revoking a compromised cert, but your app still trusts it

And when it fails? Your users get locked out. No fallback. Not even you can connect,  unless you update the app. This is a nightmare if your app is already deployed to millions of devices.

‍

‍{{cool-component}}‍

‍

HTTPS Certificate Pinning in Mobile Apps

In mobile development (especially Android and iOS), SSL certificate pinning is popular among banking apps and security-sensitive platforms.

Here’s how it’s typically done:

• You add the cert hash or key fingerprint in the app’s network config
• You use libraries like OkHttp (Android) or Alamofire (iOS) with custom TrustManagers
• You test rigorously before deployment

But if you pin incorrectly or your certificate changes, your app will stop working, and the only fix is a forced app update.

Example of a Pinning Disaster

Let’s say you run a secure payments app. You pin your current certificate. A year later, your cert expires and you replace it, but forget to update the app. Suddenly, thousands of users can’t connect.

Even worse? If your backend is hosted behind a CDN or cloud proxy like Cloudflare or AWS API Gateway, they might change their certificate without warning. That breaks pinning instantly.

Certificate Pinning Alternatives

If pinning feels too fragile, you’re not alone. Most experts now recommend safer alternatives:

1. Certificate Transparency + Monitoring: Let the browser check for suspicious certs using public logs. No hard pinning needed.

2. Trust on First Use (TOFU): Let your app store the certificate after the first successful connection. Only alert if it changes later.

3. Backend Certificate Validation: Validate certs on your backend instead of client-side. That way you control the validation logic and can update it server-side.

4. Mutual TLS (mTLS): Both client and server authenticate each other. Strong security, but much more complex.

Pinning is still useful in high-security environments; just make sure you have a fallback plan.

Should You Use Certificate Pinning?

Ask yourself:

• Will you control both client and server?
• Can you push updates quickly?
• Are you in a high-risk environment (e.g. financial services, healthcare)?
• Are you OK with the risk of self-inflicted downtime?

If yes, go for it. Just pin public keys, not full certs. And always pin backup keys too.

If not, you’re probably safer using traditional HTTPS with good monitoring, strict TLS configs, and Certificate Transparency.

‍

‍{{cool-component}}‍

‍

Final Thoughts

Certificate pinning gives you laser-focused protection, but it’s also a loaded weapon. It blocks forged certs, yes. But it also blocks you if you’re not careful.

If you’re building something where trust must be airtight and you can manage the rollout process, pinning might be worth it. Otherwise, modern HTTPS practices offer enough protection for most use cases.

‍