Certificate pinning is a security technique where an app is hard-coded to trust only a specific server certificate (or its public key), instead of trusting any certificate that a certificate authority happens to vouch for. This means that even if an attacker tricks a device into accepting a fraudulent-but-valid certificate, the app will refuse to connect because the certificate does not match the one it was told to expect. It is one of the strongest defenses against man-in-the-middle attacks on encrypted connections.
Content Table
How normal SSL certificate validation works
Before you can understand pinning, you need the baseline. When your phone or browser connects to a server over HTTPS, it runs a chain of checks called SSL certificate validation (technically TLS now, but everyone still says SSL). The device asks: is this certificate legitimate?
The standard process looks like this:
- The server presents a certificate that says "I am api.example.com."
- The certificate is signed by a certificate authority (CA) such as DigiCert, Let's Encrypt, or GlobalSign.
- Your device checks that the signing CA is on its trusted root store, that the certificate hasn't expired, and that the domain name matches.
- If everything checks out, the connection proceeds. If not, you see a certificate mismatch warning.
The weak point here is trust in CAs. Your device trusts hundreds of root certificate authorities out of the box. If any one of them is compromised, tricked, or coerced into issuing a certificate for your domain, the fraudulent certificate will pass standard validation just fine. That is exactly what happened in the 2011 DigiNotar breach, where attackers issued rogue certificates for Google and other domains.
What certificate pinning adds on top
Certificate pinning narrows the trust from "any valid CA-signed certificate" down to "this exact certificate or key that I already know about." The app ships with a copy (or a cryptographic fingerprint) of the expected certificate baked into its code.
During the handshake, the app does the normal validation and then one more check:
1. Server sends its certificate
2. App checks CA signature, expiry, domain (standard validation)
3. App computes the certificate/public-key fingerprint
4. Does the fingerprint match the pinned value?
YES -> connect
NO -> abort the connection immediately
Because step 4 depends on a value the developer chose in advance, a rogue certificate from a compromised CA fails the check even though it is technically valid. The pin doesn't care who signed it; it cares whether it is the exact key the app expects.
Certificate pinning vs public key pinning
People say "SSL pinning" loosely, but there are two distinct things you can pin, and the difference matters for maintenance.
| Approach | What you pin | Trade-off |
|---|---|---|
| Certificate pinning | The whole leaf certificate | Breaks every time the certificate is renewed, even if the key is unchanged. Frequent app updates needed. |
| Public key pinning | Just the public key (SPKI hash) | Survives certificate renewal as long as you reuse the key. Most common choice today. |
Public key pinning is usually preferred because certificates expire on a schedule (often every 90 days with Let's Encrypt), but the key pair underneath can be kept steady across renewals. There used to be a browser standard called HPKP (HTTP Public Key Pinning), but browsers dropped it because too many sites bricked themselves by pinning keys they later lost. Mozilla's own MDN documentation now marks HPKP as deprecated. Pinning today lives almost entirely inside mobile and desktop apps, not web pages.
Why apps bother with pinning
Pinning is extra work, so apps only reach for it when the stakes are high. Common cases:
- Banking and payment apps that cannot afford a single intercepted session.
- Messaging apps protecting private conversations from network snooping. If you care about that side of things, our guide on keeping private messages truly secure covers the broader picture.
- Corporate apps handling sensitive internal data where a breach turns into a headline. Pinning is one layer in the wider effort to prevent corporate data leaks.
The core benefit is defeating the interception scenario. On public Wi-Fi, a hostile hotspot, or a network with a malicious proxy, an attacker might present a forged certificate to sit in the middle of your traffic. Pinning slams that door. It's a natural complement to strong encryption in transit, and it directly frustrates the kind of message interception attacks that rely on impersonating a trusted server.
The downsides and risks of pinning
Pinning is powerful but brittle. The same rigidity that stops attackers can also lock out legitimate users.
- Certificate rotation breaks things. If the pinned certificate is replaced and the app wasn't updated, every user gets a SSL certificate mismatch and the app stops connecting until they update.
- Backup pins are mandatory. Responsible implementations pin at least two keys: the live one and a backup you can switch to in an emergency. Pin only one, and losing that key can permanently brick the app for existing installs.
- Corporate proxies and antivirus break. Many enterprise networks inspect TLS traffic by installing their own root CA. Pinning refuses that inspection, which can be a feature or a support headache depending on your users.
- False sense of completeness. Pinning protects the transport layer. It does nothing against a compromised device, weak passwords, or leaked credentials, so it should sit alongside good privacy best practices.
How certificate pinning gets bypassed
Pinning stops network-level attackers, but it isn't magic, especially if someone controls the device the app runs on. Security researchers and reverse engineers routinely perform certificate pinning bypass to inspect app traffic during testing.
Typical bypass methods on a device the tester controls:
- Runtime hooking with tools like Frida or Objection, which intercept the pinning check function and force it to always return "valid."
- Rooted or jailbroken devices where the app's memory and code can be modified freely.
- Repackaging the app after editing out the pinning logic, then re-signing it.
The important takeaway: pinning defends against attackers on the network path , not against an attacker who fully owns the endpoint. That is why apps often combine pinning with root/jailbreak detection and tamper checks. Together they raise the cost, but a determined attacker with a controlled device can still get in. Pinning is a strong layer, not a complete fortress, which is the same lesson behind understanding how safe end-to-end encryption really is.
Generate the SHA-256 fingerprints certificate pinning relies on
Public key pinning needs a SHA-256 hash of your certificate or key. Our free hash generator produces those fingerprints instantly, right in your browser, so you can build and verify your pins without pasting keys into a sketchy website.
Generate a hash →
No. SSL/TLS encrypts the connection so nobody can read the data in transit. Certificate pinning adds an identity check on top, making sure your app is talking to the real server and not an impostor holding a fraudulent-but-valid certificate. You need both working together.
The web standard HPKP was deprecated because too many sites accidentally locked themselves out by pinning keys they later lost or rotated. A single mistake could make a site unreachable for months. Pinning survives in mobile apps, where developers control both ends and can ship updates.
If the app pins the certificate itself and it expires without an app update, users get a certificate mismatch and can no longer connect. This is why developers use backup pins and often pin the public key instead of the full certificate, since keys can survive renewals.
Yes, if someone controls the device. Tools like Frida can hook into the app at runtime and disable the pinning check, and rooted or jailbroken phones make this easier. Pinning stops attackers on the network, but it cannot protect against someone who fully owns the endpoint.
Not necessarily. Pinning adds maintenance overhead and can break connectivity if mishandled. It makes the most sense for high-value apps like banking, messaging, and healthcare, where an intercepted connection is catastrophic. Lower-risk apps often rely on standard TLS validation and careful certificate management instead.