SSL Pinning Explained: What It Is and When to Use It

SSL pinning is a technique that associates a host with a specific certificate or public key, rather than accepting any certificate signed by a trusted certificate authority. Normally, your browser or app trusts any certificate issued by any of the roughly 150 root CAs in its trust store. Pinning narrows that trust to one or a few specific certificates or keys. If the server presents a certificate that doesn't match the pin, the connection is rejected, even if the certificate is perfectly valid and signed by a trusted CA. For foundational context on how certificates work, see our SSL/TLS guide.

Why Pinning Exists

The standard CA trust model has a structural weakness. Every trusted CA can issue a certificate for any domain. If any single CA is compromised, negligent, or coerced, it can issue a fraudulent certificate for your domain that browsers will accept. Historically, this has happened multiple times (DigiNotar in 2011, Symantec/Thawte test certificates in 2015, WoSign/StartCom backdating in 2016).

Pinning addresses this by saying: "I know exactly which certificate or key my server uses, and I will only accept that specific one." This makes man-in-the-middle attacks with fraudulent certificates impossible, even if the attacker obtains a valid certificate from a different CA.

Types of Pinning

There are two main approaches to pinning, and the distinction matters for maintenance and key rotation.

Certificate Pinning

The client stores or references the exact certificate (or its hash) that the server should present. When connecting, the client compares the server's certificate against the stored copy. If they don't match, the connection fails.

This is the strictest form of pinning. It means that when you renew or replace your certificate, you must also update the pin in every client. If you forget, your app stops working.

Public Key Pinning

Instead of pinning the entire certificate, the client pins the public key (specifically, the Subject Public Key Info, or SPKI). Because you can reuse the same public key across certificate renewals (by using the same CSR or key pair), public key pinning survives certificate renewal without needing to update the client.

Public key pinning is generally preferred over certificate pinning because it is more resilient to routine certificate operations. You can renew your certificate, switch CAs, or change other certificate properties, and the pin still works as long as the underlying key pair is the same.

Aspect	Certificate Pinning	Public Key Pinning
What is pinned	Entire certificate or its hash	Public key (SPKI hash)
Survives renewal	No (new cert = new hash)	Yes (if same key pair is reused)
Survives CA change	No	Yes (if same key pair is reused)
Strictness	Higher	Lower (more flexible)
Maintenance burden	Higher	Lower

HPKP: The Browser Standard That Failed

HTTP Public Key Pinning (HPKP) was a web standard (RFC 7469) that let websites instruct browsers to pin their public keys. The server sent an Public-Key-Pins HTTP header containing hashes of its public keys, and the browser would refuse to connect if future connections presented different keys.

HPKP was deprecated by Chrome in 2018 and never gained significant adoption. The reasons illustrate the fundamental tension in pinning.

The bricking problem. If a site configured HPKP and then lost access to all pinned keys (through a key compromise, CA change, or simple operational error), the site became permanently inaccessible to browsers that had cached the pins. The pins could have a max-age of up to 60 days. A misconfiguration could lock users out for months.

The ransom attack. An attacker who gained temporary control of a server (or its HTTP headers) could set HPKP pins to keys only the attacker possessed. This would "brick" the domain for all browsers that received the malicious pins. The domain owner would have no recourse until the pins expired.

Complexity. Correct HPKP deployment required pinning backup keys, carefully managing key rotation, and understanding the consequences of every certificate change. Very few organizations had the operational discipline to manage this safely.

The deprecation of HPKP effectively ended browser-side pinning for the web. Modern browsers do not support it. Chrome, Firefox, Safari, and Edge have all removed HPKP support.

Pinning in Mobile Apps

While browser-side pinning is dead, pinning remains alive and common in mobile applications. Unlike browsers, mobile apps control their own trust decisions and can be updated through app store releases. This makes the operational risks more manageable.

iOS (App Transport Security)

iOS allows pinning through the App Transport Security (ATS) configuration in your app's Info.plist, or through code using URLSession delegate methods. You can pin to specific certificates or public keys. Many iOS apps use third-party libraries like TrustKit, which provides a declarative pinning configuration with built-in reporting.

When a pinned connection fails, the app can catch the error and handle it gracefully (showing an error message, for example) rather than silently failing.

Android (Network Security Config)

