What Is Certificate Pinning?

What is Certificate Pinning?

Chrome deprecated HTTP Public Key Pinning (HPKP), the web standard that allowed sites to define public-key pins, in 2018 and removed support entirely with Chrome 72 in 2019. Certificate pinning has continued to be used in mobile apps and API clients, and shorter certificate lifetimes are making that choice more operationally demanding, especially for teams that pin individual certificates. With the maximum lifetime for publicly trusted TLS certificates now at 200 days, set to fall to 100 days in 2027 and 47 days in 2029, certificate-level pinning will require increasingly frequent updates and careful coordination.

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 rather than relying solely on certificates trusted by the operating system’s certificate store. During a standard TLS handshake, a client validates the server’s certificate, including verifying that it chains to an appropriate trusted root, is valid for the requested hostname, is within its validity period, and satisfies applicable certificate-status and policy checks.

Pinning adds another check on top of normal TLS certificate validation: the certificate, public key, or other pinned value presented by the server must match a value the client expects. If it doesn’t match, the connection is rejected even if the certificate would otherwise pass normal TLS validation.

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 static key pinning in Chrome in 2011, building in a list of trusted public keys for Google’s own domains. That same year, those pins helped expose fraudulent google.com certificates issued through the compromised DigiNotar CA. Chrome and Firefox later let websites opt in through HTTP Public Key Pinning (HPKP) response headers. HPKP turned out to be a liability: a site that lost access to its pinned key, or had a malicious pin set during a compromise, could lock users out for the configured lifetime of the pin. Chrome deprecated HPKP in 2018 and removed support in early 2019, while Firefox stopped honoring HPKP headers in 2020. Major browsers no longer support HPKP as a way for websites to establish their own pins. Browsers may still maintain built-in pins for a limited set of domains, but websites can no longer ask a browser to create pins on their behalf through HPKP.

Mobile and IoT pinning followed a different path. App developers have greater control over the client and the servers it communicates with, allowing them to distribute updated pins through application updates or other securely designed pin-management mechanisms and maintain backup pins to accommodate key changes. Current OWASP Mobile Application Security Verification Standard (MASVS) guidance includes identity pinning for remote endpoints under the developer’s control, and connected devices that communicate with a fixed set of backend servers can use pinning for similar reasons. OWASP also recommends pinning public keys rather than entire certificates where appropriate, which can reduce problems caused by certificate expiration and renewal.

That’s why “certificate pinning” today generally refers to app-level, device-level, or API-client pinning rather than something an ordinary website can ask a browser to enforce.

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. When a leaf certificate is pinned directly in an application’s code or configuration, certificate rotation may require distributing an updated pin to clients before the certificate changes. App store rollouts, staged updates, and users who simply don’t update on schedule can all complicate that process. That process was more forgiving when certificates lasted over a year. Under CA/Browser Forum Ballot SC-081, the maximum validity period for publicly trusted TLS certificates dropped to 200 days on March 15, 2026, and will fall to 100 days on March 15, 2027, and 47 days on March 15, 2029. Teams that directly pin leaf certificates therefore need a rotation strategy capable of keeping pace with increasingly frequent certificate renewals.

Pinning the public key, typically its Subject Public Key Info (SPKI), instead of the full certificate can reduce some of that pressure because a renewed certificate can retain the same public key and therefore continue matching the existing pin. However, routinely reusing a key pair simply to preserve a pin is not considered good key-management practice, so applications should instead plan for key rotation using backup pins or pinsets. Pinning an intermediate CA’s key can provide greater flexibility across leaf certificate renewals, but it also broadens the application’s trust and does not eliminate rotation risk. Intermediate CAs and their keys can change, so this approach still requires a carefully designed rotation and fallback strategy.

Exploring Better Alternatives to Certificate Pinning

Several alternative approaches can bolster the security of client-server connections without the associated challenges:

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 organizations whose threat model still justifies pinning, pinning the Subject Public Key Info (SPKI) rather than the entire certificate can provide greater flexibility during certificate renewal. A renewed certificate can continue matching an existing SPKI pin if it uses the same key pair. However, routinely reusing a key pair simply to preserve a pin is not considered good key-management practice. Applications that require pinning should instead plan for key rotation and use pinsets that include backup or future keys so that certificates and keys can be changed without disrupting connectivity.

Conclusion

In conclusion, while certificate pinning can enhance the security of client-server connections by reducing the risk of man-in-the-middle attacks, it is not without its drawbacks. The complexity of maintaining and updating pinned certificates, reduced flexibility in dynamic environments, the risk of connection disruptions, and lack of scalability can make it a less practical choice for many applications. Instead, consider exploring alternative approaches like Certificate Transparency (CT) and Online Certificate Status Protocol (OCSP) Stapling, which offer robust security measures without the inherent limitations of certificate pinning. By choosing the right security mechanism for your specific use case, you can ensure a safer and more efficient communication between clients and servers.

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