What Is Public Key Infrastructure (PKI)?

PKI: The Foundation of Digital Trust

Public Key Infrastructure (PKI) is the set of technologies, policies, and procedures that manage digital certificates and public-private key pairs. Every time you visit a website over HTTPS, sign an email, or verify a software update, PKI is working behind the scenes to ensure the connection is encrypted and the other party is who they claim to be.

Without PKI, there would be no way to distinguish a legitimate bank website from a phishing site, no way to verify that a software update actually came from its vendor, and no way to send encrypted email to someone you have never met in person. PKI solves the fundamental problem of establishing trust between parties that have no prior relationship.

At its core, PKI relies on asymmetric cryptography: every participant has a key pair consisting of a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the corresponding private key, and a digital signature created with the private key can be verified by anyone with the public key.

How PKI Works: Certificates, Keys, and Trust

The key insight of PKI is that a certificate authority (CA) — a trusted third party — vouches for the binding between a public key and an identity. Here is how the process works in practice:

1. Key pair generation. An entity (a web server, a person, a device) generates a public-private key pair. The private key is stored securely; the public key is embedded in a certificate signing request (CSR).
2. Certificate signing request. The entity sends the CSR to a certificate authority. The CSR contains the public key, the subject identity (such as a domain name), and a digital signature proving possession of the private key.
3. Validation. The CA verifies the requester's identity. For a domain-validated (DV) TLS certificate, this might be as simple as proving control of the domain. For an extended-validation (EV) certificate, it involves legal and organizational checks.
4. Certificate issuance. The CA signs the certificate with its own private key, creating a cryptographic binding between the subject's public key and their identity. The signed certificate is returned to the requester.
5. Chain of trust verification. When a client (browser, email client, operating system) encounters the certificate, it traces the chain of signatures back to a root CA that it already trusts. If the chain is valid and the certificate has not been revoked, the identity is accepted.

This chain of trust is what makes PKI scalable. Browsers and operating systems ship with a pre-installed set of trusted root CA certificates. Any certificate that chains back to one of these roots is automatically trusted, without the end user needing to make a manual decision.

PKI Components: Root CAs, Intermediates, and More

A well-architected PKI deployment consists of several layers and components:

• Root Certificate Authority. The root CA is the ultimate trust anchor. Its self-signed certificate is distributed to clients (browsers, operating systems). Because compromise of the root key would undermine the entire PKI, root CAs are typically kept offline and used only to sign intermediate CA certificates.
• Intermediate Certificate Authority. Intermediate CAs are signed by the root CA and handle day-to-day certificate issuance. This separation limits exposure: if an intermediate CA is compromised, it can be revoked without replacing the root. Most production PKIs use at least one level of intermediate CAs.
• End-entity certificates. These are the certificates issued to servers, users, and devices. A TLS certificate for a website, an S/MIME certificate for email, and a code signing certificate are all end-entity certificates.
• Certificate Revocation Lists (CRLs). CRLs are signed lists of certificates that have been revoked before their expiration date. CAs publish CRLs periodically so that relying parties can check whether a certificate is still valid.
• Online Certificate Status Protocol (OCSP). OCSP provides real-time certificate status checking. Instead of downloading an entire CRL, a client can query an OCSP responder for the status of a specific certificate. OCSP stapling further improves performance by letting the server include a signed OCSP response in the TLS handshake.
• Registration Authority (RA). An RA handles identity validation on behalf of the CA. In large deployments, the RA performs the verification work while the CA focuses on signing.

X.509 Certificates Explained

The X.509 standard defines the format for PKI certificates used across TLS, S/MIME, code signing, and most other PKI applications. An X.509 certificate contains:

• Version — Almost always v3, which supports extensions.
• Serial number — A unique identifier assigned by the issuing CA.
• Signature algorithm — The algorithm used to sign the certificate (e.g., SHA-256 with RSA, or ECDSA with P-256).
• Issuer — The distinguished name (DN) of the CA that signed the certificate.
• Validity period — Not-before and not-after dates defining when the certificate is valid.
• Subject — The distinguished name of the entity the certificate identifies.
• Subject public key — The public key and its algorithm.
• Extensions — Additional fields including Subject Alternative Names (SANs), Key Usage, Extended Key Usage, Basic Constraints, Authority Information Access (AIA), and CRL Distribution Points.

Subject Alternative Names (SANs) are particularly important for TLS certificates. SANs allow a single certificate to cover multiple domain names and IP addresses. Modern browsers require the domain to appear in the SAN field, not just the Subject CN.

