Public Key Infrastructure (PKI)

Introduction

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. PKI solves a fundamental problem: how do you know that a public key actually belongs to the person or organization it claims to belong to?

Without PKI, public key cryptography faces the identity binding problem. If Alice wants to send an encrypted message to Bob using his public key, she needs assurance that the key truly belongs to Bob and not to an attacker performing a man-in-the-middle attack. PKI provides this assurance through digital certificates issued by trusted third parties called Certificate Authorities (CAs).

PKI is the invisible infrastructure that makes HTTPS, email encryption, VPNs, code signing, electronic signatures, and smart card authentication possible. Every time your browser shows a padlock icon, PKI is at work -- verifying the server's identity through a chain of digital signatures that traces back to a trusted root.

"PKI is the most widely deployed security infrastructure in the world. Every HTTPS connection, every signed email, every VPN tunnel relies on it -- yet most users have no idea it exists." -- Peter Gutmann, University of Auckland

Core Components

Certificate Authorities (CAs)

A Certificate Authority is a trusted organization that issues digital certificates. The CA verifies the identity of the certificate requester and then digitally signs the certificate with its own private key. This signature allows anyone who trusts the CA to trust the certificate.

CAs exist in a hierarchy:

• Root CAs: Self-signed certificates that form the foundation of trust. Their certificates are pre-installed in operating systems, browsers, and devices. Root CAs are kept offline and heavily protected -- a compromised root CA would undermine all certificates it has ever issued.
• Intermediate CAs: Certificates signed by a root CA (or another intermediate CA). These handle the day-to-day issuance of end-entity certificates. Using intermediates limits exposure of the root CA's private key.

Registration Authorities (RAs)

A Registration Authority handles the verification of certificate requests before forwarding them to the CA for signing. The RA verifies that the requester controls the domain (for DV certificates), the organization exists (for OV certificates), or that the legal entity meets extended requirements (for EV certificates). In many modern systems, the RA function is integrated into the CA's automated processes.

Certificate Stores and Trust Stores

A trust store is the collection of root CA certificates that a system trusts. Operating systems maintain their own trust stores (Windows has the Microsoft Trusted Root Certificate Program, macOS uses the Apple Root Certificate Program, and Linux distributions maintain ca-certificates packages). Browsers may use the OS trust store or their own (Mozilla maintains the NSS root certificate store independently).

The typical trust store contains 100-150 root certificates from CAs worldwide. Adding or removing a root certificate from a major trust store is a significant event -- removal effectively "untrusts" all certificates issued by that CA.

X.509 Certificates

X.509 is the ITU-T standard that defines the format of public key certificates. Virtually all PKI on the internet uses X.509v3 certificates, defined in RFC 5280. A certificate contains:

Important X.509v3 extensions include:

• Subject Alternative Name (SAN): Lists additional hostnames the certificate covers (e.g., example.com, www.example.com, api.example.com). Modern browsers require SAN rather than the deprecated CN field for hostname validation.
• Key Usage / Extended Key Usage: Restricts what the key can be used for (e.g., digital signature, key encipherment, server authentication, code signing).
• Basic Constraints: Indicates whether the certificate is a CA certificate and the maximum chain depth allowed.
• Authority Information Access (AIA): URLs for the issuer's certificate and OCSP responder.
• Certificate Transparency (CT) Precertificate SCTs: Proof that the certificate has been logged in public Certificate Transparency logs.

// Examining a certificate with OpenSSL$ openssl x509 -in cert.pem -text -nooutCertificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=R3 Validity Not Before: Jan 1 00:00:00 2024 GMT Not After : Apr 1 00:00:00 2024 GMT Subject: CN=www.example.com X509v3 extensions: X509v3 Subject Alternative Name: DNS:www.example.com, DNS:example.com X509v3 Key Usage: critical Digital Signature, Key Encipherment

Certificate Chains

Certificates form a chain of trust (also called a certification path) from the end-entity certificate (the website or service) up to a trusted root CA. Each certificate in the chain is signed by the next higher CA, creating a verifiable path.

A typical chain has three levels:

