Module 3 · PKI Architecture 🔒

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