Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.
A PKI encompasses more than certificate issuance. Certificate revocation is the mechanism for marking a certificate invalid before its expiry — necessary when a private key is compromised, a subject’s identity changes, or a certificate is mis-issued. The two standard mechanisms are CRL (Certificate Revocation List), a periodically published signed list of revoked serial numbers fetched from a distribution point in the certificate, and OCSP (Online Certificate Status Protocol), a real-time query to a responder operated by the CA. Both have well-known operational weaknesses (CRL staleness, OCSP responder availability and privacy), which is why short certificate lifetimes — hours to days rather than years — have become the preferred mitigation in modern deployments: a certificate that expires tomorrow cannot be usefully revoked. Certificate lifecycle management covers the operational processes around issuance (CSR generation and validation), renewal (before expiry, automated where possible via ACME), and rotation (replacing a certificate and its associated key). Tools like Vault’s PKI engine, cert-manager on Kubernetes, and Let’s Encrypt automate these processes, eliminating the manual CSR/approval cycles that have historically caused outages from missed renewals.
PKI appears throughout the infrastructure stack in this glossary at every point where cryptographic identity is needed. TLS uses PKI to authenticate servers (and in mTLS, clients) via X.509 certificates. Secure Boot relies on a PKI rooted in the UEFI firmware trust store to validate bootloader and kernel signatures. Code signing uses a PKI to bind a public key to a software publisher so that a package manager or OS can verify a binary’s provenance. SPIFFE/SPIRE implements a specialised PKI scoped to workload identities within a trust domain, issuing short-lived X.509-SVIDs from a SPIRE-operated CA. OCI image signing via cosign, and attestation distribution via the referrers API, rely on a PKI (Sigstore’s certificate transparency-backed one, or a private CA) to bind signatures to developer identities. The transition to PQC has direct implications for PKI: every CA key, every leaf certificate, and every signature in the chain that was generated under RSA or ECDSA is potentially HNDL-exposed, and migration requires standing up a parallel PQC CA hierarchy — ML-DSA root and intermediate CAs — and re-issuing the entire certificate population under quantum-safe signatures.