What is Public Key Infrastructure (PKI)?

PKI is a framework of policies, hardware, software, and procedures that manages digital certificates and public-key encryption. It establishes trust between parties who have never met by binding public keys to verified identities through a chain of trusted certificate authorities.

What is the difference between a CA and a PKI?

A Certificate Authority (CA) is one component within a PKI. The PKI is the broader system — including registration authorities, certificate repositories, CRL/OCSP services, and policies — that governs how CAs issue, revoke, and renew certificates.

How does PKI establish trust?

PKI uses a chain of trust: a root CA signs an intermediate CA's certificate, and the intermediate CA signs end-entity certificates. Your browser or OS trusts the root CA, so it automatically trusts every certificate signed by that root's descendants.

What is PKI used for?

PKI secures HTTPS web traffic, email signing (S/MIME), VPN authentication, code signing, document signing, and smart card login. Any scenario where two parties need to verify each other's identity or exchange encryption keys safely benefits from PKI.

What is an X.509 certificate?

An X.509 certificate is a standardized digital document (defined in RFC 5280) that binds a public key to an identity. It contains the subject's name, the issuing CA's name, the public key, validity dates, and the CA's digital signature proving authenticity.

What happens when a PKI certificate expires or is revoked?

An expired certificate causes browsers to display a security warning and refuse the connection. Revoked certificates are listed in a Certificate Revocation List (CRL) or checked via OCSP; clients that verify revocation status will reject revoked certificates immediately.

Public Key Infrastructure (PKI) Explained

Introduction

Every time you see the padlock icon in your browser, a system called Public Key Infrastructure is silently working to prove you are talking to the right server — not an impostor. Without PKI, every HTTPS session, every encrypted email, and every signed software update would require you to exchange encryption keys in person with every website, bank, and service you use. That is obviously impossible at internet scale. PKI solves this by creating a web of verified trust that covers billions of devices and trillions of daily connections. A compromised PKI — like the 2011 DigiNotar breach that allowed attackers to intercept Gmail traffic for over 300,000 Iranian users — shows exactly how catastrophic it is when this foundation cracks. Understanding how PKI works helps you build, configure, and audit systems that depend on it correctly.

What Is Public Key Infrastructure?

Public Key Infrastructure (PKI) is an ecosystem of cryptographic standards, roles, policies, and software that manages the lifecycle of digital certificates — the documents that bind a public key to a verified identity. Think of PKI as the passport system of the internet: governments (Certificate Authorities) issue passports (certificates) to verified identities, and border agents (TLS clients) check those passports against trusted lists before granting access.

PKI relies on asymmetric cryptography, where every participant holds a mathematically linked key pair: a public key shared openly and a private key kept secret. Anything encrypted with the public key can only be decrypted with the corresponding private key, and anything signed with the private key can be verified with the public key. PKI answers the critical question: how do you know a public key truly belongs to the entity claiming to own it? The answer is a Certificate Authority (CA) — a trusted third party that signs the certificate, staking its reputation on the binding between key and identity. For a deep dive on how these organizations verify identities and issue certificates, read What Is a Certificate Authority (CA).

How Public Key Infrastructure Works

PKI operates through a structured set of roles and workflows:

Key pair generation: An entity — a web server, a person, a device — generates a public/private key pair locally. The private key never leaves the entity’s control.
Certificate Signing Request (CSR): The entity creates a CSR — a digitally self-signed message containing its public key, its identity information (domain name, organization), and the intended uses for the certificate.
Validation by a Registration Authority (RA): The Registration Authority (RA) verifies the identity claims in the CSR. For a domain-validated (DV) certificate, this means proving control of the domain. For extended validation (EV), it requires legal identity verification.
Certificate issuance by the CA: After the RA approves the request, the Certificate Authority (CA) digitally signs the certificate with its own private key, producing a valid X.509 certificate. This signature is the proof of authenticity.
Trust chain validation: When your browser connects to a server, it receives the server’s certificate plus any intermediate CA certificates. It walks the chain — checking each certificate’s signature against the issuer above it — until it reaches a root CA that is pre-installed in your browser or OS as trusted.
Revocation checking: The client checks whether any certificate in the chain has been revoked — due to compromise or error — using a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP).

The PKI chain of trust: every end-entity certificate traces back to a root CA trusted by the client. Revocation services allow the chain to be invalidated when a certificate is compromised.

IBM Technology breaks down the core components of PKI — watch how they explain the relationship between root CAs, intermediate CAs, and the certificate chain that your browser validates on every HTTPS connection.

PKI vs Self-Signed Certificates

