CA hierarchy design and planning
Trust Architecture Playbook: Issuance pillar
Why CA hierarchy design matters
Every X.509 certificate derives its meaning from a chain of trust that terminates at a root CA. Relying parties validate that chain every time they encounter a certificate. A well-designed CA hierarchy makes that chain predictable, auditable, and operationally manageable. A poorly-designed one creates technical debt that compounds with every certificate issued.
The most common CA hierarchy problems in enterprise environments are not cryptographic failures, they are operational and architectural ones: roots over-shared across too many use cases, intermediates that cannot be revoked without widespread disruption, key material stored without adequate controls, and hierarchies that were never formally documented. These gaps are rarely visible until a CA distrust event, a key compromise, or a compliance audit forces a full accounting.
Core hierarchy concepts
A standard enterprise CA hierarchy consists of three tiers:
CA tier | Role | Typical state |
|---|---|---|
Root CA | The trust anchor. The root certificate is self-signed and embedded in trust stores to establish trust. | Kept offline; used only to sign intermediate CA certificates. |
Intermediate CA | Signed by the root, or by a parent intermediate in deeper hierarchies. Sits between the root and the end-entity certificates it ultimately authorizes. In larger hierarchies, an intermediate may be designated as a policy CA — one that imposes name constraints, policy OIDs, or other structural constraints on the issuing CAs beneath it, rather than issuing end-entity certificates directly. | May be offline (policy CA) or online (issuing CA). Not all designs require a dedicated intermediate CA tier. |
Issuing CA | Issues end-entity certificates (for example, server, user, device, or code signing). | Always online; should be scoped to specific use cases. |
Most enterprise environments start with a two-tier hierarchy — root plus one or more issuing CAs — and add a policy CA layer only when the hierarchy is large enough that structural constraints need to be enforced at an intermediate level.
When designing your subordinate CA structure, start by identifying the certificate populations that need different controls, not by deciding how many CAs to create. Create a separate intermediate CA only when the separation provides real operational value. Good reasons include:
Different relying parties or trust stores
Different certificate policies, regulatory requirements, or audit boundaries
Different key algorithms or migration timelines
Different revocation availability requirements
Need for name constraints or path length constraints
Note
Best practice
Avoid creating intermediates simply to mirror your organization chart. Organizational ownership is better handled through business units, certificate profiles, and approval workflows in Trust Lifecycle Manager.
Key design decisions
Before provisioning any CA infrastructure, document your answers to the following questions. These decisions shape your hierarchy for years.
A single root CA is appropriate for most enterprise environments. Multiple roots are warranted when you need to separate trust domains entirely: for example, a production root and a non-production root, or separate roots for different regulatory environments. Do not create multiple roots only to separate certificate use cases; use dedicated intermediate CAs for that instead.
Different certificate use cases (for example, TLS, email, code signing, device authentication, workload identity) have different validity requirements, naming conventions, and policy constraints. In Trust Lifecycle Manager, use case separation is handled at two levels:
Certificate profiles are usually the primary mechanism. A single issuing CA can serve multiple use cases through different profiles, each enforcing its own certificate properties, enrollment method, and authentication requirements.
Dedicated issuing CAs provide structural separation when profiles alone are insufficient, for example when use cases have different trust boundaries, relying parties, revocation requirements, or audit obligations.
Start with profiles, and introduce a dedicated issuing CA only when the use case genuinely requires a structural boundary.
Root CA keys require the strongest protection. Hardware security modules (HSMs) provide tamper-resistant key storage and are the standard for CA key material in regulated or high-assurance environments. The choice of HSM model or service affects both security posture and PQC readiness. Key storage follows two patterns based on CA role:
Root and policy CA keys: Store in offline HSMs. Bring them online only for controlled CA signing operations, such as creating, renewing, or replacing subordinate CAs.
Issuing CA keys: Store in online HSMs that support routine certificate issuance.
Define your cryptographic baseline before creating any production CAs. Align the baseline to current NIST guidance while balancing security requirements, platform compatibility, and operational constraints. Recommended starting points:
Signature algorithm: Prefer ECDSA for new private CA hierarchies, particularly when smaller key and signature sizes are operationally beneficial. Use RSA where broad compatibility is required or ECDSA support cannot be confirmed. Treat EdDSA as NIST-approved, but verify product and relying-party compatibility before adopting it.
Key sizes: For ECDSA, use P-384 for CA certificates and P-256 or P-384 for end-entity certificates. For RSA, use RSA 4096 for CA certificates and RSA 2048 or stronger for end-entity certificates. EdDSA key sizes are fixed by algorithm variant, such as Ed25519 or Ed448, and do not require a separate key-size selection.
Validity periods: Set CA and end-entity validity based on risk, policy, and migration agility. Avoid CA validity periods that extend significantly beyond planned cryptographic transition timelines.
Hash algorithms: Use SHA-256 or stronger. Use SHA-384 or SHA-512 for higher-assurance or longer-lived CA certificates where supported. Do not use SHA-1 for new certificate signatures.
Crypto-agility: Document the organization's current cryptographic baseline and a roadmap for responding to algorithm deprecation, changing compliance requirements, and post-quantum migration needs. For PQC pilots, align to NIST-standardized ML-DSA and SLH-DSA where supported by DigiCert Private CA and relying parties.
A mature PKI program is supported by documented policies that establish accountability, define operational practices, and provide the evidentiary basis for internal and third-party audits. The following documents are standard in enterprise CA governance:
Certificate Policy (CP): The authoritative statement of what your PKI does: what certificates it issues, for whom, under what conditions, and what obligations apply to subscribers and relying parties.
Certificate Practice Statement (CPS): How the CA implements the CP operationally, including physical security, personnel controls, key management, issuance procedures, revocation handling, audit practices, and change control.
Key management policy: HSM use, key generation, storage, backup, access controls, and key destruction requirements.
Revocation policy: Conditions for revocation, response timelines, CRL/OCSP publication commitments, and communication procedures.
For organizations using DigiCert Private CA, DigiCert publishes a CP/CPS covering operational and technical practices that is sufficient for most use cases. Mid-to-large enterprises or those with specific regulatory, contractual, or audit obligations may need to develop their own policy documentation. Custom policies must not conflict with the operational practices defined in DigiCert's published CP/CPS.
Note
DigiCert offers services to help with developing custom CA policy documentation. Contact your account representative with questions or to discuss whether a custom policy is appropriate for your organization.
Example hierarchy diagrams
The following diagrams illustrate the most widely used CA hierarchy patterns for private PKI deployments.
A two-tier hierarchy consists of a root CA and one or more issuing CAs directly beneath it. This is the simplest and most common enterprise PKI design, and works well when issuing CAs can be separated by use case, environment, or risk level.
A three-tier hierarchy adds a policy CA layer between the root CA and the issuing CAs. Use this pattern when the hierarchy requires structural constraints or distinct policy or audit boundaries across groups of issuing CAs.
CA hierarchy and Trust Lifecycle Manager
Trust Lifecycle Manager sits above your CA infrastructure as a unified management and governance layer.
Trust components
Component | Description |
|---|---|
Trust anchors |
|
Issuing CAs |
|
Profiles |
|
Unified private and public trust
While Trust Lifecycle Manager provides a unified management plane, private trust and public trust have different design constraints that affect how you plan and configure each:
Private trust is flexible and fully under enterprise control. You define the hierarchy, cryptography, and revocation infrastructure. That flexibility is valuable but requires careful planning and ongoing operational commitment.
Public trust is constrained by CA/Browser Forum requirements, browser root programs, and CA vendor product and chain rules. Trust Lifecycle Manager can govern enrollment and lifecycle management for public certificates, but it cannot override the chain, validity, or validation requirements that public trust imposes.
Understanding these differences helps you plan each model appropriately. However, both types of trust are ultimately managed through the same Trust Lifecycle Manager workflows, profiles, and inventory.