Certificate pinning is the process of associating a host with their expected X.509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or ‘pinned’ to the host.
A host or service’s certificate or public key can be added to an application at development time, or it can be added upon first encountering the certificate or public key. The former, adding at development time, is preferred since preloading the certificate or public key out of band usually means the attacker cannot taint the pin. If the certificate or public key is added upon first encounter, this is known as key continuity. Key continuity can fail if the attacker has a privileged position during the first encounter.
Mobile applications should utilise either certificate or public key pinning in order to ensure that communications are secure. This is usually implemented when the developer of the application needs to validate the remote host’s identity or when operating in a hostile environment. Since one or both of these are almost always true, it is recommended that the majority of applications implement pinning.
Certificate and Public Key Pinning | OWASP Foundation
Certificate pinning can be implemented in a great many different ways. The pinning strategy should be carefully designed as there are many trade-offs to consider:
These decisions will affect the security but also the longevity of the solution. For example, pinning connections against the whole certificate chain will be the more robust strategy, but if any of the certificates in the chain change (for legitimate reasons) then the application will be unable to establish connections without users updating to a newer/rectified version. As another example, if the application pins connections against the leaf certificate’s public key, connections will remain securely pinned even if the CA is compromised.