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.
A functioning PKI environment relies on several interconnected components. Each plays a distinct role in the lifecycle of trust.
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.
PKI environments are organized into hierarchical tiers. The structure you choose has direct implications for security, flexibility, and operational complexity. Here are the three standard models:
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.
Regardless of the tier model, the fundamental principle is the same: the root CA's private key must be protected at all costs. If trust in the root is lost, every certificate in the hierarchy becomes untrustworthy. This is why root CAs are almost always kept offline, and their keys are stored in Hardware Security Modules (HSMs) inside physically secured facilities.
Certificate enrollment is the process by which an end entity obtains a certificate from a CA. While the specific protocol varies (ACME, SCEP, EST, CMP, or a web-based portal), the logical flow is consistent:
The end entity generates an asymmetric key pair, a public key and a private key. The private key never leaves the entity's control. The algorithm and key size (e.g., RSA 2048, ECDSA P-256) depend on organizational policy.
The entity packages the public key together with identifying information (subject name, organization, domain names) into a CSR. The CSR is signed with the entity's private key, proving possession of the corresponding key pair.
The Registration Authority receives the CSR and verifies the requester's identity. For a public TLS certificate, this might be an automated domain control check. For an internal employee certificate, it might involve checking against an HR directory or requiring manager approval.
After approval, the CA constructs the X.509 certificate (embedding the public key, subject information, validity period, extensions, and serial number) and then signs it with the CA's own private key. This signature is the proof of trust.
The signed certificate is returned to the end entity and installed on the target system (a web server, a laptop, an IoT device). From this point, the certificate is used for TLS handshakes, email signing, code signing, or mutual authentication, depending on its type and key usage extensions.
A trust anchor is a root CA certificate that a system accepts as inherently trustworthy, without needing anyone else to vouch for it. Trust anchors are the starting point of all certificate validation. If your system trusts a root CA, it will trust every certificate issued under that root (provided the chain of trust is valid).
Trust anchors are stored in trust stores, curated collections of root CA certificates maintained by operating systems, browsers, and applications. Apple, Microsoft, Mozilla, and Google each maintain their own trust store programs with strict requirements for inclusion. A root CA must undergo rigorous audits (WebTrust, ETSI) and comply with the CA/Browser Forum Baseline Requirements to be included.
For private PKI (the kind most enterprises operate), trust anchors are distributed internally. Your organization's root CA certificate is pushed to employee laptops, servers, and network appliances via group policy, configuration management tools, or MDM profiles. Any certificate issued by your private CA will be trusted only by systems that have your root in their trust store.
This distinction between public and private trust is fundamental. Public trust means your certificate is recognized by billions of devices worldwide. Private trust means it is recognized only within your controlled environment. Both are valid; they serve different purposes.
Running a PKI is not just about software. It involves physical security, cryptographic procedures, and continuous oversight. Here are the operational foundations that keep a PKI trustworthy:
A key ceremony is a formal, audited procedure for generating or using a CA's private key. Root CA key ceremonies are particularly rigorous: they take place in physically secured rooms, with multiple witnesses, video recording, and strict scripts. Every step is documented for audit purposes. The goal is to ensure that the most sensitive cryptographic material is handled with absolute accountability.
An HSM is a tamper-resistant hardware device that generates, stores, and manages cryptographic keys. In PKI, HSMs protect the CA's private keys; the keys never leave the HSM in plaintext. If someone physically tampers with the device, it destroys the keys. HSMs are the industry standard for any production CA, and their use is typically required by audit frameworks like WebTrust and ETSI.
Every action in a well-run PKI is logged: certificate issuance, revocation, key generation, policy changes, administrator access. These logs are essential for incident response, regulatory compliance, and audit readiness. Frameworks like eIDAS, NIS2, and DORA increasingly require organizations to demonstrate control over their cryptographic infrastructure.
A CA outage means no new certificates can be issued and no revocations can be processed. Production PKI environments require tested disaster recovery plans, including HSM key backup (often using key splitting with M-of-N controls), redundant infrastructure, and documented recovery procedures.
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.
