Public Key Infrastructure (PKI) Cheat Sheet
Covers PKI components, certificate lifecycle, chain of trust, and common OpenSSL commands for generating and inspecting certificates.
2 PagesIntermediateJan 28, 2026
Core PKI Components
The building blocks of a public key infrastructure.
- CA (Certificate Authority)- Trusted entity that issues and signs digital certificates
- RA (Registration Authority)- Verifies identity before a CA issues a certificate
- Certificate- Binds a public key to an identity, signed by a CA
- CRL- Certificate Revocation List, a published list of revoked certificates
- OCSP- Online Certificate Status Protocol, real-time revocation checking
- Root CA- Top of the trust chain; self-signed, kept offline for security
- Intermediate CA- Signed by root CA, issues end-entity certs; limits root exposure
Generating Keys and a CSR (OpenSSL)
Creating a private key and certificate signing request.
bash
# Generate a 2048-bit RSA private keyopenssl genrsa -out server.key 2048# Generate a Certificate Signing Request (CSR)openssl req -new -key server.key -out server.csr \ -subj "/C=US/ST=CA/O=Example Inc/CN=example.com"# Self-sign a certificate (for testing only)openssl x509 -req -days 365 -in server.csr \ -signkey server.key -out server.crt
Inspecting Certificates (OpenSSL)
Viewing certificate details and checking a live server's cert.
bash
# View certificate detailsopenssl x509 -in server.crt -text -noout# Check expiration dateopenssl x509 -in server.crt -noout -enddate# Inspect a certificate served by a live hostopenssl s_client -connect example.com:443 -showcerts
Chain of Trust Concepts
How certificate validation establishes trust.
- Trust anchor- Root CA certificate pre-installed in OS/browser trust stores
- Certificate chain- Leaf cert -> intermediate CA(s) -> root CA, each signed by the next
- Chain validation- Client verifies each signature up to a trusted root, and checks expiry/revocation
- Self-signed certificate- Not signed by a trusted CA; triggers browser warnings unless manually trusted
Modern CSR with Subject Alternative Names
Browsers ignore the CN field entirely today; every valid cert must list its hostnames in the SAN extension via a config file.
bash
cat > san.cnf <<'EOF'[req]distinguished_name = dnreq_extensions = extprompt = no[dn]CN = example.comO = Example Inc[ext]subjectAltName = @alt_names[alt_names]DNS.1 = example.comDNS.2 = www.example.comDNS.3 = api.example.comEOFopenssl req -new -key server.key -out server.csr -config san.cnf# Verify the SAN extension made it into the CSRopenssl req -in server.csr -noout -text | grep -A1 'Subject Alternative Name'
Certificate/Public-Key Pinning Verification
Extracts a SPKI (Subject Public Key Info) hash for pinning a specific key rather than trusting the full CA chain.
bash
# Compute the SPKI pin (used in HPKP-style or app-level cert pinning)openssl x509 -in server.crt -pubkey -noout | \ openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | \ openssl enc -base64# Compare against a live server's presented leaf certificateecho | openssl s_client -connect example.com:443 2>/dev/null | \ openssl x509 -pubkey -noout | \ openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | openssl enc -base64
Mutual TLS (Client Certificate) Setup
Both parties present certificates; the server authenticates the client cryptographically instead of (or alongside) a password/token.
bash
# Generate a client CA and sign a client certificateopenssl genrsa -out client-ca.key 4096openssl req -x509 -new -key client-ca.key -days 3650 \ -out client-ca.crt -subj "/CN=Internal Client CA"openssl genrsa -out client.key 2048openssl req -new -key client.key -out client.csr -subj "/CN=service-account-42"openssl x509 -req -in client.csr -CA client-ca.crt -CAkey client-ca.key \ -CAcreateserial -out client.crt -days 365# nginx server-side enforcement (excerpt)# ssl_client_certificate /etc/nginx/client-ca.crt;# ssl_verify_client on;# curl presenting the client certcurl --cert client.crt --key client.key https://internal.example.com/
Verifying OCSP Stapling
OCSP stapling lets the server proactively attach revocation proof, avoiding client-side OCSP round trips and privacy leaks.
bash
# Check whether a server staples a valid OCSP response during the handshakeopenssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | \ grep -A17 'OCSP response'# Manually query an OCSP responder for a certificate's statusopenssl ocsp -issuer intermediate.crt -cert server.crt \ -url http://ocsp.example-ca.com -text -no_nonce
PKI Failure Modes and Mitigations
Ways trust chains break down in practice, beyond simple expiry.
- CA compromise- A breached CA can mis-issue certs for any domain; browsers respond via Certificate Transparency monitoring and distrust
- Certificate Transparency (CT)- Public append-only logs of issued certs; CAs must submit SCTs so mis-issuance becomes publicly detectable
- Weak/short-lived revocation checking- CRLs are slow to propagate and OCSP can fail open; CT + short cert lifetimes reduce reliance on revocation entirely
- Cross-signed intermediates- An intermediate signed by two different roots to ease migration; validators must build the correct path, not just any valid one
- Name constraints- Restricts which domains a subordinate/private CA is permitted to issue for, limiting blast radius of a compromised intermediate
- Key compromise vs cert compromise- Revoking a cert doesn't help if the private key is reused elsewhere; rotate the key, not just reissue the cert
Pro Tip
Keep root CA private keys offline and air-gapped; use intermediate CAs for day-to-day certificate issuance so a compromised intermediate can be revoked without invalidating the entire trust chain.
Was this cheat sheet helpful?
Explore Topics
#PublicKeyInfrastructurePKI#PublicKeyInfrastructurePKICheatSheet#Cybersecurity#Intermediate#CorePKIComponents#Generating#Keys#CSR#CheatSheet#SkillVeris