PKI Use Cases

TLS/HTTPS: Securing Web Traffic

The most visible use of PKI is TLS (Transport Layer Security), which powers HTTPS. When you connect to a website, the server presents its X.509 certificate. Your browser verifies the chain of trust, confirms the certificate covers the requested domain, and establishes an encrypted session. Over 95% of web traffic now uses HTTPS, making PKI certificates essential infrastructure.

Code Signing

Software publishers use code signing certificates to prove that executables, drivers, and packages have not been tampered with since they were built. Operating systems check code signatures before running software, warning users or blocking unsigned code entirely. In enterprise environments, code signing keys often require multi-party approval to prevent a single compromised developer from distributing malicious updates.

Email Security with S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) uses PKI certificates to sign and encrypt email. A signed email proves the sender's identity and that the message was not altered in transit. An encrypted email can only be read by the intended recipient. Organizations that handle sensitive communications rely on S/MIME as part of their security policy.

Document and Contract Signing

Digital signatures on PDFs, contracts, and legal documents provide non-repudiation: the signer cannot later deny having signed. Regulatory frameworks like eIDAS in the European Union define legally binding electronic signatures that depend on PKI certificates issued by qualified trust service providers.

Mutual TLS (mTLS)

Standard TLS authenticates only the server. Mutual TLS adds client certificate authentication, so both sides verify each other's identity. mTLS is widely used in microservices architectures (Istio, Linkerd), API gateways, and zero trust networks. It eliminates the need for API keys or tokens for machine-to-machine authentication.

IoT Device Identity

IoT devices use PKI certificates provisioned at manufacturing time to establish unique, hardware-bound identities. These certificates enable secure device onboarding, encrypted communication, and firmware update verification. Combined with TPM chips, device certificates can be tied to tamper-resistant hardware.

PKI and HSMs: Why Hardware Key Protection Matters

The security of any PKI deployment is only as strong as the protection of its CA private keys. If an attacker obtains a CA's private key, they can issue fraudulent certificates for any domain or identity, completely undermining trust.

This is why every major certificate authority — and every organization running a private CA — stores CA signing keys in a Hardware Security Module (HSM). An HSM is a dedicated cryptographic device that generates, stores, and uses private keys in tamper-resistant hardware. The private key never leaves the HSM in plaintext, so even full server compromise cannot extract it.

Traditional HSMs from vendors like Thales (Luna) and Entrust (nShield) cost tens of thousands of dollars and require specialized infrastructure. Cloud HSM services (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) reduce the operational burden but introduce per-key and per-operation fees, and your keys reside on someone else's hardware.

How TPM HSM Supports PKI

TPM HSM provides a practical alternative for organizations that need hardware-backed PKI without the cost and complexity of traditional HSMs. It turns the TPM 2.0 chip already built into your servers and workstations into a fully functional HSM for PKI operations.

CSR Generation from Hardware-Protected Keys

TPM HSM generates PKCS#10 Certificate Signing Requests directly from keys stored in the TPM. The private key never leaves the chip — the CSR is built around the TPM-resident public key with full support for subject distinguished names and Subject Alternative Names. You submit the CSR to any CA (public or private) and receive a certificate that is cryptographically bound to a hardware-protected key.

Certificate Storage and Chain Management

TPM HSM stores X.509 certificates and associates them with their corresponding TPM-resident keys. You can import full certificate chains (root, intermediate, and end-entity) and manage them alongside your HSM keys. This gives you a unified view of your PKI assets with hardware-backed key protection.

Hardware-Backed CA Signing Keys

When running a private certificate authority, TPM HSM protects your CA signing keys inside the TPM. Combined with hardware-enforced signing policies, the TPM itself refuses unauthorized signing operations. Even if the CA server is compromised, the attacker cannot extract the CA key or forge certificates without satisfying the TPM's policy requirements.

Multi-Party Certificate Issuance

For high-security PKI deployments, TPM HSM supports M-of-N threshold signing for CA keys. Certificate issuance requires approval from multiple authorized parties, each authenticating with their own YubiKey or file key. This prevents a single compromised administrator from issuing rogue certificates — a critical control for root and intermediate CA operations.

Remote Attestation for PKI Trust

TPM HSM can attest that your CA keys are genuinely stored in real TPM hardware, not in a software emulator. This provides cryptographic proof to auditors and relying parties that your PKI meets hardware key protection requirements, supporting compliance with CA/Browser Forum standards and regulatory frameworks.