PKI Hierarchy Design (1-tier, 2-tier, 3-tier)

PKI hierarchy design determines how many CA layers exist between the trust anchor (Root CA) and end-entity certificates. A 1-tier hierarchy has a single CA that both anchors trust and issues certificates. A 2-tier hierarchy separates the Root (offline, protected) from the Issuing CA (online, operational). A 3-tier hierarchy adds a Policy CA between them, enabling multiple Issuing CAs with different policies under a single root. The choice is architectural — it affects security posture, operational complexity, and how you recover from compromise.

Why it matters

• Compromise recovery — in a 1-tier design, compromising the single CA means total loss. In 2-tier, you revoke the Issuing CA and create a new one without touching the Root. In 3-tier, you can revoke one Issuing CA without affecting others under the same Policy CA.
• Operational separation — the Root CA should be offline (air-gapped, HSM-stored). If it also issues certificates, it must be online — defeating the purpose of protecting it. Hierarchy depth enables this separation.
• Policy segmentation — a 3-tier design lets you enforce different policies (key sizes, validity periods, allowed usages) per Issuing CA while maintaining a single trust anchor. Useful when one organization needs TLS certs, code signing certs, and device certs with different requirements.
• Scalability — adding capacity means adding Issuing CAs, not modifying the Root. In a 2-tier design, you can add regional Issuing CAs or purpose-specific Issuing CAs without any Root CA ceremony.
• Permanence — hierarchy depth is chosen once and is extremely difficult to change. Moving from 1-tier to 2-tier requires creating a new Root, re-issuing all certificates, and re-distributing trust to every client. Plan for your 5-year needs, not today’s.

How it works

1-Tier (Single CA):

1. One CA serves as both Root and Issuing CA
2. The CA is online (must be, to issue certificates)
3. End-entity certificates chain directly to this single CA
4. If compromised: total loss, no recovery without new CA + full re-issuance

2-Tier (Root + Issuing):

1. Root CA is created offline during a key ceremony, stored in HSM
2. Root signs one or more Issuing CA certificates
3. Root goes offline — powered down, stored in a safe
4. Issuing CA operates online, handles all certificate requests
5. If Issuing CA is compromised: revoke it, Root signs a new Issuing CA, re-issue affected certificates
6. Root CA is brought online only for: signing new Issuing CAs, renewing Issuing CA certificates, or emergency revocation

3-Tier (Root + Policy + Issuing):

1. Root CA created offline (same as 2-tier)
2. Root signs one or more Policy CAs (also called Intermediate CAs)
3. Each Policy CA defines a certificate policy scope (e.g., “TLS certificates”, “Code signing”, “Device identity”)
4. Policy CAs sign Issuing CAs within their scope
5. Issuing CAs handle end-entity issuance
6. Compromise of one Issuing CA affects only certificates under that specific policy branch

In real systems

2-Tier with Microsoft AD CS (most common enterprise setup):

Root CA: Standalone CA on Windows Server (offline, powered off)
  - Key: RSA 4096, stored in HSM (or software if budget-constrained)
  - Validity: 20 years
  - CRL: published manually during ceremonies (1-year validity)

Issuing CA: Enterprise CA on Windows Server (online, AD-integrated)
  - Key: RSA 2048 or ECDSA P-256, stored in HSM
  - Validity: 10 years (signed by Root)
  - CRL: published every 1-7 days to AD/HTTP
  - Templates: User auth, server TLS, workstation, code signing

2-Tier with EJBCA (open source):

# Root CA created with offline profile
ejbca ca init "Root CA" \
  --keyspec RSA4096 \
  --validity 7300  # 20 years

# Issuing CA signed by Root
ejbca ca init "Issuing CA" \
  --keyspec ECDSAP256 \
  --signedby "Root CA" \
  --validity 3650  # 10 years

3-Tier in government/large enterprise:

Root CA (Offline, 25-year validity)
├── Policy CA: TLS Certificates (15-year validity)
│   ├── Issuing CA: US Region (5-year validity)
│   └── Issuing CA: EU Region (5-year validity)
├── Policy CA: Code Signing (15-year validity)
│   └── Issuing CA: Engineering (5-year validity)
└── Policy CA: Device Identity (15-year validity)
    ├── Issuing CA: Manufacturing Line A
    └── Issuing CA: Manufacturing Line B

AWS Private CA (2-tier, cloud-managed):

# Root CA
aws acm-pca create-certificate-authority \
  --certificate-authority-type ROOT \
  --key-algorithm EC_prime256v1

# Subordinate (Issuing) CA
aws acm-pca create-certificate-authority \
  --certificate-authority-type SUBORDINATE \
  --key-algorithm EC_prime256v1
# Then sign the subordinate with the root

Where it breaks

1-tier in production — a team sets up a single CA for “quick internal PKI.” It issues certificates for mTLS between 200 microservices. The CA server is compromised via an unpatched vulnerability. Every certificate is now untrusted. There’s no offline Root to fall back to — the entire PKI must be rebuilt from scratch, and every service must be re-provisioned with new certificates simultaneously. A 2-tier design would have contained this to revoking the Issuing CA and signing a new one.

Root CA validity shorter than hierarchy — the Root CA certificate is valid for 10 years. The Issuing CA is valid for 10 years. Five years in, the Issuing CA needs renewal — but the Root’s remaining validity (5 years) is shorter than the Issuing CA’s desired validity (10 years). The Issuing CA can only be renewed for 5 years maximum. Rule: Root validity must be significantly longer than any subordinate’s validity. Typical: Root 20-25 years, Policy CA 10-15 years, Issuing CA 5-10 years.

3-tier complexity without justification — a 50-person company deploys a 3-tier hierarchy because “it’s more secure.” They now have 5 CAs to manage, 3 layers of CRL publication, and key ceremonies for both Root and Policy CAs. The operational overhead exceeds their team’s capacity. CRLs expire because nobody remembers to run the Policy CA ceremony. Certificates fail validation because the chain is incomplete. A 2-tier design would have served them with a fraction of the operational burden.

Operational insight

The most common mistake in hierarchy design is under-planning validity periods. Every CA certificate in the chain must be valid for longer than any certificate it signs. If your Issuing CA has 5 years remaining and issues a 2-year certificate, that certificate becomes unverifiable when the Issuing CA expires in 5 years — even though the end-entity cert hasn’t expired yet. The chain breaks at the intermediate. Plan validity periods top-down: Root (20 years) → Issuing CA (10 years) → End entity (1-2 years), ensuring each layer has comfortable headroom above the layer below it.

Related topics

• Root CA vs Intermediate CA
• What is a Certificate Authority
• Cloud-based PKI
• PKI Trust Models
• Certificate Policy and Practice Statement