How PKI Works

Public Key Infrastructure (PKI) is the system of processes, policies, and technologies that manages digital certificates and public/private key pairs. It is the trust framework that makes TLS, code signing, email encryption, and document signing work at scale.

Certificate Authority Hierarchy

PKI operates as a hierarchy of trust:

Root CA (offline, in trust stores)
├── Intermediate CA "A" (online, issues server certs)
│   ├── leaf: api.example.com
│   └── leaf: www.example.com
└── Intermediate CA "B" (online, issues client certs)
    ├── leaf: service-alpha
    └── leaf: service-beta

Root CAs are kept offline in hardware security modules (HSMs) and are only brought online to sign intermediates or for key ceremonies. Intermediate CAs handle day-to-day issuance. This layered approach limits the impact of a compromise — revoking an intermediate does not require replacing the root.

Certificate Lifecycle

Every certificate follows a predictable lifecycle:

1. Key Generation — the applicant generates a key pair (RSA 2048+, ECDSA P-256/P-384, or Ed25519).
2. Certificate Signing Request (CSR) — the public key and subject information are packaged into a PKCS#10 CSR and sent to the CA.
3. Validation— the CA verifies the applicant controls the domain (DV), the organization exists (OV), or meets extended criteria (EV).
4. Issuance— the CA signs the certificate and returns it.
5. Deployment— the certificate and private key are installed on the target server or client.
6. Renewal— before expiry, a new certificate is requested (often automated).
7. Revocation— if the key is compromised or the certificate is no longer needed, the CA revokes it.

Revocation: OCSP and CRL

Certificate Revocation Lists (CRL)

A CRL is a signed list of revoked certificate serial numbers published by the CA at a URL specified in the certificate's CRL Distribution Points extension. Clients download and cache the list. The downside: CRLs grow over time and must be downloaded in full.

Online Certificate Status Protocol (OCSP)

OCSP provides real-time, per-certificate revocation status. The client sends the certificate serial number to the OCSP responder (URL from the AIA extension) and gets a signed “good”/“revoked”/“unknown” response. OCSP stapling improves performance by letting the server fetch the response and include it in the TLS handshake, avoiding a separate client-to-OCSP round trip.

Certificate Transparency (CT)

Certificate Transparency is a system of public, append-only logs where CAs must publish every certificate they issue. This allows domain owners and researchers to monitor for misissued certificates. When a CA issues a certificate, it submits it to one or more CT logs and receives a Signed Certificate Timestamp (SCT) that is embedded in the certificate or delivered via TLS extension. Chrome requires at least two SCTs from independent logs for a certificate to be trusted.

Monitor your domains using services like crt.sh or Google's CT search to detect unauthorized certificate issuance.

Trust Store Management

Trust stores are platform-managed collections of root CA certificates. Each major platform has its own:

• Windows— Managed via Group Policy or certmgr.msc. Auto-updated via Windows Update.
• macOS— System Keychain, managed via Keychain Access or MDM profiles.
• Linux— varies by distro. Debian/Ubuntu: /etc/ssl/certs/. RHEL: /etc/pki/tls/certs/.
• .NET— uses the OS trust store by default. Docker containers based on Alpine/Debian may need explicit CA bundle installation.

Let's Encrypt and ACME

The ACME (Automatic Certificate Management Environment) protocol (RFC 8555) enables fully automated certificate issuance and renewal. Let's Encrypt is the largest ACME-based CA, issuing free domain-validated (DV) certificates with 90-day lifetimes.

The ACME workflow:

1. Client creates an account with the CA.
2. Client requests a certificate for a domain.
3. CA issues a challenge (HTTP-01, DNS-01, or TLS-ALPN-01) to prove domain control.
4. Client completes the challenge.
5. CA validates and issues the certificate.
6. Client installs and later auto-renews before expiry.

# Certbot example for nginx
sudo certbot --nginx -d example.com -d www.example.com

# Auto-renewal is configured via systemd timer or cron
sudo certbot renew --dry-run