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.
A functioning PKI consists of several interlocking components. Understanding each one is essential to designing, operating, or evaluating a PKI deployment.
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.
One of the most important architectural decisions is whether to use a public PKI, a private PKI, or a hybrid approach. The answer depends on who needs to trust your certificates and what level of control you require.
Public CAs issue certificates that are trusted by all major browsers and operating systems out of the box. Their root certificates are pre-installed in trust stores worldwide.
An organization operates its own CA hierarchy, issuing certificates for internal use. Private PKI gives you full control over certificate policies, validity periods, key algorithms, and issuance workflows. Traditionally, many organizations used Microsoft ADCS for this purpose, though modern alternatives offer broader protocol support and cloud-native deployment.
Most enterprises use both: public certificates for anything browser-facing and private certificates for everything internal. The challenge is managing both through a single pane of glass, with consistent policies and automated lifecycle management. This is where a dedicated CLM platform becomes essential.
Here is the end-to-end lifecycle of a certificate within a PKI, from key generation to eventual expiry or revocation. For a deeper dive into each stage, see the How PKI Works guide.
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.
PKI underpins far more than just HTTPS. Here are the most common use cases where organizations depend on certificate-based trust.
Every HTTPS connection relies on a TLS certificate issued by a trusted CA. This is by far the largest use case for PKI, with billions of certificates in active use across the internet.
S/MIME certificates enable end-to-end email encryption and digital signatures. Essential in regulated industries (finance, healthcare, government) where confidentiality and non-repudiation are legally required.
Code signing certificates prove that software, drivers, and scripts haven't been tampered with since the publisher signed them. Operating systems use these signatures to warn or block unsigned code.
Certificates authenticate laptops, phones, and IoT devices to networks via mutual TLS (mTLS), 802.1X (EAP-TLS), and VPN gateways. This eliminates password-based authentication and is foundational to zero-trust architectures.
Digital signatures on PDFs, contracts, and invoices provide legally binding proof of origin and integrity. Regulated under eIDAS in Europe, these certificates enable paperless workflows that meet compliance requirements.
In Kubernetes and cloud-native environments, service meshes like Istio and Linkerd use certificates to authenticate service-to-service communication via mTLS. Every pod gets its own short-lived certificate, creating thousands of certificates that must be managed automatically.
Most PKI problems don't come from the technology itself but from how it's deployed and operated. These are the mistakes we see most often in enterprise PKI environments.
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.
Organizations that need private PKI face a fundamental choice: build it themselves (using tools like Microsoft ADCS or open-source alternatives) or adopt a managed PKI platform. Here is how the options compare. For a more detailed analysis, see our Choosing a CLM Platform guide.
The most widely deployed enterprise PKI, deeply integrated with Active Directory. Handles Windows autoenrollment well but lacks native support for ACME, EST, or CMP protocols. Limited to Windows environments with no cloud-native deployment option. No built-in certificate discovery or CLM capabilities.
Flexible and protocol-rich but require significant in-house expertise to deploy, harden, and operate. No commercial support guarantee (unless using the enterprise edition). Scaling, HA, and compliance auditing are the operator's responsibility.
Purpose-built platforms that combine PKI issuance with certificate lifecycle management. Support all major enrollment protocols (ACME, SCEP, EST, CMP), deploy on-premises or in the cloud, integrate with existing infrastructure, and provide built-in compliance reporting. The goal is operational simplicity without sacrificing control.
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.
