Certificate Authority Hierarchy: Complete Guide

Root Certificate Authorities

Root CAs are the trust anchors of the PKI system. They are self-signed certificates that are pre-installed in browsers, operating systems, and devices.

Key Characteristics

• • Self-signed: The certificate is signed by its own private key
• • Kept offline: The private key is generated during a formal key ceremony and stored in HSMs in secure facilities
• • Long validity: Typically 20-30 years
• • Pre-installed: Included in OS/browser trust stores
• • basicConstraints: CA:TRUE: Allowed to sign other certificates

Major Root CAs

Intermediate CAs (Why They Exist)

Intermediate CAs sit between the Root CA and end-entity certificates. They're the workhorses that actually issue certificates on a daily basis.

Why Not Issue Directly from Root?

Intermediate CA Characteristics

• • Signed by Root CA: Creates the chain of trust
• • Stays online: Needs to issue certificates on demand
• • Shorter validity: Typically 5-10 years
• • basicConstraints: CA:TRUE: Can sign certificates
• • pathLenConstraint: May limit how many levels below it

Leaf (End-Entity) Certificates

Leaf certificates are the certificates installed on your actual servers, devices, or used for email signing. They're called "leaf" because they're at the end of the trust tree—they can't sign other certificates.

Leaf Certificate Characteristics

• • Signed by Intermediate CA: Part of the chain
• • Short validity: 90 days (Let's Encrypt) to 1 year (commercial)
• • basicConstraints: CA:FALSE: Cannot sign other certificates
• • Subject Alternative Names: Lists all valid domains
• • Key Usage: Digital Signature, Key Encipherment

Types of Leaf Certificates

The Chain of Trust

When your browser connects to a website, it validates the entire certificate chain from your server's certificate up to a trusted Root CA.

Validation Process

Common Chain Problems

View a Certificate Chain

# View full chain from a server
openssl s_client -connect example.com:443 -showcerts

# Parse the chain
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -subject -issuer

# Check chain is valid
openssl verify -CAfile /path/to/root.pem \
  -untrusted /path/to/intermediate.pem \
  /path/to/leaf.pem

What Happens When CAs Are Compromised

The impact of a key compromise depends entirely on which level of the hierarchy is affected.

Cross-Signing Explained

Cross-signing is when one CA signs another CA's certificate, creating an alternative trust path. This is commonly used when new CAs need to establish trust before their own root is widely distributed.

Let's Encrypt Example

Benefits of Cross-Signing

• ✓ New CAs can gain instant trust via established CAs
• ✓ Enables graceful transition as new roots propagate
• ✓ Supports older devices that don't receive trust store updates

Viewing Certificate Chains

Using OpenSSL

# See full chain from a live server
openssl s_client -connect example.com:443 -showcerts 2>/dev/null

# Count certificates in chain
openssl s_client -connect example.com:443 2>/dev/null | \
  grep -c "BEGIN CERTIFICATE"

# View chain details
openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep -E "(Subject:|Issuer:|Not After)"

In Your Browser

• • Chrome: Click padlock → Certificate → Certification Path tab
• • Firefox: Click padlock → Connection → More Information → View Certificate
• • Safari: Click padlock → Show Certificate → expand the chain

Frequently Asked Questions