Implementing a Public Key Infrastructure

Digital Certificate

A digital certificate is essentially a wrapper for a subject's public key. As well as the public key, it contains information about the subject and the certificate's issuer or guarantor. The certificate is digitally signed to prove that it was issued to the subject by a particular CA. The subject could be a human user (for certificates allowing the signing of messages, for instance) or a computer server (for a web server hosting confidential transactions, for instance). Digital certificates are based on the X.509 standard approved by the International Telecommunications Union. This standard is incorporated into the Internet Engineering Taskforce's RFC 5280 (http://tools.ietf.org/html/rfc5280) and several related RFCs. The Public Key Infrastructure (PKIX) working group manages the development of these standards. RSA also created a set of standards, referred to as Public Key Cryptography Standards (PKCS), to promote the use of public key infrastructure.

key revocation and renewal

A key (or more typically, a digital certificate) may be revoked or suspended. A revoked key is no longer valid and cannot be "un-revoked" or reinstated. A suspended key can be re-enabled. A certificate may be revoked or suspended by the owner or by the CA for many reasons. For example, the certificate or its private key may have been compromised, the business could have closed, a user could have left the company, a domain name could have been changed, the certificate could have been misused in some way, and so on. These reasons are codified under choices such as Unspecified, Key Compromise, CA Compromise, Superseded, or Cessation of Operation. A suspended key is given the code Certificate Hold. Certificate and Key Renewal Typically, a certificate is renewed before it expires. Where a user is in possession of a valid certificate, less administration is required (in terms of checking identity) than with a request for a new certificate. When you are renewing a certificate, it is possible to use the existing key (referred to specifically as "key renewal") or generate a new key (the certificate is "re-keyed"). A new key might be generated if the old one was no longer considered long enough or if any compromise of the key was feared. Expiration When a key has expired, it is no longer valid or trusted by users. An expired key can either be archived or destroyed. Destroying the key offers more security, but has the drawback that any data encrypted using the key will be unreadable. Whether a key is archived or destroyed will largely depend on how the key was used. In software terms, a key can be destroyed by overwriting the data (merely deleting the data does not provide security). A key stored on hardware can be destroyed by a specified erase procedure or by destroying the device.

Key Generation and usage

A key or key pair is a pseudo-randomly generated integer of the required size (1024-bit or 2048-bit, for instance), expressed in binary DER or ASCII PEM encoding. Generating integers that are sufficiently random is not a trivial task, and it is possible to make a mistake, leading to a weak key (one that is easier to crack). The process is also CPU-intensive, meaning that it often must be undertaken on dedicated hardware, such as a hardware security module (HSM). Keys (or certificates) have different usages, as set out in the Certificate Policy Statement. In the case of key pairs used for secure email and communications, a key pair used to encrypt a document (providing confidentiality or digital sealing) should not be used to sign a document (providing authentication and non-repudiation). If the same private key is used for both purposes, and the key is compromised, then both uses of the key are threatened. If a key is used for signing only, it can be destroyed, and a new key issued if the original one is compromised. A key used for encryption cannot be destroyed so easily, as the data encrypted by it has to be recovered first. Consequently, an email user may require multiple key pairs represented by multiple certificates. The security requirements for key usage will also determine the key's length. Longer keys are more secure, and critical processes (such as identifying the root CA) should use long keys (4096-bit). Data processing servers are likely to use 2048-bit keys, rather than 1024-bit keys, especially if there is any regulatory compliance involved. Conversely, a certificate issued to a smartphone or tablet or Internet of Things (IoT) device might need to use a shorter key to reduce the amount of CPU processing and power required for each operation using the key.

SSL Web Server certificate types