Android 7.0 and later support certificate pinning through the Network Security Configuration file (network_security_config.xml). You can declare pins for specific domains:

<domain-config>
  <domain includeSubdomains="true">example.com</domain>
  <pin-set expiration="2027-01-01">
    <pin digest="SHA-256">base64EncodedSPKIHash=</pin>
    <pin digest="SHA-256">backupBase64EncodedSPKIHash=</pin>
  </pin-set>
</domain-config>

The expiration attribute is important. It sets a date after which pinning is disabled, preventing the bricking problem. If your pins expire and you haven't updated the app, connections fall back to standard CA validation rather than failing entirely.

Best Practices for Mobile Pinning

Pin the public key, not the certificate

Public key pinning is more resilient to certificate renewal. You can renew certificates without pushing an app update.

Always include backup pins

Pin at least two keys: your current key and a backup key that you keep securely stored but not yet deployed. If your primary key is compromised, you can rotate to the backup without an emergency app update.

Set pin expiration dates

On Android, use the expiration attribute. On iOS, implement expiration logic in your code. Expired pins should fall back to standard validation, not hard failure.

Pin the intermediate CA instead of the leaf

Pinning to an intermediate CA's public key provides protection against rogue CAs while being more resilient to your own certificate changes. You only need to update pins if your CA changes its intermediate.

Implement pin failure reporting

When a pin validation fails, report it to your backend. This lets you detect potential man-in-the-middle attacks and also catch pinning misconfigurations before they affect all users.

When Pinning Helps

Pinning provides meaningful security benefits in specific scenarios.

High-value mobile apps. Banking apps, healthcare apps, and other applications that handle sensitive data benefit from pinning because they are prime targets for man-in-the-middle attacks. In some regions, users may be subject to state-level interception using locally trusted CA certificates.

Known server infrastructure. When your app communicates with a specific set of servers that you control and whose certificates you manage, pinning is practical. You know what certificates to expect and can plan key rotations.

Zero trust environments. In service-to-service communication within a zero trust architecture, pinning (or mutual TLS, which is a form of pinning) ensures that services only communicate with authenticated peers.

When Pinning Hurts

Pinning can cause more harm than good in several situations.

Websites in browsers. HPKP failed for good reasons. The web is too dynamic and the consequences of misconfiguration too severe. Use Certificate Transparency monitoring and CAA records instead.

Apps with many third-party API integrations. If your app connects to many different services with different certificate lifecycles, pinning each one becomes an operational nightmare. A single provider rotating their certificate can break your app.

Teams without strong certificate management. If your team does not have robust processes for tracking certificate expiry, managing key rotation, and pushing app updates, pinning will eventually cause an outage. The certificate chain must be understood before pinning is implemented.

CDN-fronted applications. If your app connects through a CDN like Cloudflare or AWS CloudFront, the CDN's edge certificates may change without your knowledge. Pinning to CDN certificates is fragile.

Pinning can brick your app

If all pinned keys become unavailable (compromised, rotated, or lost) and you can't push an app update, your app is permanently broken for all users until they update. Always have backup pins and expiration dates. Test your pin failure path before deploying to production.

Alternatives to Pinning

For most use cases, there are alternatives that provide similar security benefits with lower operational risk.

Certificate Transparency monitoring. Monitor CT logs for unauthorized certificates issued for your domain. This detects rogue certificates after issuance rather than blocking them at connection time, but it avoids the bricking risk entirely. See our guide to Certificate Transparency.

CAA records. DNS CAA records specify which certificate authorities are allowed to issue certificates for your domain. This is a preventive control at the CA level. Not as strong as pinning (a compromised CA could ignore CAA), but it stops most misissurance scenarios.

Expect-CT header. This HTTP header (now largely obsolete as CT is mandatory) instructed browsers to enforce Certificate Transparency for a domain. It provided similar benefits to pinning for the web without the bricking risk.

Mutual TLS (mTLS). For API-to-API communication, mTLS provides strong authentication of both parties. It is effectively bidirectional pinning with a more structured management model.

Strong SSL certificate management and regular certificate validation are prerequisites for any pinning strategy. Know your certificates before you pin them.

References

Track every certificate for your domains

SSL Certificate Expiry monitors your certificates and alerts you before they expire. Stay ahead of renewals so pinning never breaks your app.

Try SSL Certificate Expiry