What Is Certificate Pinning?

History of This Technique

In 2011, Google was among the first organizations to adopt the technique as SSL / TLS certificate pinning was utilized in connecting Chrome browsers to Google servers. Chrome was programmed to accept only the current pinned certificates when attempting to connect domain names to Google.com. So, even in the event that an attacker found a way to dupe a trusted CA issuer into issuing a certificate, it would still be recognized by Chrome as invalid, and the connection rejected.

Though web browsers such as Chrome and Firefox were among the first applications to implement this technique, the range of use cases rapidly expanded. Soon, Internet of Things (IoT) devices, mobile apps for iOS and Android operating systems, along with a disparate collection of software applications, began using this technique to defend against man-in-the-middle attacks.

However, in the fast-morphing world of cybersecurity, SSL certificate pinning has become widely discredited because it carries unacceptable certificate agility costs, and one form, HTTP Public Key Pinning (HPKP), has been deprecated altogether.

How Does SSL Pinning Work?

At its foundation, certificate pinning is quite simplistic: it is merely the process of correlating a host, from which connections will be sought, with the predesignated certificate or the server's public key that conforms to IETF X.509 cryptography standards. Once that association has been established between host and certificate, the relationship between the two is formalized, pinning that certificate to that host. A secure connection with a client or API call is approved only in instances where the offered certificate exists within that set of pinned certificates.

Most often the approved, or pinned, certificate is embedded within an application during the development process. Pinning during development adds a layer of security by making it more difficult for a would-be attacker to compromise the pin. But, they can also be added when an application first attempts to connect — a process known as key continuity. The utilization of key continuity, however, comes with the price of increased risk exposure through attacks that can occur during the initial connection attempt between host and application.

Pinning assumes and utilizes a relationship between client and host that has been both pre-defined and pre-established, with proper protocols and parameters known and accepted by all legitimate participants. This eliminates the necessity of depending upon constant pings to organizational elements — to CAs, for example, for continuous updates about certificate status.

Which Certificates Can Be Pinned?

Application owners are free to choose what in the certificate chain is pinned. At minimum, one certificate in the chain of trust should be controlled solely by the organization that owns the application. However, an oft-repeated mistake is to only pin the root certificate in a chain. This over-simplification of the process leaves a vulnerability through which a bad actor can gain access by leveraging a certificate obtained from the same CA. Therefore, application developers wishing to use this technique should consider pinning more than one or all certificates in the chain including:

• Root Certificates: A root certificate is issued by a trusted CA based on a defined certificate validation method with public and private key combinations that are created by complex cryptographic algorithms and hashing algorithms. It is carefully monitored and protected by the root CA that issues them. That means that the pinning of just a root certificate is, in essence, a demonstration of trust in the CA that issued it, along with any intermediary ones that branch off the root.
• Intermediate Certificate: The intermediate certificate serves as an intermediary between the leaf and root certificates. While there must be at least one intermediate cert in a chain, it is also possible to deploy multiple intermediates within a single chain. It is possible, though not recommended, to perform pinning with only the intermediate one as you place all your trust in the intermediate CA.
• Leaf Certificate: This represents the highest-level cert in a chain. The pinning of a leaf certificate virtually assures a certificate match. Leaf certificates — also known as end-user or end-entity certificates — should typically be revoked and replaced fairly often, requiring corresponding updates to all client applications.

What Are the Benefits?

Certificate pinning offers enhanced control for organizations that wish to custom-design certificate-based authentication and encryption security directly into their online applications and mobile applications. The expectation is that pinning would make it extremely difficult for cybercriminals to successfully utilize fraudulent certificates in gaining illegitimate access to applications or data through:

• The issuance of invalid certificates
• The compromising of certificate authorities
• Man-in-the-middle attacks

What Are the Problems?

While SSL pinning can be effective, it is also quite problematic. This method exposes organizations to costly certificate management challenges and potentially poor user experiences. The following are just some of the common problems that organizations utilizing this technique are likely to face:

• Resolution of compromised keys: When using HPKP, each leaf certificate is commonly pinned to applications for a 60-day period of time. And, quite frequently, an organization utilizing a 60-day operational life for a leaf certificate would fail to designate any backup keys. If it becomes compromised, CAs are required to revoke that key. With no backup key available, legitimate clients are no longer able to connect. Key compromise could be a difficult, costly, and time-consuming problem to resolve.
• Lack of cryptographic agility: Cryptographic changes happen more often than you may think. Crypto agility is necessary when you’re forced to change out certificates with new cryptographic algorithms because you or your CA no longer trust your keys. As pinning hard-codes the certificate requirements into an application, any changes to the certificate require both an update to the certificate as well as an update patch to the application. Updating software can be difficult to implement, especially on a limited timeline, and those clients that do not install the latest application may not be able to access the application or a warning that the application connection is unsecure.
• Revocations of certificates: CAs can and do revoke certificates. Revocations can be triggered by a range of scenarios. An issue that comes to light during the course of an audit, for example, can initiate a revocation. The CA may be required to revoke with little warning, which may not fit into your development roadmap. Similar to cryptographic changes, you may be left scrambling to update your software quickly so that users can access it or avoid warnings.

Listen to our Root Causes podcast to learn more about this technique, how it came about, and why nearly all developers should avoid certificate pinning today.