A server certificate guarantees the identity of e-commerce sites or any sort of website to which users submit data that should be kept confidential. One of the problems with SSL is that anyone can set up a PKI solution. It is also simple to register convincing-sounding domain names, such as my-bank-server.com where the "real" domain is mybank.com. If users choose to trust a certificate in the naïve belief that simply having a certificate makes a site trustworthy, they could expose themselves to fraud. There have also been cases of disreputable sites obtaining certificates from third-party CAs that are automatically trusted by browsers that apparently validate their identities as financial institutions. Differently graded certificates might be used to provide levels of security; for example, an online bank requires higher security than a site that collects marketing data. Domain Validation (DV)—proving the ownership of a particular domain. This may be proved by responding to an email to the authorized domain contact or by publishing a text record to the domain. This process can be highly vulnerable to compromise. Extended Validation (EV)—subjecting to a process that requires more rigorous checks on the subject's legal identity and control over the domain or software being signed. EV standards are maintained by the CA/Browser forum (https://cabforum.org). When creating a web server certificate, it is important that the subject matches the Fully Qualified Domain Name by which the server is accessed, or browsers will reject the certificate. If using multiple certificates for each subdomain is impractical, a single certificate can be issued for use with multiple subdomains in the following ways: 1- Wildcard domain—the certificate is issued to the parent domain and will be accepted as valid for all subdomains (to a single level). Wildcard certificates cannot be issued with Extended Validation (EV). 2- Subject Alternative Name (SAN)—the subdomains are listed as extensions. If a new subdomain is added, a new certificate must be issued. Both these methods can cause problems with legacy browser software and some mobile devices. There is also greater exposure for the servers operating each subdomain should the certificate be compromised. Using separate certificates for each subdomain offers better security.

online vs offline CAs

An online CA is one that is available to accept and process certificate signing requests, publish certificate revocation lists, and perform other certificate management tasks. Because of the high risk posed by compromising the root CA, a secure configuration involves making the root an offline CA. This means that it is disconnected from any network and usually kept in a powered-down state. The drawback is that the CRL must be published manually. The root CA will also need to be brought online to add or update intermediate CAs.

PKI Trust Models

Another critical concept in PKI is the idea of the trust model. A trust model shows how users and different CAs are able to trust one another. Single CA In this simple model, a single CA issues certificates to users; users trust certificates issued by that CA and no other. The problem with this approach is that the single CA server is very exposed. If it is compromised, the whole PKI collapses. Hierarchical (Intermediate CA) In the hierarchical model, a single CA (called the root) issues certificates to several intermediate CAs. The intermediate CAs issue certificates to subjects (leaf or end entities). This model has the advantage that different intermediate CAs can be set up with different certificate policies, enabling users to perceive clearly what a particular certificate is designed for. Each leaf certificate can be traced back to the root CA along the certification path. This is also referred to as certificate chaining or a chain of trust. The root's certificate is self-signed. In the hierarchical model, the root is still a single point of failure. If the root is damaged or compromised, the whole structure collapses. To mitigate against this, however, the root server can be taken offline as most of the regular CA activities are handled by the intermediate CA servers. Another problem is that there is limited opportunity for cross-certification; that is, to trust the CA of another organization. Two organizations could agree to share a root CA, but this would lead to operational difficulties that could only increase as more organizations join. In practice, most clients are configured to trust multiple root CAs.

OCSP and stapling

Another means of providing up-to-date information is to check the certificate's status on an Online Certificate Status Protocol (OCSP) server, referred to as an OCSP responder. Rather than return a whole CRL, this just communicates the status of the requested certificate. Details of the OCSP responder service should be published in the certificate. Note: Most OCSP servers can query the certificate database directly and obtain the real-time status of a certificate. Other OCSP servers actually depend on the CRLs and are limited by the CRL publishing interval. One of the problems with OCSP is that the job of responding to requests is resource intensive and can place high demands on the issuing CA running the OCSP responder. There is also a privacy issue, as the OCSP responder could be used to monitor and record client browser requests. OCSP stapling resolves these issues by having the SSL/TLS web server periodically obtain a time-stamped OCSP response from the CA. When a client submits an OCSP request, the web server returns the time-stamped response, rather than making the client contact the OCSP responder itself.

Certificate Policies

