Public key infrastructure (PKI) is the combination of certificate authorities, digital certificates, cryptographic keys, software and policies that lets people and systems trust that a public key really belongs to who it claims to. It underpins secure websites through Transport Layer Security (TLS), signed email and software, and certificate-based login for users and devices. Most organizations use public PKI for their websites and run, or buy, a private PKI for internal systems.
At a glance
- PKI binds identities, such as websites, users, devices or software, to public keys using signed digital certificates.
- Certificate authorities (CAs) issue certificates; a chain of trust runs from an issuing CA up to a root that systems already trust.
- It supports encryption in transit, digital signatures and certificate-based authentication.
- Most PKI failures are operational: expired certificates, unknown certificates and poorly protected private keys.
- Shorter public certificate lifetimes and the coming move to post-quantum algorithms are pushing organizations toward automation.
What problem it solves
Public key cryptography uses pairs of keys: a public key that can be shared freely and a private key that is kept secret. Data encrypted with a public key can only be read with the matching private key, and a signature made with a private key can be checked with the public one. That solves the problem of exchanging secrets over an untrusted network, but leaves another: how do you know a public key really belongs to your bank, your VPN gateway or your colleague, and not to an attacker?
PKI answers that question. A trusted third party, the certificate authority, checks an identity and issues a certificate tying it to a public key. Software that trusts the authority can then trust the key. For a business, that means encrypted connections that can’t easily be impersonated, devices and users that can prove who they are without passwords, and signed documents and software that show they haven’t been altered.
How it works
Key pairs. Each user, device or service generates a public and private key. The private key should never leave the system that owns it, or a hardware security module (HSM) for high-value keys.
Certificates. The owner sends a certificate request to a certificate authority. A registration step, sometimes handled by a separate registration authority, verifies the identity. The CA then issues a signed certificate, typically in the X.509 format, containing the public key, the identity, the issuer and an expiry date.
Chain of trust. Root CAs, whose certificates are built into browsers, operating systems or your managed devices, sign intermediate CAs, which sign end certificates. A system checking a certificate follows that chain up to a root it already trusts.
Revocation. If a key is compromised or a certificate is issued in error, it can be revoked, and relying systems check revocation lists or online status services.
Policies and operations. Certificate policies define who can get which certificates, how identities are verified and how keys are protected. Day to day, certificate lifecycle management (CLM) tracks every certificate, its owner and expiry, and automates renewal.
Common uses include TLS for websites and APIs, signed and encrypted email (S/MIME), code signing, VPN and Wi-Fi authentication, smart cards and device identity for laptops, servers and IoT equipment.
When it matters for buyers
- After an expired-certificate outage. These are common and avoidable; they usually signal a missing inventory and manual renewals.
- As public certificate lifetimes shrink. More frequent renewals make automation necessary, not optional.
- When moving to passwordless or device-based access. Certificate-based authentication for devices and users relies on a well-run private PKI.
- When your internal CA is old. Legacy CAs on unsupported servers, weak algorithms or keys without hardware protection are a real risk.
- When planning for post-quantum cryptography. You will need an inventory of where certificates and keys are used before you can migrate.
Questions to ask vendors
- Do you provide public certificates, private CAs or both, and how are our CAs hosted and protected?
- How are private keys for the CAs stored, and are HSMs used?
- How do you discover existing certificates across our environment, including ones issued outside your platform?
- Which renewal and deployment steps can be automated, and for which servers, devices and cloud services?
- How is revocation handled, and how quickly does it take effect?
- What is your roadmap for post-quantum algorithms?
- How is the service priced: per certificate, per CA, or by device or user count?
How it differs from Resource Public Key Infrastructure (RPKI)
Despite the similar name, Resource Public Key Infrastructure (RPKI) is a specialized system for internet routing. It uses certificates, run by the regional internet registries, to prove which networks may announce which IP address ranges, so other networks can reject false routes. General-purpose PKI, the subject of this entry, proves the identity of websites, users, devices and software for encryption, signing and authentication. Both rely on certificates and chains of trust, but they serve different purposes and are run by different authorities. PKI is also one building block of zero trust security, which uses certificate-based device and service identity among many other controls. Our access management page covers how certificate-based authentication fits into identity security.
Problems this helps with
- An expired certificate took down our website or VPN
- Nobody knows how many certificates we have or who owns them
- Our internal certificate authority was set up years ago by someone who left
- Need devices and users to authenticate without passwords
