Module 3 · PKI Architecture

Last updated: April 29, 2026

Public Key Infrastructure (PKI) is the system that issues, manages, and revokes the certificates that authenticate identities (servers, clients, code, documents). Understanding PKI is necessary for anything beyond “Let’s Encrypt this server.” This module covers Certificate Authorities, the cert lifecycle, ACME automation, internal PKI for service mesh, and the architectural decisions that matter.

The PKI components

• Certificate Authority (CA) — entity that issues certificates. Trusted by relying parties
• Registration Authority (RA) — verifies identity before CA issues; sometimes the same as CA
• Subject — entity the certificate identifies (server, person, device)
• Relying Party — the consumer that validates and trusts the certificate (browser, application)
• Repository / Directory — where issued certs and revocations are published
• Trust Store — list of CAs the relying party trusts (OS, browser, custom)

Public CAs — the major ones

• Let’s Encrypt — free, automated; the default for most websites in 2026; 90-day cert lifetime
• Sectigo (formerly Comodo) — commercial; longer lifetimes, EV certs
• DigiCert — premium commercial; common in enterprise
• GlobalSign, Entrust, GoDaddy — also widely used
• Google Trust Services — Google’s own CA; free options for cloud customers
• ZeroSSL, Buypass — alternative free ACME providers

Choosing matters less than it used to — most browsers trust the major CAs equally; Let’s Encrypt is acceptable for nearly all use cases.

Certificate types

• DV (Domain Validation) — proves you control the domain. Most common; cheap or free. Issued via ACME or email/DNS challenge
• OV (Organization Validation) — DV + verified organization name. Visible in cert details
• EV (Extended Validation) — extensive vetting; used to show green address bar (no longer in browsers); still used in regulated sectors for high-trust signaling
• Wildcard — *.example.com. Single cert covers all subdomains. Operational simplicity vs single-point-of-compromise
• Multi-domain (SAN) — covers multiple specific names
• Code signing — for signing executables; different EKU; different trust paths
• Document signing — for signing PDFs etc
• Client certs — for mTLS authentication

The ACME protocol

Automatic Certificate Management Environment (ACME) is the standard automation protocol for getting certs from a CA. Used by Let’s Encrypt, ZeroSSL, Buypass, Google Trust Services, others.

Standard flow:

1. Client generates an account key, registers with CA
2. Client requests a cert for example.com
3. CA presents a challenge: “prove you control example.com”
4. Client responds — HTTP-01 (file at well-known URL), DNS-01 (TXT record), or TLS-ALPN-01
5. CA validates the challenge
6. Client submits a CSR (Certificate Signing Request)
7. CA issues the cert

Tools: certbot, acme.sh, lego, native integration in many web servers (Caddy auto-provisions).

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

# Auto-renewal via cron / systemd timer (built-in)
certbot renew

# acme.sh for DNS-01 with Cloudflare
acme.sh --issue --dns dns_cf -d *.example.com -d example.com

Certificate lifecycle

1. Generation: private key generated; CSR submitted
2. Validation: CA verifies subject identity (DV/OV/EV vary in depth)
3. Issuance: CA signs and returns the cert
4. Deployment: cert installed on the system; private key protected
5. Use: active life — typically 90 days (LE) to 1-2 years (commercial); industry trending shorter
6. Renewal: automated via ACME; manual for non-ACME CAs
7. Revocation: if compromised — CRL or OCSP entry
8. Expiry: end of validity period; renewal must happen before

Revocation — the broken-but-mandatory mechanism

Two mechanisms:

• CRL (Certificate Revocation List): CA publishes signed list of revoked cert serial numbers. Clients download periodically. Large; slow to propagate; many clients don’t check
• OCSP (Online Certificate Status Protocol): client queries CA “is this cert revoked?” in real-time. Latency on every connection; privacy leak (CA learns who you visit)
• OCSP Stapling: server fetches OCSP response, attaches to TLS handshake. Eliminates client → CA round-trip
• Must-Staple: cert extension requiring OCSP response or refuse

Browser support for revocation is uneven. Chrome doesn’t reliably check OCSP; relies on CRLSets (Google-curated). Implication: don’t trust revocation as your only recovery from compromise — you also need to rotate the cert and replace it everywhere.

Internal PKI — when and how

Public CAs are great for internet-facing services. For internal services, mTLS authentication, code signing, document signing — internal PKI may make sense.

Considerations:

• Operational overhead — running a CA is non-trivial
• Trust distribution — internal CA root must be on every endpoint that trusts it
• Compromise impact — if internal CA’s signing key leaks, every cert it ever issued is suspect
• Lifetime management — automated rotation of internal certs

Tools for internal PKI:

• HashiCorp Vault PKI secrets engine — most flexible; programmable; common choice
• Cloudflare CFSSL — open source; basic but solid
• step-ca (Smallstep) — modern; ACME support; good for service mesh
• Microsoft AD CS — for Windows-heavy environments
• Cloud-managed PKI — AWS Private CA, GCP CA Service, Azure-managed PKI

Service mesh PKI

Istio, Linkerd, Consul Connect — all rely on internal PKI to issue short-lived certs (often 24-hour) to every workload for mTLS. Patterns:

• Mesh control plane embeds a CA
• Workload identity = SPIFFE format (e.g., spiffe://cluster.local/ns/prod/sa/api)
• Certificates rotate automatically; engineers never see them
• Trust root is bootstrapped from cluster admin

Compromise of mesh CA = lateral movement enabled. Secure the bootstrap.

Code signing certificates

For signing executables (Windows, macOS) and packages (npm, PyPI, Docker images):

• Certs come from CAs that issue specifically for code signing
• Higher vetting (often EV requirements)
• Private key protection critical — leaked code signing key signs malware that’s now trusted
• Trend: HSM-backed keys (eToken or cloud HSM)
• Sigstore / Cosign for keyless signing of container images (covered in DevSecOps track)

Cert lifetime trends

Industry is pushing toward shorter cert lifetimes:

• 2018: maximum 825 days for public TLS
• 2020: capped at 397 days
• 2026: discussion of capping at 90 days for all public TLS (Apple/Google/Mozilla pushing)
• Shorter lifetimes → automated renewal mandatory; ACME everywhere

If you have a service with manual cert renewal, plan to automate. The window for “we’ll just renew it once a year” is closing.

Common PKI mistakes

• Long-lived certs that nobody renews → expired cert → outage
• Wildcard cert in 50 places; one compromise affects all → hard to revoke without breaking everything
• Code signing key stored in CI without HSM → key leak signs malicious code
• Internal CA root distributed via “everyone install this” instead of automation → some endpoints miss the trust update
• OCSP stapling not enabled → every client makes its own slow OCSP query
• Cert renewal works in test, fails in prod (different ACME challenge type, firewall block)
• Monitoring gaps — first you know is when the site is down

What the next module covers

Module 4 covers secrets management at scale — vaults, dynamic secrets, rotation, SDK integration. The complement to PKI for non-certificate secrets.