Certificate policies define the different uses of certificate types issued by the CA, typically following the framework set out in RFC 2527 (http://www.ietf.org/rfc/rfc2527.txt). As an example of a policy, you could refer to the US federal government's common policy framework for PKI (https://idmanagement.gov/topics/fpki/). Different policies will define different levels of secure registration and authentication procedures required to obtain the certificate. A general purpose or low-grade certificate might be available with proof of identity, job role, and signature. A commercial grade certificate might require in-person attendance by the authorized person. A CA will issue many different types of certificates, designed for use in different circumstances.

Certificate Revocation List (CRL)

It follows that there must be some mechanism for informing users whether a certificate is valid, revoked, or suspended. CAs must maintain a certificate revocation list (CRL) of all revoked and suspended certificates, which can be distributed throughout the hierarchy. A CRL has the following attributes: 1- Publish period—the date and time on which the CRL is published. Most CAs are set up to publish the CRL automatically. 2- Distribution point(s)—the location(s) to which the CRL is published. 3- Validity period—the period during which the CRL is considered authoritative. This is usually a bit longer than the publish period (for example, if the publish period was every 24 hours, the validity period might be 25 hours). 4- Signature—the CRL is signed by the CA to verify its authenticity. The publish period introduces the problem that a certificate might be revoked but still accepted by clients because an up-to-date CRL has not been published. Another problem is that the CRL Distribution Point (CDP) may not be included as a field in the certificate. A further problem is that the browser (or other application) may not be configured to perform CRL checking, though this now tends to be the case only with legacy browser software.

Certificate and Key management

Key management refers to the operations at various stages in a key's lifecycle. A key's lifecycle may involve the following stages: Key generation—creating a secure key pair of the required strength, using the chosen cipher. Certificate generation—to identify the public part of a key pair as belonging to a subject (user or computer), the subject submits it for signing by the CA as a digital certificate with the appropriate key usage. At this point, it is critical to verify the identity of the subject requesting the certificate and only issue it if the subject passes identity checks. Storage—the user must take steps to store the private key securely, ensuring that unauthorized access and use is prevented. It is also important to ensure that the private key is not lost or damaged. Revocation—if a private key is compromised, it can be revoked before it expires. Expiration and renewal—a key pair that has not been revoked expires after a certain period. Giving the key or certificate a "shelf-life" increases security. Certificates can be renewed with new key material. Note: Key management also deals with symmetric secret keys, with the problem of secure distribution being particularly acute. Key management can be centralized (where one administrator or authority controls the process) or decentralized (where each user is responsible for his or her keys). In very general terms, keys issued to servers and appliances are likely to be managed centrally, while some provision is made for users to be able to request keys dynamically. Certificate and key management can represent a critical vulnerability if not managed properly. If an attacker can obtain a private key, it puts both data confidentiality and identification/authentication systems at risk. If an attacker gains the ability to create signed certificates that appear to be valid, it will be easy to harvest huge amounts of information from the network as the user and computer accounts he or she sets up will be automatically trusted. Finally, if a key used for encryption is accidentally destroyed, the data encrypted using that key will be inaccessible, unless there is a backup or key recovery mechanism.

Public and Private Key Usage

Public key cryptography solves the problem of distributing encryption keys when you want to communicate securely with others or authenticate a message that you send to others. When you want others to send you confidential messages, you give them your public key to use to encrypt the message. The message can then only be decrypted by your private key, which you keep known only to yourself. Note: As encryption using a public key is relatively slow, rather than encrypting the whole message using a public key, more typically, the public key is used to encrypt a symmetric encryption key for use in a single session and exchange it securely. The symmetric session key is then used to encrypt the actual message. When you want to authenticate yourself to others, you create a signature and sign it by encrypting the signature with your private key. You give others your public key to use to decrypt the signature. As only you know the private key, everyone can be assured that only you could have created the signature. The basic problem with public key cryptography is that you may not really know with whom you are communicating. The system is vulnerable to Man-in-the-Middle attacks. This problem is particularly evident with e-commerce. How can you be sure that a shopping site or banking service is really maintained by whom it claims? The fact that the site is distributing public keys to secure communications is no guarantee of actual identity. How do you know that you are corresponding directly with the site using its certificate? How can you be sure there isn't a Man-in-the-Middle intercepting and modifying what you think the legitimate server is sending you? Public Key Infrastructure (PKI) aims to prove that the owners of public keys are who they say they are. Under PKI, anyone issuing public keys should obtain a digital certificate. The validity of the certificate is guaranteed by a certificate authority (CA). The validity of the CA can be established using various models, described later.

key recovery and escrow

Keys such as the private key of a root CA must be subject to the highest possible technical and procedural access controls. For such a key to be compromised would put the confidentiality and integrity of data processed by hundreds or thousands of systems at risk. Access to such critical encryption keys must be logged and audited and is typically subject to M-of-N control. M-of-N control means that of N number of administrators permitted to access the system, M must be present for access to be granted. M must be greater than 1, and N must be greater than M. For example, when m=2 and n=4, any two of four administrators must be present. Staff authorized to perform key management must be carefully vetted, and due care should be taken if these employees leave the business. Note: Another way to use M-of-N control is to split a key between several storage devices (such as three USB sticks; any two of which could be used to recreate the full key). If the private key or secret key used to encrypt data is lost or damaged, the encrypted data cannot be recovered unless a backup of the key has been made. A significant problem with key storage is that if you make multiple backups of a private key, it is exponentially more difficult to ensure that the key is not compromised. On the other hand, if the key is not backed up, the storage system represents a single point of failure. Key Recovery defines a secure process for backing up keys and/or recovering data encrypted with a lost key. This process might use M-of-N control to prevent unauthorized access to (and use of) the archived keys. Escrow means that something is held independently. In terms of key management, this refers to archiving a key (or keys) with a third party. This is a useful solution for organizations that don't have the capability to store keys securely themselves, but it invests a great deal of trust in the third party. Note: Historically, governments have been sensitive about the use of encryption technology (clearly, it is as useful to terrorists, criminals, and spies as it is to legitimate organizations). In the 1990s, the US government placed export controls on strong keys (128-bit and larger). It also tried to demand that all private keys were held in escrow, so as to be available to law enforcement and security agencies. This proposal was defeated by powerful counter arguments defending civil liberty and US commercial interests. Such arguments have resurfaced as governments and their security agencies attempt to restrict the use of end-to-end encryption and try to insert backdoors into encryption products.

key storage and distribution

Once generated, an asymmetric private key or symmetric secret key must be stored somewhere safe (a repository). If these keys are not appropriately secured, the PKI might appear to be functional, but there is the risk of information exposure (anyone obtaining a private or secret key can use it to decrypt a message) or inaccurately attest to the identity of a particular person (a private key could be misused to impersonate a digital signature). Key storage can be either software- or hardware-based. In software-based storage, the key is stored on a server. Security is provided by the operating system ACLs. This is sufficient in some cases, but it would not be considered secure enough for mission-critical key storage. Software-based distribution of keys (or in-band distribution) should take place only over a secured network. Hardware-based storage and distribution is typically implemented using removable media, a smart card, or at the higher end, a dedicated key storage hardware security module (HSM). A smart card may be a credit card style device, a USB device, or a SIM card (used with smartphones). A smart card may therefore support a variety of interfaces, including a card reader or USB port. The main consideration with media and smart card-based storage is to physically secure the device and to keep the access method (typically protected by a passcode) secure. Another option is to use a Trusted Platform Module (TPM) chip in a PC or laptop to generate, store, and protect key material. Third-party key management HSM products, such as RSA Certificate Manager, AEP Keyper, or Certicom Trust Infrastructure, offer enterprise key management options. There are a variety of solutions, some combining hardware and software devices and systems. One of the advantages of this type of system is that the process is often automated, meaning that the keys cannot be compromised by human involvement. HSMs can be implemented in several form factors, including rack-mounted appliances, plug-in PCIe adapter cards, and USB-connected external peripherals.

Key Usage Extensions

One of the most important standard extensions is Key Usage. This extension defines the purpose for which a certificate was issued, such as for signing documents or key exchange. The Extended Key Usage (EKU) field—referred to by Microsoft as Enhanced Key Usage—is a complementary means of defining usage. Typical values used include Server Authentication, Client Authentication, Code Signing, or Email Protection. The EKU field is more flexible than the Key Usage field, but problems can occur when non-standard or vendor-specific object identifiers (OIDs) are used. An extension can be tagged as critical. This means that the application processing the certificate must be able to interpret the extension correctly; otherwise, the certificate should be rejected. In the case of a Key Usage extension marked as critical, an application should reject the certificate if it cannot resolve the Key Usage value. This prevents a certificate issued for signing a Certificate Revocation List (CRL), for example, from being used for signing an email message. If key usage is not marked as critical, it effectively serves as a comment, rather than controlling the certificate in any way.

PGP/GPG Encryption

PGP stands for Pretty Good Privacy, which is a popular open standard for encrypting email communications and which can also be used for file and disk encryption. It supports the use of a wide range of encryption algorithms. PGP actually exists in two versions. The PGP Corporation develops a commercial product (now owned by Symantec). However, PGP has also been ratified as an open Internet standard with the name OpenPGP (RFC 4880). The principal implementation of OpenPGP is Gnu Privacy Guard (GPG), which is available for Linux and Windows (gpg4win). The commercial and open versions of PGP are broadly compatible. In OpenPGP, for encrypting messages (symmetric encryption), you can use 3DES, CAST, Blowfish/Twofish, AES, or IDEA. For signing messages and asymmetric encryption, you can use RSA, DSA, or ElGamal. OpenPGP supports MD5, SHA, and RIPEMD cryptographic hash functions. To use PGP, a user needs to install PGP software (usually available as a plug-in for the popular mail clients). The user then creates his or her own certificate. In order to provide some verification that a certificate is owned by a particular user, PGP operates a web of trust model (essentially users sign one another's certificates). The contents of X.509 and PGP certificates are similar. The main difference is that PGP certificates can be signed by multiple users, while X.509 certificates are signed by a single CA. PGP certificates can also store more "friendly" information about the user (though this type of data could be added using attribute extensions to X.509 certificates).

Registration and CSRs

Registration is the process by which end users create an account with the CA and become authorized to request certificates. The exact processes by which users are authorized and their identity proven are determined by the CA implementation. For example, in a Windows Active Directory network, users and devices can often auto-enroll with the CA just by authenticating to Active Directory. Commercial CAs might perform a range of tests to ensure that a subject is who he or she claims to be. It is in the CA's interest to ensure that it only issues certificates to legitimate users or its reputation will suffer. Note: On a private network (such as a Windows domain), the right to issue certificates of different types must be carefully controlled. The Windows CA supports access permissions for each certificate type so that you can choose which accounts are able to issue them. When a subject wants to obtain a certificate, it completes a Certificate Signing Request (CSR) and submits it to the CA. The CSR is a Base64 ASCII file containing the information that the subject wants to use in the certificate, including its public key. The format of a CSR is based on the PKCS#10 standard. The CA reviews the certificate and checks that the information is valid. For a web server, this may simply mean verifying that the subject name and FQDN are identical and verifying that the CSR was initiated by the person administratively responsible for the domain, as identified in the domain's WHOIS records. If the request is accepted, the CA signs the certificate and sends it to the subject. The registration function may be delegated by the CA to one or more registration authorities (RAs). These entities complete identity checking and submit CSRs on behalf of end users, but they do not actually sign or issue certificates.

Certificate fields, extensions, OIDs

The X.509 standard defines the fields (information) that must be present in the certificate. The standard provides interoperability between different vendors. The information shown in the certificate includes the following: Version: The X.509 version supported (V1, V2, or V3). Serial Number: A number uniquely identifying the certificate within the domain of its CA. Signature Algorithm: The algorithm used by the CA to sign the certificate. Issuer: The name of the CA, expressed as a distinguished name (DN). Valid From/To: Date and time during which the certificate is valid. Subject: The name of the certificate holder, expressed as a distinguished name (DN). Public Key: Public key and algorithm used by the certificate holder. Extensions: V3 certificates can be defined with extended attributes, such as friendly subject or issuer names, contact email addresses, and intended key usage. The certificate fields are expressed as object identifiers (OIDs), using the syntax defined in Abstract System Notation One (ASN.1). Certificate extensions, defined for version 3 of the X.509 format, allow extra information to be included about the certificate. An extension consists of: Extension ID (extnID)—expressed as an OID. Critical—a Boolean (True or False) value indicating whether the extension is critical. Value (extnValue)—the string value of the extension. Public certificates can use standard extensions; that is, an OID defined in the X.509 documentation, which all clients should support. Certificates issued for private use can use private, proprietary, or custom extensions, but may need dedicated or adapted client and server software to interpret them correctly.

Certificate Authority (CA)

The certificate authority (CA) is the person or body responsible for issuing and guaranteeing certificates. Private CAs can be set up within an organization for internal communications. Most network operating systems, including Windows Server, have certificate services. For public or business-to-business communications, however, the CA must be trusted by each party. Third-party CA services include Comodo, Digicert, GlobalSign, and Symantec's family of CA brands (VeriSign, GeoTrust, RapidSSL, and Thawte). The functions of a CA are as follows: 1- Provide a range of certificate services useful to the community of users serviced by the CA. 2- Ensure the validity of certificates and the identity of those applying for them (registration). 3- Establish trust in the CA by users and government and regulatory authorities and enterprises, such as financial institutions. 4- Manage the servers (repositories) that store and administer the certificates. 5- Perform key and certificate lifecycle management.

certificate issues

The most common problem when dealing with certificate issues is that of a client rejecting a server certificate (or slightly less commonly, an authentication server rejecting a client's certificate). If the problem is with an existing certificate that has been working previously, check that the certificate has not expired or been revoked or suspended. If the problem is with a new certificate, check that the key usage settings are appropriate for the application. Some clients, such as VPN and email clients, have very specific requirements for key usage configuration. Also check that the subject name is correctly configured and that the client is using the correct address. For example, if a client tries to connect to a server by IP address instead of FQDN, a certificate configured with an FQDN will be rejected. If troubleshooting a new certificate that is correctly configured, check that clients have been configured with the appropriate chain of trust. You need to install root and intermediate CA certificates on the client before a leaf certificate can be trusted. Be aware that some client applications might maintain a different certificate store to that of the OS. In either case, verify that the time and date settings on the server and client are synchronized. Incorrect date/time settings are a common cause of certificate (and other) problems. From a security point of view, you must also audit certificate infrastructure to ensure that only valid certificates are being issued and trusted. Review logs of issued certificates periodically. Validate the permissions of users assigned to manage certificate services. Check clients to ensure that only valid root CA certificates are trusted. Make sure clients are checking for revoked or suspended certificates.

Certificate Formats

There are various formats for encoding a certificate as a digital file for exchange between different systems. All certificates use an encoding scheme called Distinguished Encoding Rules (DER) to create a binary representation of the information in the certificate. A DER-encoded binary file can be represented as ASCII characters using Base64 Privacy-enhanced Electronic Mail (PEM) encoding. The file extensions .CER and .CRT are also often used, but these can contain either binary DER or ASCII PEM data. Additionally, the .PFX or .P12 (PKCS #12) format allows the export of a certificate along with its private key. This would be used to archive or transport a private key. This type of file format is password-protected. The private key must be marked as exportable. The P7B format implements PKCS #7, which is a means of bundling multiple certificates in the same file. It is typically in ASCII format. This is most often used to deliver a chain of certificates that must be trusted by the processing host. It is associated with the use of S/MIME to encrypt email messages. P7B files do not contain the private key.

Other certificate types

Web servers are not the only systems that need to validate identity. There are many other certificate types, designed for different purposes. Machine/Computer Certificates It might be necessary to issue certificates to machines (servers, PCs, smartphones, and tablets), regardless of function. For example, in an Active Directory domain, machine certificates could be issued to Domain Controllers, member servers, or even client workstations. Machines without valid domain-issued certificates could be prevented from accessing network resources. Machine certificates might be issued to network appliances, such as routers, switches, and firewalls. Email/User Certificates An email certificate can be used to sign and encrypt email messages, typically using S/MIME or PGP. The user's email address must be entered in the Subject Alternative Name (SAN) extension field. On a directory-based local network, such as Windows Active Directory, there may be a need for a wider range of user certificate types. For example, in AD there are user certificate templates for standard users, administrators, smart card logon/users, recovery agent users, and Exchange mail users (with separate templates for signature and encryption). Each certificate template has different key usage definitions. Code Signing Certificates A code signing certificate is issued to a software publisher, following some sort of identity check and validation process by the CA. The publisher then signs the executables or DLLs that make up the program to guarantee the validity of a software application or browser plug-in. Some types of scripting environments, such as PowerShell, can also require valid digital signatures. Root Certificate The root certificate is the one that identifies the CA itself. The root certificate is self-signed. A root certificate would normally use a key size of at least 2048 bits. Many providers are switching to 4096 bits. Self-Signed Certificates Any machine, web server, or program code can be deployed with a self-signed certificate. Self-signed certificates will be marked as untrusted by the operating system or browser, but an administrative user can choose to override this.

certificate pinning

When certificates are used by a transport protocol, such as SSL/TLS, there is a possibility that the chain of trust between the client, the server, and whatever intermediate and root CAs have provided certificates can be compromised. If an adversary can substitute a malicious but trusted certificate into the chain (using some sort of proxy or Man-in-the-Middle attack), they could be able to snoop upon the supposedly secure connection. Pinning refers to several techniques to ensure that when a client inspects the certificate presented by a server or a code-signed application, it is inspecting the proper certificate. This might be achieved by embedding the certificate data in the application code or by submitting one or more public keys to an HTTP browser via an HTTP header, which is referred to as HTTP Public Key Pinning (HPKP).