1. End-entity certificate: Identifies the server (e.g., www.example.com). Signed by the intermediate CA.
2. Intermediate CA certificate: Issued by the root CA. Signs end-entity certificates on behalf of the root. Sent by the server during the TLS handshake.
3. Root CA certificate: Self-signed. Pre-installed in the client's trust store. Never sent by the server.

The chain verification process works bottom-up: the client verifies the end-entity certificate's signature using the intermediate CA's public key, then verifies the intermediate's signature using the root CA's public key. If the root CA is in the trust store and all signatures are valid, all validity periods are current, and no certificate has been revoked, the chain is trusted.

Cross-signing allows a new CA to be trusted by older clients that do not yet have the new root in their trust store. Let's Encrypt's root (ISRG Root X1) was cross-signed by IdenTrust's DST Root CA X3, enabling trust across older devices before ISRG Root X1 was widely distributed.

Certificate Lifecycle

Certificates follow a defined lifecycle from issuance to expiration or revocation:

1. Key Generation: The subject generates a public/private key pair.
2. Certificate Signing Request (CSR): The subject creates a CSR containing the public key, subject information, and a signature proving possession of the private key.
3. Validation: The CA (or RA) verifies the subject's identity. The level of verification depends on the certificate type.
4. Issuance: The CA signs the certificate and returns it to the subject.
5. Installation and Use: The subject installs the certificate on their server.
6. Renewal: Before expiration, the subject obtains a new certificate.
7. Revocation: If the private key is compromised, the certificate is revoked before its natural expiration.

The trend in the industry is toward shorter certificate lifetimes. Let's Encrypt certificates are valid for 90 days, and Apple announced in 2024 that the maximum certificate lifetime would be reduced to 45 days by 2027. Shorter lifetimes reduce the window of exposure from a compromised key and encourage automation.

Revocation: CRL and OCSP

When a private key is compromised or a certificate must be invalidated before its expiration date, revocation mechanisms notify relying parties. Two primary mechanisms exist:

Certificate Revocation Lists (CRL): A CRL is a signed list of serial numbers of revoked certificates, published periodically by the CA. Clients download the entire CRL and check whether the certificate in question appears on it. CRLs have significant drawbacks: they can grow very large (hundreds of megabytes for major CAs), they are updated on a schedule (so there is a delay between revocation and publication), and clients must download the entire list even to check a single certificate.

Online Certificate Status Protocol (OCSP): OCSP allows clients to query the CA's OCSP responder in real time to check the revocation status of a specific certificate. This is more efficient than CRLs but introduces a privacy concern (the CA learns which sites you visit) and a latency cost (an extra network round-trip during the TLS handshake).

OCSP Stapling: To address the privacy and performance issues of OCSP, TLS servers can periodically fetch their own OCSP response from the CA and "staple" it to the TLS handshake. The client receives a signed, time-limited proof of non-revocation directly from the server, without contacting the CA. OCSP stapling is enabled in most modern web servers (Nginx, Apache, Caddy).

"Revocation is the Achilles' heel of PKI. We have certificates that expire, but no reliable way to revoke them before expiration. Every proposed solution has significant trade-offs." -- Adam Langley, Google Chrome security team

CRLite and Short-Lived Certificates: Mozilla developed CRLite, a compressed representation of all revoked certificates that can be pushed to browsers efficiently. An alternative approach, advocated by some in the industry, is to make certificate lifetimes so short (hours or days) that revocation becomes unnecessary -- if a key is compromised, the certificate expires before meaningful damage occurs.

Trust Models

Different systems use different models for establishing trust in public keys:

Hierarchical PKI (CA model): The dominant model on the web. Trust flows from root CAs down through intermediate CAs to end-entity certificates. This model is centralized -- you trust whoever the browser and OS vendors have decided to trust. Over 100 root CAs are trusted by default, and any one of them can issue a certificate for any domain.

Web of Trust (WoT): Used by PGP/GPG. Instead of centralized CAs, individuals sign each other's keys, creating a decentralized network of trust. If Alice trusts Bob, and Bob has signed Carol's key, Alice can transitively trust Carol. The web of trust is more resilient to single points of failure but is difficult to bootstrap and maintain -- it never achieved widespread adoption beyond technically sophisticated users.

Trust on First Use (TOFU): Used by SSH. The first time you connect to a server, you are prompted to accept its public key fingerprint. That fingerprint is then cached locally. If the key changes on a subsequent connection, you receive a warning. TOFU is simple but provides no protection against a man-in-the-middle attack on the first connection.

