Public Key Infrastructure is the trust framework behind every HTTPS connection, every digitally signed email, and every authenticated device on your network. This guide explains what PKI is, how it works, where organizations get it wrong, and how to choose the right platform for your needs.
Public Key Infrastructure (PKI) is the set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
Think of PKI as the passport system of the digital world. Just as a government issues passports through trusted agencies, verifies identity before issuing them, and maintains lists of revoked documents, a PKI issues digital certificates through trusted Certificate Authorities (CAs), verifies identities before issuance, and publishes revocation information so relying parties can check whether a certificate is still valid.
Without PKI, there would be no way to verify that the website you're visiting is genuine, that the email you received was actually sent by your colleague, or that the software update you're installing hasn't been tampered with. PKI is the invisible foundation that makes digital trust possible at scale.
PKI is not a single product or protocol. It is an architectural framework that combines asymmetric cryptography, certificate standards (X.509), validation protocols, and operational procedures into a coherent trust model. Every organization that uses HTTPS, signs code, encrypts email, or authenticates devices is already relying on PKI, whether they manage it deliberately or not.
The entity that needs a certificate (a server, user, or device) generates an asymmetric key pair. The private key stays secret; the public key will be embedded in the certificate. Key generation should use cryptographically secure random number generators, and the private key should ideally be stored in hardware (HSM or TPM).
The requester creates a CSR containing the public key and identity information (domain name, organization, etc.). The CSR is signed with the requester's private key, proving possession without revealing it. The CSR is then submitted to the CA or RA.
The Certificate Authority verifies the requester's identity. For public TLS certificates, this means domain validation (DV), organization validation (OV), or extended validation (EV). For private PKI, validation follows the organization's own policies. Once approved, the CA signs the certificate with its private key.
The signed certificate is returned to the requester and installed on the target system (web server, mail server, device, etc.) along with any intermediate CA certificates needed to form a complete chain of trust. This step can be automated using protocols like ACME, SCEP, or EST.
When a client connects to a certificate-bearing server, it validates the certificate: checks the CA's signature, verifies the chain of trust back to a root CA in its trust store, confirms the certificate hasn't expired, and checks revocation status via CRL or OCSP. If all checks pass, an encrypted session is established.
Before expiry, certificates must be renewed. With TLS lifespans shrinking to 47 days by 2029, this means each certificate will need ~8 renewals per year. If a key is compromised or an entity's status changes, the certificate must be revoked immediately and the revocation published via CRL/OCSP.
The trusted entity that issues and signs digital certificates. A CA verifies the identity of the requester before binding their public key to an identity. Organizations may use public CAs for external-facing services, and private CAs for internal use. The CA's own private key, often protected by an HSM, is the most critical asset in the entire PKI.
Acts as a gatekeeper between certificate requesters and the CA. The RA verifies identity claims, validates Certificate Signing Requests (CSRs), and approves or rejects requests before they reach the CA for signing. In smaller deployments, the RA function is often built into the CA itself.
The actual credentials issued by the CA. Each certificate binds a public key to an identity (a domain, a user, a device) following the X.509 standard. Certificates include metadata like the issuer, validity period, key usage constraints, and Subject Alternative Names (SANs).
Mechanisms for invalidating certificates before they expire. Certificate Revocation Lists (CRLs) are periodically published lists of revoked serial numbers. OCSP provides real-time, per-certificate status checks. Both are essential for maintaining trust when keys are compromised or affiliations change.
The collection of root CA certificates that a device, browser, or operating system trusts by default. When a client receives a certificate, it builds a chain of trust from the certificate up to a root in its trust store. If the chain is valid and the root is trusted, the certificate is accepted.
The CP (Certificate Policy) and CPS (Certification Practice Statement) are governance documents that define the rules of the PKI: who can request certificates, what validation is required, how keys must be protected, and what happens during revocation. These documents are critical for compliance and auditing.
Storing CA signing keys in software is a critical vulnerability. If the CA key is compromised, every certificate it has ever issued becomes suspect. Root and issuing CA keys should always be protected by hardware security modules (HSMs) with FIPS 140-3 Level 3 certification.
Using a root CA that directly issues end-entity certificates is risky. If that CA is compromised or needs to be replaced, every certificate must be reissued. Best practice is a two-tier (or three-tier) hierarchy: an offline root CA and one or more online issuing CAs.
If you don't know what certificates exist in your environment, you can't manage them. Shadow certificates issued by developers, cloud teams, or acquired through mergers create blind spots. Certificate discovery must be continuous, not a one-time exercise.
Tracking certificates in spreadsheets or ticketing systems is a ticking time bomb. Certificate-related outages cost companies millions and damage customer trust. With certificates moving to 47-day lifespans, automation is no longer optional.
Quantum computers will eventually break RSA and ECC. Organizations should start building crypto-agile PKI infrastructure now: inventorying cryptographic assets, testing post-quantum algorithms, and ensuring their PKI platform can support algorithm migration without re-architecting.
Issue certificates from your own CA — Evertrust PKI is a full-featured Certificate Authority that supports ACME, SCEP, EST, CMP, and REST API enrollment. Deploy on-premises or in the cloud with native HSM integration for key sovereignty.
Manage every certificate in one place — Evertrust CLM discovers certificates across your entire infrastructure (network, cloud, endpoints), regardless of which CA issued them. Get a single pane of glass for your hybrid PKI.
Automate the entire lifecycle — From enrollment to renewal to revocation, automate certificate operations at scale. Ready for the 47-day TLS certificate era with built-in ACME support.
Replace ADCS without disruption — Migrate from Microsoft ADCS to a modern, multi-protocol PKI platform with side-by-side deployment. Keep your existing AD integration while gaining ACME, cloud support, and full lifecycle visibility.
