What is public key infrastructure?

Paired with public-key cryptography, digital certificates act as virtual passports—authenticating the identity and permissions of various users and entities when establishing secure end-to-end communication over public or private networks.

Encompassing elements of software, hardware, policies and procedures, PKI formalizes the process to create, distribute, manage and revoke digital certificates.

Public key infrastructure (PKI) provides protocols to validate the authenticity of the digital certificates that underscore the trust in public key cryptography systems. A cornerstone of cybersecurity, cryptography provides confidentiality, integrity, nonrepudiation and authenticity. PKI adds validity to cryptographic systems by cryptographically binding digital certificates to unique users, institutions, entities and third parties.

The following are the key components of a public key infrastructure.

The ability to establish the secure transfer of information between users, entities and devices enables e-commerce and banking platforms to collect financial information. It also allows Internet of Things (IoT) connected devices to operate safely and establishes confidential lines of communication for secure email web servers.

To send and receive secure information over potentially vulnerable and insecure networks, cybersecurity specialists rely on data encryption to securely encrypt (scramble) and decrypt (unscramble) sensitive data.

The two primary types of data encryption are known as public key cryptography and private key cryptography.

Also known as asymmetric encryption or public key encryption, public key cryptography uses a pair of keys, a shared public key and a private key that is unique to each party. The public key is used for encryption while the private key is used for decryption. Because every user has their own private key, each key pair is unique to each user, while the public key is shared among all users.

Also known as symmetrical or secret key cryptography, private key cryptosystems use only one key for both encryption and decryption. For these types of systems to work, each user must already have access to the same secret key.

Private keys might be shared through a previously established trusted communication channel, such as a private courier or secured line. More practically, they can also be exchanged by using a secure key‑exchange method, such as the Diffie–Hellman key agreement. Safe and effective key management is a primary use of PKI that cannot be devalued.

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), use cryptographic algorithms to establish protected connections between web browsers and servers. They rely on SSL/TLS certificates to confirm user and server identities. These protocols establish secure channels that keep data shared between a user’s browser and a website’s server private and protected from interception by malicious actors.

Cryptography is also used for common messaging applications like email and WhatsApp to provide end-to-end encryption (E2EE) and maintain the privacy of users’ conversations. With E2EE, only the sender and intended recipient can decrypt and read their messages, making it nearly impossible for third parties—including users’ own service providers—to access the content.

While symmetric cryptography is faster, asymmetric cryptography is often more practical and secure. In practice, both types of cryptosystems are often used together. For instance, a user might choose to encrypt a long message by using a symmetric system and then use an asymmetrical system to share the private key. While the asymmetrical system will be slower, the symmetrical key will likely be shorter and faster to decrypt than the full message.

However, both types of systems can be vulnerable to so-called man-in-the-middle (MitM) attacks, in which a malicious eavesdropper might intercept secure data during transmission. In such an attack, a hacker or bad actor might intercept a public key, create their own private key and then replace the authentic public key with one that has been compromised.

The hacker can then intercept encrypted messages sent between the parties over the compromised asymmetric system. After decrypting and reading the contents, they can reencrypt the messages and forward the now‑compromised communication. For the users, the effect would be the same and the effective attack would be undetectable.

To prevent these types of attacks, public key infrastructure (PKI) uses digital certificates—also known as PKI certificates, public key certificates and X.509 certificates—to confirm the identity of people, devices, applications. These certificates verify the owners of the private keys and their corresponding public keys. PKI provides the framework to effectively assign authenticated ownership of cryptographic keys. This framework ensures that when information is sent over an asymmetric cryptosystem, only the verified and intended recipient can decrypt it.

PKI provides the framework to effectively assign authenticated ownership of cryptographic keys. This data ensures that when information is sent over an asymmetric cryptosystem, only the verified and intended recipient can decrypt it.

Used to establish a verifiable identity, a digital certificate contains specific information, including the following details:

• The Distinguished Name (DN) of the owner
• The owner’s public key
• The date of issuance
• An expiration date
• The DN of the issuing CA
• The issuing CA’s digital signature

While all digital certificates are not alike, all valid digital certificates should:

• Contain information for establishing the identity of an individual or entity
• Be issued from a trusted and specified third party Certificate Authority
• Be tamper-resistant
• Contain information to prove their authenticity
• Contain an expiration date

Being able to trust the validity of a digital certificate is critical for establishing a trustworthy PKI, which is why a trusted third party Certificate Authority (CA) is crucial.

Reliable CAs vouch for the identity of certificate holders. They are responsible for creating and issuing digital certificates and the policies, practices and procedures associated with vetting recipients.

Specifically, a CA will establish the following requirements:

• Vetting methods for certificate recipients
• The type of certificate issued
• Associated parameters with each certificate type
• Operational security procedures and requirements

A reputable CA formally documents and publishes these policies to allow users and institutions the opportunity to assess the CA’s security measures and trustworthiness. Once operational, a CA follows a set order of operations to create new digital certificates by using asymmetric cryptography. 

The following steps outline the process to create a new digital certificate:

1. A private key is created and assigned for the certificate recipient along with a corresponding public key.
2. The CA requests and vets any available identifying information for the private key owner. 
3. The public key and identifying attributes are encoded into a certificate signing request (CSR).
4. The key owner signs the CSR to prove possession of the private key.
5. The CA validates the request and signs the digital certificate with the CA’s own private key.

By confirming who owns the private key used to sign a digital certificate, the certificate can be used to verify the certificate holder’s identity. It also confirms the identity and reputation of the CA and as a result the trustworthiness of the certificate itself.

To further establish trust, CAs use their own public and private keys and issue certificates to themselves (self-signed certificates) and each other. This practice requires a CA hierarchy, in which an exceptionally trustworthy CA acts as a root certificate authority, trusted to self-sign their own certificates as well as the certificates of other CAs.

If a CA’s keys are ever compromised, an attacker could issue fraudulent certificates and trigger a major security breach. As such, root certificate authorities mostly operate offline and under the most strict security protocols. If a root CA or a subordinate CA becomes compromised, they must disclose the details of the breach publicly. They are also required to provide certificate revocation lists for any potentially affected certificate holders or recipients.

All of this context makes the security of private keys extra important for CAs. A private key falling into the wrong hands is bad in any case, but it’s devastating for CAs because then someone can issue certificates fraudulently.

Security controls and the impact of loss become even more severe as you move up the chain in a CA hierarchy because there is no way to revoke a root certificate. If a root CA becomes compromised, the organization must make the security breach public. As a result, root CAs enforce the most stringent security measures.

As a best practice, root CAs should store their private keys in NSA‑grade safes within state‑of‑the‑art data centers with around‑the‑clock security through cameras and physical guards. All of these measures might seem extreme, but they’re necessary to protect the authenticity of a root certificate.

Although a root CA should be offline 99.9% of the time, there are certain instances where it does need to come online. Specifically, root CAs need to come online for the creation of public keys, private keys and new certificates. They also need to verify that their own key material is still legitimate and hasn’t been damaged or compromised in any way. Ideally, root CAs should run these tests about two to four times a year.

Finally, it’s important to note that root certificates do eventually expire. Root certificates typically last for 15–20 years (compared to approximately 7 years for certificates from subordinate CAs). Introducing and building trust in a new root isn’t easy, but these certificates must expire because the longer they run, the more vulnerable they become to security risks.