Feature	PKI-issued Certificate	Self-Signed Certificate
Trust	Pre-trusted by browsers/OS via root CA store	Trusted only if manually imported by the client
Validation	Identity verified by RA/CA	No third-party validation
Revocation	Supported via CRL/OCSP	No revocation infrastructure
Use case	Public-facing web, APIs, email	Internal testing, development, internal services
Cost	Free (Let’s Encrypt) to thousands of dollars	Free
Compliance	Required by PCI DSS, HIPAA, ISO 27001 for public services	Not acceptable for public-facing production
MitM risk	Low — chain validation catches impostor certs	High — no way for clients to detect impostor

The bottom line: self-signed certificates are fine for development and internal microservice communication where you control both endpoints and import the cert manually. For anything public-facing, or any system requiring regulatory compliance, a PKI-issued certificate is not optional.

Real-World Use Cases

HTTPS and web PKI: Every HTTPS connection uses PKI. Let’s Encrypt, a free automated CA, now issues over 400 million active certificates and runs on ACME (Automatic Certificate Management Environment, RFC 8555) to remove manual renewal entirely. This made HTTPS the default rather than the exception.

Code signing: Software publishers sign executables and packages with certificates issued by a code-signing CA. When Windows or macOS runs a downloaded application, it validates the signature against the trusted CA store. An invalid or missing signature triggers a security warning. Malware campaigns frequently steal or purchase code-signing certificates because a valid signature dramatically increases the chance a user will run the payload. You can explore how mTLS Explained: Mutual TLS for Zero-Trust APIs extends this trust model to machine-to-machine authentication.

Enterprise internal PKI: Organizations run their own private CA infrastructure — using tools like Microsoft AD CS, HashiCorp Vault PKI, or EJBCA — to issue certificates for internal systems including VPN gateways, internal web applications, and device identity. These private roots are distributed to corporate devices via MDM, so internal services can use TLS without purchasing public CA certificates. The TLS Handshake Explained article covers exactly how these certificates are used during connection setup.

Common Mistakes to Avoid

Storing private keys insecurely: The private key is the crown jewel. If it is compromised, an attacker can impersonate your server or decrypt past sessions if forward secrecy was not used. Private keys should be stored in a Hardware Security Module or at minimum in an encrypted key store with strict access controls. See Hardware Security Modules: HSM vs KMS Explained for your options.

Ignoring certificate expiry: An expired certificate causes immediate downtime and trust errors for every user. The 2020 Microsoft Teams outage — which affected tens of millions of users — was caused by a missed certificate renewal. Automate renewal with ACME clients (Certbot, AWS ACM, Caddy) so expiry is never a surprise.

Using long-lived root CA private keys without offline storage: Root CA keys should be generated and stored on offline HSMs that are air-gapped from the network. If a root CA key is exposed, every certificate that chains to it must be revoked and re-issued — potentially affecting millions of certificates.

Skipping revocation infrastructure: Issuing certificates without CRL distribution points or OCSP responders means you have no way to invalidate compromised certificates quickly. Modern best practice is OCSP stapling, where the server caches a fresh OCSP response and presents it alongside the certificate during the TLS handshake, eliminating the separate client-to-OCSP-responder round-trip. For a full breakdown of CRL, OCSP, and OCSP stapling — including how to enable stapling in Nginx and Apache — see How Certificate Revocation Works (CRL vs OCSP).

Getting Started

To implement PKI correctly in your systems, follow these steps:

First, choose your CA type based on your use case. For public-facing web services, use an automated public CA like Let’s Encrypt with the Certbot ACME client — it is free, renews every 90 days automatically, and is trusted by every major browser. For internal enterprise services, evaluate running a private CA hierarchy using HashiCorp Vault’s PKI secrets engine or Microsoft AD CS.

Second, design a two-tier CA hierarchy for any internal PKI. Keep the root CA offline and use it only to sign intermediate CA certificates. Issue all end-entity certificates from the intermediate CA. If an intermediate CA is compromised, you can revoke only its certificates without invalidating your entire root.

Third, automate certificate lifecycle management. Certificate expiry is the most common PKI failure in practice. Use tooling — Datadog certificate monitoring, Prometheus exporters, or AWS Certificate Manager renewal alerts — and treat certificate management as infrastructure-as-code alongside your other configuration management.

Fourth, verify your chain before deployment. Use SSL Labs’ Server Test or OpenSSL’s s_client to confirm your full chain is served correctly and no intermediate is missing. A missing intermediate causes TLS failures on mobile devices that do not cache intermediate CAs.

For a deeper understanding of how the web validates certificates at scale, read Certificate Transparency: How CT Logs Stop Bad TLS Certs. For the certificate format itself, see Understanding Digital Certificates: A Beginner’s Guide. The TLS 1.3 vs TLS 1.2 article shows how PKI underpins the security of modern connections.