Module 1: PKI Fundamentals
Lesson 1.4: The PKI Trust Hierarchy
20–25 minutes
Reading + Quiz
Lesson 4 of 18Module 1 of 5
How to Use This Lesson
- 1.Read each section in order — they build on each other.
- 2.Study the trust hierarchy diagrams carefully — they are the mental model for all future lessons.
- 3.Use "Listen to This Lesson" in the sidebar for optional audio narration.
- 4.Complete the knowledge check at the bottom.
- 5.Mark the lesson complete and continue to Lesson 1.5.
Lesson Summary
The PKI trust hierarchy is the chain of certificate authorities — Root CA, Issuing CAs, and end-entity certificates — that allows any client to validate any certificate by tracing a path back to a trusted root. Understanding how this chain is built, validated, and protected is the foundation of all PKI architecture and troubleshooting.
Learning Objectives
- Describe the role of the Root CA, Issuing CA, and end-entity certificate in the trust hierarchy.
- Explain why Root CA certificates are self-signed and why Root CAs must be kept offline.
- Trace a certification path from an end-entity certificate to a trusted root.
- Explain how the trust store enables certificate validation.
- Identify the Basic Constraints extension and explain its role in preventing unauthorized certificate issuance.
- Describe common enterprise PKI hierarchy designs (two-tier and three-tier).
A
The Trust Hierarchy Concept
PKI is built on a simple but powerful idea: trust is transitive. If you trust entity A, and A vouches for entity B, and B vouches for entity C, then you trust C — as long as the chain of vouching is intact and every signature is valid.
In PKI, "vouching" means signing a certificate. When a CA signs a certificate, it is asserting: "I have verified this subject's identity and I am binding their public key to this identity." The trust hierarchy is the chain of these assertions from a trusted root down to the certificate you are trying to validate.
The PKI Trust Chain — Northstar Manufacturing
Northstar Root CA
Self-signed · Offline · 20-year validity
Trust Anchor — in every machine's trust store
Root CA signs ↓
Northstar Issuing CA
Signed by Root CA · Online · 10-year validity
Issues certificates to servers, users, devices
Issuing CA signs ↓
End-entity (leaf) certificates — cannot sign other certificates
Key Concept
Trust flows downward; validation flows upward
Trust is established from the root downward — the Root CA signs the Issuing CA, which signs end-entity certificates. But certificate validation works in the opposite direction: a client starts with the end-entity certificate and builds the chain upward until it reaches a trusted root. Both directions must be understood to troubleshoot PKI issues.
B
The Root Certificate Authority
The Root CA is the top of the trust hierarchy. It has three defining characteristics that distinguish it from all other CAs:
Self-signed certificate
The Root CA signs its own certificate with its own private key. There is no higher authority to sign it. The certificate is trusted because it is explicitly installed in the trust store — not because of a higher signature.
Offline posture
Enterprise Root CAs are kept offline — powered down and stored in a physically secured location (often a safe or HSM vault). The Root CA only comes online to sign Issuing CA certificates, which happens infrequently.
Long validity period
Root CA certificates typically have 20-year validity periods. Because the Root CA is offline and rarely used, long validity is practical. Issuing CA certificates are shorter (5–10 years); end-entity certificates are shorter still (1–2 years).
Security Consideration
Root CA compromise is catastrophic
If the Root CA private key is compromised, every certificate in the hierarchy must be considered untrusted. The attacker can sign fraudulent Issuing CA certificates, which can then sign fraudulent end-entity certificates that pass all validation checks. Recovery requires replacing the Root CA, all Issuing CAs, all end-entity certificates, and updating the trust store on every machine. This is why Root CA private keys are protected by HSMs and the Root CA is kept offline.
C
Issuing CAs (Subordinate CAs)
Issuing CAs (also called Subordinate CAs or Intermediate CAs) are the workhorses of the PKI hierarchy. They are online, handle day-to-day certificate issuance, and are signed by the Root CA or a Policy CA above them.
Separating the Issuing CA from the Root CA is a fundamental security design. If an Issuing CA is compromised, only the certificates it issued need to be revoked — the Root CA and other Issuing CAs remain unaffected. The Root CA can revoke the compromised Issuing CA's certificate and issue a new one.
PropertyTypical Value
Signed byRoot CA or Policy CA
Online/OfflineOnline — must be reachable to issue certificates
Validity period5–10 years (shorter than Root CA)
Key size (RSA)2048–4096 bit (4096 recommended for new deployments)
Basic ConstraintscA=TRUE, pathLenConstraint=0 (cannot create sub-CAs)
CRL publishingPublishes CRLs for certificates it has issued
OCSPMay host an OCSP responder for real-time revocation checking
Production Note
Multiple Issuing CAs for separation of duties
Large enterprises often deploy multiple Issuing CAs for different purposes: one for user certificates, one for server certificates, one for device certificates, one for code signing. This limits the blast radius of a compromise and allows different certificate policies (validity periods, key usage, templates) per CA. Each Issuing CA publishes its own CRL and AIA.
D
Two-Tier vs. Three-Tier Hierarchy Designs
Enterprise PKI deployments use either a two-tier or three-tier hierarchy. The choice depends on the size of the organization, the number of Issuing CAs needed, and the required level of separation.
Two-Tier Hierarchy
Root CA (Offline)
Issuing CA (Online)
End-Entity Certificates
Best for: Small to medium enterprises. Simpler to manage. Root CA directly signs Issuing CA certificates. Most common design for internal enterprise PKI.
Three-Tier Hierarchy
Root CA (Offline)
Policy CA (Offline)
Issuing CA (Online)
End-Entity Certificates
Best for: Large enterprises, government, or organizations with multiple Issuing CAs under different policies. Policy CA adds separation between Root and Issuing CAs.
Key Concept
Microsoft ADCS uses two-tier by default
The Microsoft Active Directory Certificate Services (ADCS) documentation and best practice guides recommend a two-tier hierarchy for most enterprise deployments: one offline Root CA and one or more online Issuing CAs. Three-tier hierarchies are used when additional policy separation is required. The PKI Foundations and ADCS Architecture courses cover both designs in detail.
E
End-Entity (Leaf) Certificates
End-entity certificates are issued to specific subjects — web servers, users, workstations, devices, services, or code signing identities. They are the "leaves" of the certificate tree: they cannot sign other certificates.
TLS/SSL Server Certificates
Issued to web servers and services. Used to authenticate the server and establish encrypted TLS sessions. Subject: CN=server.domain.local or SAN entries.
User Certificates
Issued to Active Directory user accounts. Used for smart card logon, S/MIME email signing/encryption, and EFS file encryption.
Computer/Workstation Certificates
Issued to domain-joined computers. Used for machine authentication (802.1X, IPsec, VPN), and to establish trust in domain environments.
Code Signing Certificates
Issued to developers or build systems. Used to sign executables, scripts, drivers, and packages. Extended Key Usage: Code Signing (1.3.6.1.5.5.7.3.3).
OCSP Responder Certificates
Issued to OCSP responders. Used to sign OCSP responses. Must have the id-kp-OCSPSigning EKU and typically the OCSP No Check extension.
Enrollment Agent Certificates
Issued to enrollment agents in ADCS. Allow the agent to enroll certificates on behalf of other users. Require careful access control — a common ADCS misconfiguration target.
F
The Trust Store
The trust store is the collection of Root CA certificates that a system trusts by default. When a client validates a certificate chain, it checks whether the root of the chain is in the trust store. If it is, the chain is trusted. If it is not, the certificate is untrusted regardless of how valid the signatures are.
Windows Certificate Store
Windows maintains the Trusted Root Certification Authorities store (certlm.msc → Trusted Root Certification Authorities). Enterprise Root CAs are distributed via Group Policy (Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities).
Browser Trust Stores
Chrome and Edge use the Windows certificate store on Windows. Firefox maintains its own trust store independent of the OS. Safari uses the macOS/iOS trust store. Enterprise deployments must distribute internal Root CA certificates to all relevant trust stores.
Java Trust Store (cacerts)
Java applications use the JDK cacerts trust store, which is separate from the OS trust store. Internal Root CA certificates must be imported into cacerts using keytool for Java applications to trust internal certificates.
Linux / OpenSSL Trust Store
Linux systems use the system CA bundle (typically /etc/ssl/certs/ or /etc/pki/tls/certs/). Internal Root CA certificates must be added using update-ca-certificates (Debian/Ubuntu) or update-ca-trust (RHEL/CentOS).
Common Mistake
Forgetting to distribute the Root CA certificate via Group Policy
The most common cause of "certificate not trusted" errors after deploying a new internal PKI is failing to distribute the Root CA certificate to the enterprise trust store. The certificate may be perfectly valid, the chain may be complete, but if the Root CA is not in the trust store, every client will show an error. Always verify trust store distribution as part of PKI deployment testing.
G
Certification Path Building and Validation
When a client receives a certificate, it must build and validate the certification path — the ordered chain from the end-entity certificate to a trusted root. This process is called path building and path validation.
Certification Path Validation — Step by Step
1
Start with the end-entity certificate
The client receives the server's certificate (e.g., in a TLS handshake). This is the starting point for path building.
2
Find the issuing CA certificate
The client looks at the Issuer field and AIA extension to find the issuing CA certificate. It may be in the local cache, sent by the server, or downloaded from the AIA URL.
3
Verify the CA's signature on the end-entity cert
Using the CA's public key (from the CA certificate), the client verifies the digital signature on the end-entity certificate.
4
Check validity period and revocation status
The client verifies the certificate is within its validity period and checks revocation status via CRL or OCSP.
5
Repeat up the chain
The client repeats steps 2–4 for the issuing CA certificate (validated against its issuer) until the Root CA is reached.
6
Verify the Root CA is in the trust store
The client checks whether the Root CA certificate is in the local trust store. If yes, the chain is trusted. If no, validation fails.
H
Basic Constraints — The CA Flag
The Basic Constraints extension is one of the most important X.509 certificate extensions. It controls whether a certificate can be used to sign other certificates.
Certificate TypeBasic ConstraintsCan Sign Certificates?
Root CAcA=TRUE, pathLen=noneYes — can sign any CA or end-entity cert
Issuing CA (no sub-CAs)cA=TRUE, pathLen=0Yes — can sign end-entity certs only
Policy CAcA=TRUE, pathLen=1Yes — can sign one level of sub-CAs
End-Entity CertificatecA=FALSENo — cannot sign any certificates
Security Consideration
ESC1 and ESC2 — ADCS misconfigurations involving Basic Constraints
Several critical ADCS attack paths (ESC1, ESC2, ESC9) involve certificate templates that allow requestors to specify a Subject Alternative Name or obtain certificates with elevated privileges. ESC2 specifically involves templates that allow any purpose — including CA certificates — to be issued. Auditing certificate templates for Basic Constraints and EKU misconfigurations is a core ADCS security task covered in the ADCS Architecture course.
I
Enterprise Example: Northstar Manufacturing PKI Design
Northstar Manufacturing has deployed a two-tier PKI hierarchy to support their 2,400-user enterprise. Here is how the hierarchy is structured and why each design decision was made:
Northstar Root CA
Offline Windows Server 2022 VM. Stored powered-off in a locked server cabinet. 4096-bit RSA key. SHA-256 signature. 20-year validity. Certificate distributed to all domain machines via Group Policy. Only brought online to sign Issuing CA certificates or CRLs.
Northstar Issuing CA
Online Windows Server 2022 with ADCS role. 2048-bit RSA key. SHA-256 signature. 10-year validity. Signed by Root CA. Publishes CRLs to a highly available HTTP CDP. Hosts OCSP responder. Issues all end-entity certificates via certificate templates.
Certificate Templates
Separate templates for: Web Server (2-year), User (1-year), Workstation (2-year), Code Signing (1-year), OCSP Responder (1-year). Each template has specific EKU, key usage, and enrollment permissions configured.
Trust Store Distribution
Root CA certificate distributed via Group Policy to all domain-joined Windows machines. Also imported into Java cacerts on application servers and added to the Linux CA bundle on build servers.
J
PKI Engineer Notes
Production Note
Verify the AIA extension before deploying certificates
The Authority Information Access (AIA) extension in every certificate tells clients where to download the issuing CA certificate and check revocation status. If the AIA URLs are unreachable — wrong hostname, firewall blocking, or HTTP not HTTPS — clients cannot build the chain and revocation checking fails. Always test AIA URLs from outside the PKI server before deploying certificates to production.
Common Mistake
Issuing CA certificate not included in the TLS handshake
A common TLS misconfiguration: the server sends only its end-entity certificate in the TLS handshake, not the full chain including the Issuing CA certificate. Clients that do not have the Issuing CA certificate cached will fail to build the chain. Always configure your web server (IIS, nginx, Apache) to send the full certificate chain. Use SSL Labs or certutil to verify chain completeness.
Security Consideration
Path length constraints prevent unauthorized sub-CA creation
Set pathLenConstraint=0 on Issuing CA certificates to prevent them from creating sub-CAs. Without this constraint, a compromised Issuing CA could sign a new CA certificate, creating an unauthorized sub-CA that can issue trusted certificates. In ADCS, this is configured in the CA properties during installation. Audit existing CA certificates with certutil -dump to verify pathLenConstraint is set correctly.
Key Concept
Cross-certification and bridge CAs
When two separate PKI hierarchies need to trust each other — for example, after a merger or for a government-to-contractor trust relationship — cross-certification is used. Each Root CA signs a certificate for the other Root CA, establishing bidirectional trust. A Bridge CA is a specialized CA that acts as a hub for cross-certification between multiple hierarchies. These advanced topics are covered in the ADCS Architecture course.
Key Terms Glossary
Trust Hierarchy
The chain of certificate authorities from a trusted Root CA down through Subordinate CAs to end-entity certificates. Trust flows from the root downward.
Root CA
The top-level Certificate Authority in a PKI hierarchy. Its certificate is self-signed and is the ultimate trust anchor. Must be kept offline in enterprise deployments.
Self-Signed Certificate
A certificate signed by its own private key rather than by a higher CA. Root CA certificates are self-signed. Self-signed certificates are only trusted if explicitly installed in a trust store.
Subordinate CA / Issuing CA / Intermediate CA
A Certificate Authority whose certificate is signed by a higher CA (Root or Policy CA). Handles day-to-day certificate issuance. Also called an Issuing CA or Intermediate CA.
Policy CA
An optional intermediate CA between the Root CA and Issuing CAs. Used to separate certificate policies or organizational units. Adds an extra layer of protection for the Root CA.
End-Entity Certificate / Leaf Certificate
A certificate issued to a specific subject (server, user, device). Cannot sign other certificates (Basic Constraints: cA=FALSE). The "leaf" of the certificate tree.
Certificate Chain / Certification Path
The ordered sequence of certificates from an end-entity certificate up to a trusted Root CA. Each certificate is signed by the one above it in the chain.
Trust Store
The collection of trusted Root CA certificates maintained by an operating system or application. Windows: Trusted Root Certification Authorities store. Browsers maintain their own trust stores.
Basic Constraints
An X.509 certificate extension that indicates whether the certificate is a CA certificate (cA=TRUE) or an end-entity certificate (cA=FALSE). Critical for preventing unauthorized certificate issuance.
Path Length Constraint
An optional field in the Basic Constraints extension that limits how many additional CA certificates may appear below this CA in the chain. Prevents unauthorized sub-CA creation.
AIA (Authority Information Access)
An X.509 extension that provides URLs where clients can download the issuing CA certificate and check certificate revocation status (OCSP). Critical for chain building.
Cross-Certification
A trust relationship between two separate PKI hierarchies, established by each Root CA signing a certificate for the other. Allows certificates from one hierarchy to be trusted by the other.
Knowledge Check
Question 1 of 5
Why is the Root CA certificate considered self-signed?
Question 2 of 5
Why do enterprise PKI designs keep the Root CA offline?
Question 3 of 5
A client is validating a TLS certificate for webserver.northstar.local. The certificate was issued by Northstar Issuing CA, whose certificate was signed by Northstar Root CA. What is the correct certification path?
Question 4 of 5
An administrator deploys a new internal Root CA. Users report that browsers show certificate errors for all internal sites. What is the most likely cause?
Question 5 of 5
What is the key difference between an Issuing CA certificate and an end-entity (leaf) certificate?
Lesson Completion
Downloads
PKI Trust Hierarchy Quick Reference
Two-tier and three-tier hierarchy diagrams, certification path validation steps, and trust store distribution checklist.
Coming Soon
Module 1 Lessons
Your Progress
Not yet complete
3 of 18 lessons complete (est.)