What Is Certificate Pinning?

What is certificate pinning?

Certificate pinning is an online application security techniqueused to authenticate client-server connections. Web browsers use this mechanism to have a client application validate the server's certificate against a known copy. If they match, it would be considered authorized ("pinned"). Any attemped secure connection requests utilizing certificates other than those that are pinned are refused.

Applications most commonly pin an X.509 certificate, though just a trusted Certificate Authority (CA) or public key can also be pinned. Additionally, even public keys can be pinned, not being tied to a single certificate.

Pinning was originally devised as a means of thwarting man-in-the-middle attacks (MITM). However, it has largely become obsolete due to its complexity and risks, and most web browsers no longer support it. When pinning was a more common practice, most companies implemented it incorrectly, leading to several outages. Doing pinning inccorectly can have a devastating consequences. For this reason, Sectigo recommends against using certificate pinning.

Below, we'll go into the history of the technique, how it works, the benefits, and the risks.

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 certificate pinning work?

At its foundation, certificate pinning is quite simplistic: it is 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. 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 risky. 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 replace 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.

Alternatives to certificate pinning

While there is not a 1-to-1 alternative to certficate pinning, there are techniques that accomplish the same goal. The cost common alternative is Certificate Transparency (CT). This is an open framework used to monitor and audit all public SSL certificates issued by CAs. When a CA issues a publicly-trusted SSL certificate, it submits the detail to the Certificate Transparency logs. These logs are publicly accessible, allowing browsers to confirm that a certificate was issued correctly. Organization should also monitor CT logs to confirm the issuance of certificates to their domain names.

In addition, automated certificate lifecycle management (CLM) is the ideal approach to ensuring the certificates being authenticated are always secure and up-to-date throughout all of the lifecycle stages: request and enrollment, issuance and provisioning, usage and monitoring, and expiration and renewal, as well as revocation. Learn about the CA-agnostic certificate lifecycle management platform from Sectigo.

You can also listen to our Root Causes podcast to learn more about certificate pinning, how it came about, and why nearly all developers should avoid certificate pinning today.

Want to learn more? Get in touch to book a demo of Sectigo Certificate Manager!

Related posts:

What is an X.509 certificate and how does it work?

What is certificate revocation & when should an SSL certificate be revoked?

Stages of the Certificate Lifecycle Explained in Simple Terms