PKI Fundamentals: Understanding Certificates, CAs, and Trust Chains
A practical guide to Public Key Infrastructure. Understand how certificates work, build trust hierarchies, and implement PKI for your organization.
Public Key Infrastructure (PKI) underpins virtually all secure internet communication. Every HTTPS connection, every S/MIME email, every code signing operation relies on PKI. Yet most engineers treat certificates as magical incantations-copy the right commands from Stack Overflow and hope it works.
Understanding PKI fundamentals transforms certificate management from frustrating guesswork into predictable operations. This guide covers how PKI actually works, from asymmetric cryptography basics through enterprise PKI deployment.
The Trust Problem PKI Solves
When you connect to your bank's website, how do you know you're actually talking to your bank-not an attacker who intercepted the connection?
Without PKI, you can't. The attacker could present their own encryption key, establish a seemingly secure connection, and intercept everything. This is the classic man-in-the-middle attack.
┌─────────────────────────────────────────────────────────────────────────┐
│ MAN-IN-THE-MIDDLE WITHOUT PKI │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ You Attacker Bank │
│ ─── ──────── ──── │
│ │ │ │ │
│ │ "Connect to bank.com" │ │ │
│ │ ──────────────────────────►│ │ │
│ │ │ │ │
│ │ │ (Intercepts, connects │ │
│ │ │ to real bank) │ │
│ │ │─────────────────────────►│ │
│ │ │ │ │
│ │ "Here's MY public key" │ "Here's MY public key" │ │
│ │ ◄──────────────────────────│◄─────────────────────────│ │
│ │ │ │ │
│ │ 🔒 Encrypted with │ 🔒 Re-encrypted with │ │
│ │ attacker's key │ bank's real key │ │
│ │ ──────────────────────────►│─────────────────────────►│ │
│ │ │ │ │
│ │ 👁️ Attacker reads all │ │ │
│ │ your banking data │ │ │
│ │ │ │ │
└─────────────────────────────────────────────────────────────────────────┘
PKI solves this by binding public keys to verified identities. A trusted third party (Certificate Authority) vouches that "this public key belongs to bank.com." Your browser trusts certain CAs, those CAs verify identities, and the chain of trust lets you confirm you're talking to the real bank.
Asymmetric Cryptography Primer
PKI relies on asymmetric (public key) cryptography. Unlike symmetric encryption where both parties share the same secret key, asymmetric cryptography uses key pairs:
| Key | Who Has It | Purpose |
|---|---|---|
| Private Key | Owner only (secret) | Sign messages, decrypt data |
| Public Key | Anyone (published) | Verify signatures, encrypt data |
The mathematical relationship between keys enables two fundamental operations:
Encryption: Anyone can encrypt data with your public key. Only you can decrypt it with your private key.
Signing: You sign data with your private key. Anyone can verify the signature with your public key.
┌─────────────────────────────────────────────────────────────────────────┐
│ ASYMMETRIC KEY OPERATIONS │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ENCRYPTION (Confidentiality) │
│ ──────────────────────────── │
│ │
│ Sender Recipient │
│ ────── ───────── │
│ ┌──────────────┐ │
│ │ Plaintext │ ──► Public Key ──► ┌──────────────┐ │
│ │ Message │ │ Ciphertext │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ▼ │
│ Private Key ──► ┌──────────────┐ │
│ │ Plaintext │ │
│ │ Message │ │
│ └──────────────┘ │
│ │
│ ═══════════════════════════════════════════════════════════════════ │
│ │
│ SIGNING (Authentication) │
│ ──────────────────────── │
│ │
│ Signer Verifier │
│ ────── ──────── │
│ ┌──────────────┐ │
│ │ Document │ ──► Hash ──► Private Key ──► ┌──────────────┐ │
│ └──────────────┘ │ Signature │ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ Public Key ──► Verify ──► ✓ or ✗ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Anatomy of a Certificate
A certificate is a signed document binding a public key to an identity. It contains:
┌─────────────────────────────────────────────────────────────────────────┐
│ X.509 CERTIFICATE STRUCTURE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Certificate │
│ ├── Version: 3 (most common) │
│ ├── Serial Number: Unique identifier │
│ ├── Signature Algorithm: sha256WithRSAEncryption │
│ │ │
│ ├── Issuer (Who signed this certificate) │
│ │ └── CN=DigiCert TLS RSA SHA256 2020 CA1 │
│ │ O=DigiCert Inc, C=US │
│ │ │
│ ├── Validity │
│ │ ├── Not Before: Dec 15 00:00:00 2023 GMT │
│ │ └── Not After: Jan 14 23:59:59 2025 GMT │
│ │ │
│ ├── Subject (Who this certificate identifies) │
│ │ └── CN=www.example.com │
│ │ O=Example Corp, L=San Francisco, ST=California, C=US │
│ │ │
│ ├── Subject Public Key Info │
│ │ ├── Algorithm: RSA (2048 bit) │
│ │ └── Public Key: 30 82 01 0a 02 82 01 01 00 c7 85... │
│ │ │
│ ├── Extensions │
│ │ ├── Subject Alternative Name (SAN) │
│ │ │ └── DNS:www.example.com, DNS:example.com │
│ │ ├── Key Usage: Digital Signature, Key Encipherment │
│ │ ├── Extended Key Usage: TLS Web Server Authentication │
│ │ ├── Basic Constraints: CA:FALSE │
│ │ └── CRL Distribution Points: http://crl.digicert.com/... │
│ │ │
│ └── Signature (CA's signature over all above data) │
│ └── 5a 73 c4 89 a5 14 72 48 6f 3c d0 b6 77... │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Key Fields Explained
| Field | Purpose |
|---|---|
| Subject | Entity the certificate identifies (your domain/org) |
| Issuer | CA that signed the certificate |
| Validity | Time period certificate is valid |
| Public Key | The actual cryptographic key |
| SAN | Additional domains/IPs the cert covers |
| Key Usage | What the key can be used for |
| Signature | CA's cryptographic signature proving authenticity |
Certificate Types by Validation Level
| Type | Validation | Indicators | Use Case |
|---|---|---|---|
| DV (Domain Validated) | Prove domain control | Lock icon only | Basic websites |
| OV (Organization Validated) | Verify legal entity | Org name in cert | Business sites |
| EV (Extended Validation) | Extensive verification | Green bar (legacy) | Banks, e-commerce |
DV certificates are automated and instant (Let's Encrypt). OV and EV require manual verification of business documents.
The Chain of Trust
Browsers don't trust certificates directly-they trust Certificate Authorities. CAs are organizations vetted to verify identities and sign certificates.
┌─────────────────────────────────────────────────────────────────────────┐
│ CERTIFICATE CHAIN │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ROOT CA (Trust Anchor) │
│ ──────────────────────── │
│ ┌─────────────────────────────────────────┐ │
│ │ DigiCert Global Root CA │ ◄── Embedded in browsers │
│ │ Self-signed (issuer = subject) │ /OS trust stores │
│ │ Validity: 25 years │ │
│ └────────────────────┬────────────────────┘ │
│ │ Signs │
│ ▼ │
│ INTERMEDIATE CA │
│ ─────────────── │
│ ┌─────────────────────────────────────────┐ │
│ │ DigiCert TLS RSA SHA256 2020 CA1 │ ◄── Signed by Root │
│ │ Signed by: DigiCert Global Root CA │ │
│ │ Validity: 10 years │ │
│ └────────────────────┬────────────────────┘ │
│ │ Signs │
│ ▼ │
│ END-ENTITY CERTIFICATE (Leaf) │
│ ───────────────────────────── │
│ ┌─────────────────────────────────────────┐ │
│ │ www.example.com │ ◄── Your certificate │
│ │ Signed by: DigiCert TLS RSA SHA256... │ │
│ │ Validity: 1 year │ │
│ └─────────────────────────────────────────┘ │
│ │
│ VERIFICATION: Browser walks chain from leaf → intermediate → root │
│ If root is in trust store, entire chain is trusted │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Why Intermediates?
Root CA private keys are incredibly valuable-compromising one compromises all certificates it ever issued. So roots are kept offline, in hardware security modules, used only to sign intermediate CA certificates.
Intermediates handle day-to-day signing. If an intermediate is compromised, only that intermediate's certificates are affected, and it can be revoked without invalidating the root.
Trust Store Management
Operating systems and browsers maintain lists of trusted root CAs:
| Platform | Trust Store Location |
|---|---|
| Windows | Certmgr.msc → Trusted Root CAs |
| macOS | Keychain Access → System Roots |
| Linux | /etc/ssl/certs/ |
| Firefox | Built-in (independent of OS) |
| Chrome | Uses OS trust store |
| Java | cacerts keystore |
Enterprise environments often add internal CA roots to trust stores for internal applications.
Certificate Lifecycle
Generation
# Generate private key
openssl genrsa -out server.key 2048
# Generate CSR (Certificate Signing Request)
openssl req -new -key server.key -out server.csr \
-subj "/CN=www.example.com/O=Example Corp/C=US"
# View CSR contents
openssl req -in server.csr -noout -text
The CSR contains your public key and identity information. You send this to the CA-never the private key.
Validation
For DV certificates (Let's Encrypt, etc.), validation proves domain control:
| Method | How It Works |
|---|---|
| HTTP-01 | Place file at /.well-known/acme-challenge/ |
| DNS-01 | Create TXT record _acme-challenge.domain.com |
| TLS-ALPN-01 | Present special cert on port 443 |
For OV/EV, additional verification of business identity is required.
Issuance
The CA signs your CSR and returns the certificate. You'll typically receive:
- Your certificate (leaf/end-entity)
- Intermediate certificate(s)
- Root certificate (optional-usually not needed)
Deployment
Configure your server with the complete chain:
# Nginx configuration
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/ssl/certs/example.com.crt; # Cert + chain
ssl_certificate_key /etc/ssl/private/example.com.key; # Private key
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
}
The certificate file should contain your cert + intermediates (fullchain):
# Concatenate cert + intermediates
cat server.crt intermediate.crt > fullchain.crt
Renewal
Certificates expire. Automate renewal before expiration:
# Let's Encrypt automatic renewal (certbot)
certbot renew --dry-run
# Add to crontab
0 0 * * * certbot renew --quiet
Revocation
When private keys are compromised, revoke the certificate:
| Method | Description |
|---|---|
| CRL (Certificate Revocation List) | Published list of revoked certs |
| OCSP (Online Certificate Status Protocol) | Real-time status check |
| OCSP Stapling | Server includes OCSP response in TLS handshake |
Common Certificate Problems
Incomplete Chain
Browser shows certificate error even though cert is valid-usually missing intermediates.
# Test certificate chain
openssl s_client -connect example.com:443 -showcerts
# Look for:
# depth=0 → your certificate
# depth=1 → intermediate
# depth=2 → root (may not be sent)
# Verify chain
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt fullchain.pem
Fix: Ensure your server sends the complete chain (cert + intermediates).
Name Mismatch
Certificate doesn't match the hostname being accessed.
# Check certificate names
openssl s_client -connect example.com:443 | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
Fix: Ensure certificate includes all hostnames in SAN (Subject Alternative Name).
Expired Certificate
Certificate validity period has passed.
# Check expiration
openssl s_client -connect example.com:443 | openssl x509 -noout -dates
Fix: Renew certificate before expiration. Automate this.
Self-Signed Certificate
Certificate not signed by a trusted CA.
Fix: Use a certificate from a trusted CA for public services. Self-signed is acceptable for internal testing only.
Enterprise PKI
Organizations running internal applications often deploy private PKI:
┌─────────────────────────────────────────────────────────────────────────┐
│ ENTERPRISE PKI ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ OFFLINE ROOT CA │
│ ─────────────── │
│ ┌─────────────────────────────────────────┐ │
│ │ Internal Root CA │ │
│ │ • Kept offline (air-gapped) │ │
│ │ • HSM-protected private key │ │
│ │ • Signs only intermediate CAs │ │
│ │ • 20+ year validity │ │
│ └────────────────────┬────────────────────┘ │
│ │ │
│ ┌───────────┴───────────┐ │
│ │ │ │
│ ▼ ▼ │
│ ISSUING CA (Servers) ISSUING CA (Users) │
│ ──────────────────── ────────────────── │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Server Cert CA │ │ User Cert CA │ │
│ │ • Online │ │ • Online │ │
│ │ • Issues TLS │ │ • Issues client │ │
│ │ certs │ │ certs │ │
│ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Server Certs │ │ Client Certs │ │
│ │ • intranet │ │ • User auth │ │
│ │ • internal │ │ • VPN │ │
│ │ apps │ │ • S/MIME │ │
│ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Deploying Internal CA
For internal PKI, options include:
| Solution | Complexity | Use Case |
|---|---|---|
| OpenSSL scripts | Low | Small scale, testing |
| step-ca | Medium | Modern internal PKI |
| EJBCA | High | Enterprise, compliance |
| Microsoft AD CS | Medium | Windows environments |
| HashiCorp Vault | Medium | DevOps/cloud native |
Trust Distribution
Internal root CA must be trusted by all clients:
| Platform | Distribution Method |
|---|---|
| Windows (AD) | Group Policy |
| macOS | MDM profiles |
| Linux | Package, configuration management |
| Containers | Mount CA bundle |
| Mobile | MDM profiles |
PKI Best Practices
Key Management
| Practice | Reason |
|---|---|
| RSA 2048-bit minimum | 1024-bit is deprecated |
| ECDSA P-256 preferred | Smaller, faster, equally secure |
| HSM for CA keys | Tamper-resistant key storage |
| Rotate keys regularly | Limit exposure window |
Certificate Policies
| Policy | Recommendation |
|---|---|
| Validity period | 90 days (automated) or 1 year max |
| Key usage | Restrict to intended purpose |
| SAN vs CN | Use SAN; CN is deprecated |
| Wildcards | Avoid where possible |
Operational Security
- Automate renewal: Manual renewal leads to outages
- Monitor expiration: Alert 30+ days before
- Maintain inventory: Know every cert in your environment
- Plan for revocation: Have process ready before compromise
- Audit regularly: Review trust stores and issued certs
Certificate Transparency
Certificate Transparency (CT) requires CAs to log all issued certificates publicly. This detects misissued certificates:
┌─────────────────────────────────────────────────────────────────────────┐
│ CERTIFICATE TRANSPARENCY │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ CA issues cert ─► │ CT Log Server │ │
│ │ (append-only) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Monitor │ │ Monitor │ │ Monitor │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Alert: Unexpected certificate for your domain detected! │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Monitor CT logs for certificates issued to your domains:
- crt.sh (search interface)
- Facebook CT Monitor
- Google Certificate Transparency
Next Steps
PKI knowledge transforms certificate management from mysterious to methodical. Start by understanding your current certificate inventory, implement automated renewal, and establish monitoring for expiration and CT alerts.
We help organizations implement and manage PKI infrastructure. Request an assessment to evaluate your certificate management practices.
Running internal PKI or managing hundreds of certificates? We've designed and operated PKI for enterprises with complex certificate requirements. Contact us to discuss your needs.