Certificate Transparency (CT): CT is an augmentation to the CA model, not a replacement. All publicly trusted CAs must submit certificates to public, append-only CT logs before issuance. Anyone can monitor these logs to detect misissued or unauthorized certificates for their domain. CT was made mandatory for all publicly trusted certificates by Google Chrome in 2018.

Let's Encrypt and ACME

Let's Encrypt, launched in 2016 by the Internet Security Research Group (ISRG), transformed the PKI landscape by providing free, automated DV certificates. Before Let's Encrypt, obtaining an SSL/TLS certificate required manual processes, payment, and technical knowledge. As of 2024, Let's Encrypt has issued billions of certificates and secures over 300 million websites.

Let's Encrypt uses the ACME (Automatic Certificate Management Environment) protocol, standardized as RFC 8555. ACME automates the entire certificate lifecycle:

1. Account registration: The client generates a key pair and registers with the CA
2. Domain validation: The client proves control of the domain via HTTP-01 challenge (place a file at a specific URL) or DNS-01 challenge (create a specific DNS TXT record)
3. Certificate issuance: Upon successful validation, the CA signs and returns the certificate
4. Automated renewal: ACME clients (Certbot, acme.sh, Caddy) automatically renew certificates before expiration

// Obtaining a certificate with Certbot (ACME client)$ certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com// Automatic renewal (typically via cron or systemd timer)$ certbot renew --quiet// Certificate files/etc/letsencrypt/live/example.com/fullchain.pem # Certificate + intermediate/etc/letsencrypt/live/example.com/privkey.pem # Private key

The success of Let's Encrypt and ACME has made HTTPS the default for the web. In 2015, approximately 40% of web page loads used HTTPS. By 2024, that figure exceeded 95%.

Attacks and Failures

PKI's history includes several high-profile failures that revealed systemic weaknesses:

DigiNotar (2011): The Dutch CA DigiNotar was compromised by attackers who issued fraudulent certificates for google.com, yahoo.com, and other domains. These were used for man-in-the-middle attacks against Iranian internet users. DigiNotar was completely removed from all trust stores, and the company went bankrupt. This incident demonstrated that a single compromised CA can undermine the entire system.

Symantec (2017): Google discovered that Symantec (the world's largest CA at the time) had misissued over 30,000 certificates, including test certificates for domains Symantec did not control. Google gradually distrusted all Symantec-issued certificates in Chrome, forcing Symantec to sell its CA business to DigiCert.

Superfish/eDellRoot (2015): Lenovo shipped laptops with Superfish adware that installed its own root CA certificate, allowing it to intercept HTTPS traffic. Dell shipped laptops with a similar root certificate (eDellRoot) and its private key, meaning anyone could extract the key and impersonate any website to Dell users.

Government CAs: Several government-controlled CAs have been found issuing certificates for domains they do not own, raising concerns about state-sponsored surveillance. In 2015, CNNIC (China Internet Network Information Center) was distrusted after issuing unauthorized certificates through an intermediate CA. Certificate Transparency was developed in part to detect such abuses.

For related topics, see Digital Signatures (the cryptographic mechanism underlying certificate verification) and RSA (the most common algorithm used in certificate signing).

References

• Cooper, D., et al. (2008). RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
• Barnes, R., et al. (2019). RFC 8555: Automatic Certificate Management Environment (ACME).
• Laurie, B., Langley, A., & Kasper, E. (2013). RFC 6962: Certificate Transparency.
• Santesson, S., et al. (2013). RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.
• Gutmann, P. (2002). PKI: It's Not Dead, Just Resting. IEEE Computer, 35(8).
• Aas, J., et al. (2019). "Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web." ACM CCS 2019.
• Prins, J. R., & Cybercrime, B. U. (2011). "DigiNotar Certificate Authority Breach: Operation Black Tulip." Fox-IT Report.
• NIST (2020). SP 800-57 Part 1 Rev. 5: Recommendation for Key Management.
• CA/Browser Forum (2024). Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.
• Sleevi, R. (2020). "Moving Forward, Together." Google Security Blog (Symantec distrust timeline).