What Is Certificate Pinning?

What is Certificate Pinning?

Chrome dropped support for browser-based certificate pinning back in 2018. Mobile apps kept pinning anyway, and a wave of shorter certificate lifetimes is about to make that choice more expensive than most teams expect.

Certificate pinning is a security technique that ties a client, typically a mobile app or API client, to a specific certificate, public key, or certificate authority instead of trusting anything the operating system’s certificate store accepts. During a standard TLS handshake, a client checks that the server’s certificate chains up to a trusted Certificate Authority (CA) and hasn’t expired or been revoked. Pinning adds one more check on top of that: the certificate or key presented also has to match a value the client already has on file. If it doesn’t match, the connection is rejected, even if every other browser or OS on the planet would have accepted that certificate as valid.

How does Certificate Pinning Work?

1. Standard Certificate Validation: In a typical TLS handshake, when a client connects to a server, the server presents its digital certificate to the client. The client then checks the certificate’s authenticity by verifying that it has been signed by a trusted Certificate Authority (CA) and that it hasn’t expired or been revoked. If the checks pass, the client proceeds with the secure connection.
2. Pinning Trust: Certificate pinning takes the trust verification a step further. Instead of solely relying on the CA system, the client’s application or device has a preconfigured list of public keys or certificates that it explicitly trusts

Browser Pinning vs. App-Level Pinning: What Changed

Certificate pinning didn’t disappear. It moved.

Google introduced pinning in Chrome in 2011, hardcoding which CAs the browser would accept for google.com. Chrome and Firefox later let any site opt in through HTTP Public Key Pinning (HPKP) response headers. HPKP turned out to be a liability: a site that lost its pinned key, or had a malicious pin set during a brief compromise, could lock out its own visitors for the header’s entire max-age, sometimes a year or more. Chrome removed HPKP support in 2018, and no major browser offers a pinning header today.

Mobile and IoT pinning followed a different path. Apps distributed through app stores don’t face the “lock out every visitor” risk the same way a website does, and pentest guidance (OWASP’s Mobile Application Security Verification Standard among them) still treats pinning as a control worth having for apps handling sensitive data. That’s why “certificate pinning” today mostly means app-level or API-client pinning, not anything a browser does on its own.

What are the Disadvantages of Certificate Pinning?

The four operational problems pinning creates haven’t changed, and the industry consensus on them has hardened. Microsoft, Google, AWS, Cloudflare, and OWASP now widely discourage static pinning of publicly trusted certificates, not because pinning fails to work, but because in the public Web PKI it tends to create more operational risk than it removes.

1. 1. Maintenance Complexity: Certificate pinning necessitates that clients maintain a list of trusted certificates or public keys. However, this list must be continuously updated to reflect changes in server certificates. As certificates have expiration dates and are regularly renewed, the process of keeping pinned certificates up-to-date can be cumbersome, prone to human error, and may lead to disruptions in service.
   2. Reduced Flexibility: In dynamic and cloud-based environments where server certificates change frequently (e.g., content delivery networks or microservices), certificate pinning can pose operational challenges. The inflexibility of pinned certificates can hinder smooth transitions during server updates and complicate certificate management.
   3. Risk of Breaking Connections: Pinning a certificate to an application introduces the risk of connectivity loss if the pinned certificate becomes compromised or expires. This could result in service interruptions for users until the client application is updated with the new pinned certificate.
   4. Lack of Scalability: Certificate pinning can be impractical for large-scale applications or services that need to communicate with numerous servers, each with its own certificate. Managing a multitude of pinned certificates becomes unwieldy and may undermine the benefits of certificate pinning itself.

Shorter Certificate Lifetimes Are Raising the Stakes

Every one of the four problems above gets worse as certificate validity periods shrink. A pinned leaf certificate has to live inside a compiled app binary, and app store rollouts, staged updates, and users who simply don’t update on schedule all take time to catch up. That gap was manageable when certificates lasted over a year. It gets a lot less forgiving as the industry moves toward much shorter certificate lifespans: CA/Browser Forum ballots are steadily cutting maximum certificate validity down from today’s figure toward 47 days by the end of the decade. Teams still pinning leaf certificates should expect to renew and redeploy their pins far more often than their release cadence was built for.

Pinning the public key (SPKI) instead of the full certificate absorbs some of that pressure, since a certificate can renew without the underlying key, and therefore the pin, changing. Pinning an intermediate CA’s key buys more time between rotations, but CAs do rotate intermediates, sometimes with little warning, so that approach still needs a plan.

Exploring Better Alternatives to Certificate Pinning

Several alternative approaches can bolster the security of client-server connections without pinning’s maintenance burden:

1. Certificate Transparency (CT): Certificate Transparency is a public log of all issued certificates, providing transparency and accountability in the issuance process. By monitoring CT logs, clients can detect unauthorized or fraudulent certificates. This approach doesn’t rely solely on pinning but adds a layer of trust verification, allowing clients to identify rogue certificates without pinning-specific maintenance.
2. Online Certificate Status Protocol (OCSP) Stapling: OCSP stapling allows servers to provide clients with a digitally signed assertion about the status of their SSL/TLS certificates. By using OCSP stapling, clients can verify the validity of a server’s certificate without relying solely on CA trust. It’s a more dynamic approach that doesn’t require pinning and reduces the risk associated with outdated certificates.
3. Public Key (SPKI) Pinning: For teams that still need pinning, for example a mobile app handling payment or health data, pinning the Subject Public Key Info hash instead of the full certificate is the more resilient version of the same control. The certificate around that key can rotate on a 47-day cycle without breaking a single deployed client, as long as the key itself stays the same.

Conclusion

Certificate pinning still has a legitimate home: mobile and API clients handling sensitive data, where the team controls both ends of the connection and has a real plan for rotating pins. Outside that case, current guidance from OWASP and the major cloud providers points away from static pinning and toward Certificate Transparency and OCSP stapling, which deliver similar protection without hardcoding a value that breaks the app the day it changes. If pinning is genuinely warranted, pin the public key rather than the full certificate, and build the rotation plan before certificate lifespans force the issue.

 

Get assistance today. Fill out the form below to get in touch with our sales team.