PKI Fundamentals: Understanding Certificates, CAs, and Trust Chains

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.

Without PKI — Man-in-the-Middle Attack:

1. You request connection to bank.com
2. Attacker intercepts and connects to the real bank
3. Attacker sends YOU their public key (not the bank's)
4. Bank sends the attacker its real public key
5. You encrypt data with attacker's key → attacker decrypts, re-encrypts with bank's key, forwards
6. 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.

Encryption (Confidentiality):

Sender encrypts plaintext message with recipient's public key → ciphertext → recipient decrypts with private key → plaintext message

Signing (Authentication):

Signer hashes document, signs hash with private key → signature → verifier checks signature with public key → valid ✓ or invalid ✗

---

Anatomy of a Certificate

A certificate is a signed document binding a public key to an identity. It contains:

X.509 Certificate Structure:

• 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 cryptographic 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.

Root CA (Trust Anchor)

• DigiCert Global Root CA
• Self-signed (issuer = subject)
• Validity: 25 years
• Embedded in browsers/OS trust stores

↓ Signs

Intermediate CA

• DigiCert TLS RSA SHA256 2020 CA1
• Signed by: DigiCert Global Root CA
• Validity: 10 years

↓ Signs

End-Entity Certificate (Leaf)

• www.example.com
• Signed by: DigiCert TLS RSA SHA256 2020 CA1
• Validity: 1 year
• Your certificate

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:

1. Your certificate (leaf/end-entity)
2. Intermediate certificate(s)
3. 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:

Offline Root CA

• Internal Root CA
• Kept offline (air-gapped)
• HSM-protected private key
• Signs only intermediate CAs
• 20+ year validity

↓ Signs two Issuing CAs:

Issuing CA (Servers)

• Online
• Issues TLS certs for:
  • Intranet sites
  • Internal apps

Issuing CA (Users)

• Online
• Issues client certs for:
  • User authentication
  • VPN access
  • S/MIME email

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

1. Automate renewal: Manual renewal leads to outages
2. Monitor expiration: Alert 30+ days before
3. Maintain inventory: Know every cert in your environment
4. Plan for revocation: Have process ready before compromise
5. 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 Flow:

1. CA issues certificate → logs it to CT Log Server (append-only)
2. Multiple monitors watch the CT logs
3. If an unexpected certificate for your domain is detected → Alert triggered

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. Organizations implementing zero trust security will need robust PKI infrastructure to support certificate-based authentication.

We help organizations implement and manage PKI infrastructure through our security services. 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.