Public Key Infrastructure is more than just certificates. It is an entire ecosystem of hardware, software, policies, and procedures that work together to create, distribute, and verify digital identities at scale.
When people hear "PKI," they often think of certificates alone. But a digital certificate is just the most visible output of a much larger system. Public Key Infrastructure (PKI) is the complete set of roles, policies, hardware, software, and procedures that make it possible to create, manage, distribute, use, store, and revoke digital certificates.
Think of it this way: if a certificate is a driver's license, then PKI is the entire system behind it: the government agency that issues licenses, the database that stores records, the rules about who qualifies, the process for revoking a license after a violation, and the equipment used to verify the license at a traffic stop. No single piece works in isolation.
Understanding how PKI works is essential for anyone responsible for securing communications, managing machine identities, or architecting trust within an organization. This chapter walks through every major component, from Certificate Authorities and Registration Authorities to trust hierarchies, enrollment protocols, and the operational practices that keep the whole system trustworthy.
The simplest architecture: one CA that is both the root of trust and the certificate issuer. It is easy to set up, but risky: if the root CA's private key is compromised, the entire PKI collapses. This model is only appropriate for small, low-risk environments like lab networks or development setups.
The most common model in enterprise environments. The root CA is kept offline (air-gapped and stored in a safe), and one or more subordinate issuing CAs handle day-to-day certificate issuance. If an issuing CA is compromised, you revoke its certificate and stand up a new one. The root remains intact. This is the architecture most organizations should start with.
Used by large organizations, governments, and regulated industries. A policy CA sits between the root and the issuing CAs, enforcing specific rules for different parts of the organization. For example, a bank might have one policy CA for its internal IT and another for customer-facing services, each with different validation requirements. This adds operational complexity but provides fine-grained control and strong isolation.
The Certificate Authority is the trusted entity that issues and signs certificates. It vouches for the binding between a public key and an identity. CAs can be public (trusted by browsers globally) or private (trusted only within an organization).
The RA acts as a gatekeeper. It receives certificate requests, verifies the identity of the requester, and forwards approved requests to the CA for signing. In many deployments, the RA function is integrated into the CA, but large organizations often separate them for security and scalability.
A directory or database where issued certificates and their metadata are stored and made available. This is often an LDAP directory or an internal database that allows clients and administrators to look up certificates when needed.
When a certificate must be invalidated before it expires, the CA publishes this information through Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). Clients check these to confirm a certificate is still valid. Learn more in the certificate revocation chapter.
These are the users, servers, devices, or applications that hold certificates. An end entity generates a key pair, requests a certificate, and uses it to authenticate, encrypt, or sign data.
Every serious PKI is governed by a Certificate Policy (CP) and a Certification Practice Statement (CPS). These documents define the rules: who can get a certificate, how identity is verified, how keys are stored, and what happens during a compromise.
Run your own PKI — Evertrust PKI provides a complete, production-ready Certificate Authority platform. Deploy root and subordinate CAs with built-in HSM integration, policy enforcement, and enrollment protocols (ACME, SCEP, EST, CMP), without building the plumbing from scratch.
Full lifecycle visibility — Evertrust CLM gives you a single pane of glass across every CA, public and private, so you always know which certificates exist, where they are deployed, and when they expire.
Audit-ready from day one — Every certificate operation is logged and traceable. Built-in reporting helps you meet compliance requirements for eIDAS, NIS2, DORA, and internal audit frameworks without manual evidence gathering.
Flexible hierarchy support — Whether you need a simple two-tier PKI or a complex multi-tier architecture with policy CAs and cross-certification, Evertrust PKI supports the full range of deployment models.
