What Is Public Key Infrastructure (PKI)?

Public key infrastructure (PKI) is the system of roles, policies, hardware, software, and procedures that creates, manages, distributes, and revokes digital certificates, binding a public key to a verified identity. PKI is what lets a browser and a web server, or two services calling each other for the first time, trust each other without ever having met, and it underpins HTTPS, code signing, secure email, and the certificate-based identity behind modern infrastructure. 

The guide covers what PKI is, how it works, and where PKI is used and where it becomes hard to run at scale. Teleport is built on PKI and issues short-lived certificates to humans, machines, workloads, and AI agents.

Understanding public key infrastructure (PKI)

Public key infrastructure is the set of technology and processes that manages digital certificates and public-key encryption. The role of PKI is to answer if a public key belongs to the person, server, or workload that claims it. PKI answers that question by having a trusted authority sign a certificate that ties the key to a verified identity. 

The question exists because encryption alone cannot establish who you are talking to. Anyone can generate a key pair and claim any name for it, so a client that receives a bare public key has no way to tell a legitimate server from an attacker who substituted their own key. Sharing keys by hand works between two people who already know each other, but the approach collapses at the scale of the internet, where billions of clients connect to servers they have never seen. PKI solves the distribution-of-trust problem by letting everyone rely on a small set of vetted authorities instead of verifying every counterparty directly.

PKI rests on asymmetric cryptography, where every party holds a pair of mathematically related keys. The private key stays secret and signs or decrypts, while the matching public key is shared freely and verifies or encrypts. A signature made with the private key can be checked by anyone holding the public key, which proves the holder controls the private key without ever exposing it. PKI adds the trust layer on top, so a public key comes with a certificate vouching for whose key it is. 

Asymmetric cryptography differs from the symmetric kind, where both sides share one secret key. Symmetric encryption is fast, but the shared key has to reach both parties over a channel an attacker cannot read, which recreates the original problem. Real systems combine the two. In a TLS connection, PKI and asymmetric cryptography authenticate the server and agree on a fresh session key, and the session itself then runs on fast symmetric encryption.

The certificate at the center of all of this follows the X.509 standard, first defined in 1988 and profiled for the internet in RFC 5280. An X.509 certificate carries the subject being identified, the issuer that signed it, the subject’s public key, a validity window with a start and an expiry date, a serial number, and extensions such as the subject alternative names that list the domains a web certificate covers. The issuing authority’s signature covers every field, so any tampering invalidates the certificate.

Every certificate also moves through a defined lifecycle. A requester generates a key pair and submits a signing request, the authority validates the identity and issues the certificate, the certificate is installed and presented in live connections, and it is later renewed, revoked, or allowed to expire. Managing that lifecycle used to be manual, and automation through the ACME protocol, popularized by Let’s Encrypt, now handles issuance and renewal for much of the public web. Lifetimes keep getting shorter, and the CA/Browser Forum has voted to reduce the maximum public TLS certificate lifetime in stages, reaching 47 days by 2029, which makes automation a requirement rather than a convenience.

How does PKI work?

PKI works by having a trusted authority vouch for identities through signed certificates, and by giving every party a way to verify that vouching. 

The starting point is the key pair. Each user, server, or workload generates a private key it keeps secret and a public key it can share. Anything encrypted with the public key can be decrypted only by the private key, and anything signed by the private key can be verified with the public key. 

The digital certificate builds on the key pair. A certificate authority (CA) checks an identity, then issues an X.509 certificate that binds that identity to a public key and signs it with the CA’s own private key. Because the certificate is signed, tampering breaks the signature, and anyone can confirm the certificate came from the CA. 

The chain of trust makes certificates verifiable at scale. Every device already trusts a small set of root CAs, whose certificates ship with operating systems and browsers through the root programs that Microsoft, Apple, Mozilla, and Google maintain. A root CA signs intermediate CAs, which in turn sign end-entity certificates, forming a chain a client can follow back to a root it already trusts. A client accepts a certificate only after it has verified that chain, confirmed the certificate has not expired, and checked that it was not revoked. Revocation happens through a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP), which let a CA declare a certificate invalid before it expires.

The components of a PKI

A working PKI is made of a handful of parts, each with a clear job. The following table names them and what each one does.

The certificate authority is the part that carries the trust. You can go deeper in our article What is a Certificate Authority?

Public PKI vs private PKI

PKI comes in two forms, and the difference is who the certificates are meant to be trusted by. A public PKI issues certificates trusted by the whole internet, which is what secures public websites. Public CAs such as Let’s Encrypt, DigiCert, and Sectigo are audited against industry requirements, and their roots are distributed in every browser and operating system, so a certificate they issue is trusted everywhere without any setup.

A private PKI issues certificates trusted only inside one organization. Teams may run a private PKI to secure internal services, devices, workloads, and machine-to-machine traffic, where a public CA would be unnecessary and slow. A private PKI gives an organization full control over issuance policy and short certificate lifetimes, which is exactly what infrastructure identity depends on. Most companies run both, using public certificates for anything internet-facing and a private PKI for everything internal.

What is PKI used for?

PKI appears almost everywhere trust has to cross a network, usually without anyone noticing. The most common uses are TLS and SSL for HTTPS, which is the padlock that encrypts and authenticates web traffic. Code signing uses PKI so software can prove it came from a real publisher and was not altered, and secure email through S/MIME signs and encrypts messages the same way.

Beyond the browser, PKI authenticates SSH access with certificates instead of static keys, signs documents, and secures VPNs. The fastest-growing use is identity for devices, machines, and workloads, where each non-human actor gets a certificate rather than a shared secret. Identity for non-human actors is why PKI has become the backbone of zero trust and machine identity, which our article What is Workload Identity covers in detail.

The challenges of managing PKI

Running PKI at scale can be challenging for several reasons. Certificates expire, and a single missed renewal takes down a production service or a public site, an outage that has hit major companies more than once. Tracking thousands of certificates across servers, load balancers, and workloads, each with its own expiry, is a real burden, and manual renewal does not keep up as infrastructure grows.

Key management adds more difficulty. Private keys have to be generated, stored, and protected, and a leaked private key undermines every certificate it backs. Long-lived certificates make this worse, because a compromised key stays valuable for as long as the certificate lives. Revocation is the other hard part, since CRLs and OCSP have to reach every client fast enough to close off a compromised certificate. The way through most of these problems is short certificate lifetimes issued automatically, so nothing lives long enough to become a standing liability. Short lifetimes are the bridge from classic PKI to cryptographic identity.

PKI, cryptographic identity, and zero trust

Modern infrastructure security takes the trust that PKI provides and issues it as short-lived cryptographic identity rather than long-lived certificates and static keys. A zero trust architecture depends on verifying every request against a strong identity, and PKI is the technology that makes that identity verifiable. Instead of copying static keys across a fleet and hoping to account for them, each human, machine, workload, and AI agent presents a certificate that proves who it is and expires within hours.

Short-lived certificates eliminate many of the challenges described in the previous section. Nothing has to be rotated by hand because a fresh certificate is issued at each login, offboarding is immediate because access ends when the certificate lapses, and there is no long-lived key sitting in a config file for an attacker to find. Short-lived certificates are the difference between managing static credentials and issuing identity, and they are why teams move from static keys toward certificate-based access. You can read more about these concepts in the articles What is Cryptographic Identity and Credentials vs Cryptographic Identity.