Building a hierarchy in DigiCert Private CA
Trust Architecture Playbook: Issuance pillar
Once you have chosen your deployment model and documented your hierarchy design, you are ready to build your CA infrastructure. This section covers the key configuration areas for DigiCert® Private CA in the order you should address them.
Initial setup
Before creating any CAs, configure your HSM integration and account-wide defaults. These are one-time configurations that apply across your entire hierarchy.
HSMs are the recommended storage mechanism for CA private keys, providing tamper-resistant storage, hardware-enforced access controls, and audit logging. In regulated environments, HSM use for CA keys is often mandatory. DigiCert Private CA supports various HSM options, including:
Crypto4A: FIPS-validated HSM that supports classical algorithms (RSA, ECC, EdDSA) and post-quantum cryptography (ML-DSA and SLH-DSA).
Thales Luna: PKCS#11-based HSM that supports common enterprise CA key storage patterns. Luna Network HSMs are commonly used for online issuing CAs, while Luna USB HSMs may be used for offline root CA key storage. Newer firmware versions also support PQC.
Thales DPoD: Cloud-based HSM service available for North America-hosted environments. Used for online CA deployments only.
For customer-hosted (on-premises) Private CA:
Configure HSM integration before creating any CAs. Migrating externally generated CA keys into an HSM later may not meet operational or compliance requirements and can complicate key provenance and auditability.
Where FIPS validation is a compliance requirement, FIPS 140 Level 2 is the typical minimum baseline, while Level 3 is commonly recommended for high-assurance or regulated environments. Confirm the required level with your compliance framework before finalizing your HSM selection.
Suggerimento
Best practices
Use offline HSMs for root and policy CA keys, and online HSMs for issuing CA keys. Include adequate HSM high availability, backup, and recovery in the design. At minimum, use separate HSM partitions for root and issuing CA keys to provide isolation.
DigiCert Private CA supports account-wide defaults for OCSP, CRL, AIA (Authority Information Access), and certificate policy OIDs. Setting these before creating your first CA ensures that revocation and chain-building information is consistent across all certificates issued from your hierarchy, and reduces per-CA configuration work.
These defaults feed directly into the revocation infrastructure you will configure for each issuing CA. Establishing them here first means your CRL distribution point and OCSP responder URLs are pre-populated when you create each CA, reducing the risk of inconsistent or missing revocation endpoints, which can cause certificate validation failures in environments with strict revocation checking. See Configuring revocation infrastructure.
Creating your CA hierarchy
To build your private-trust issuance hierarchy, create root and intermediate CAs in DigiCert Private CA. To standardize configuration across your hierarchy, use CA certificate templates to define cryptographic settings, validity periods, and policy extensions for each CA tier.
Root CAs provide the top-level trust anchor for your issuance hierarchy. Configuration decisions include:
HSM provider and partition for storing the root key
Common name (use something descriptive and stable; avoid product names or version numbers that could become inaccurate)
Validity period (typically 10 to 15 years) and path length constraint
For customer-hosted (on-premises) Private CA, plan and conduct a formal root key ceremony before provisioning. Key elements include:
Multi-person control: Define which roles must be present to authorize root CA signing operations (for example, PKI owner, security officer, CA operators, and a witness). Where supported by the HSM, use M-of-N or equivalent controls so no single individual can activate or use the root CA key alone.
Controlled environment: Offline root CA designs require an offline DigiCert Private CA instance and offline HSM, with a separate online instance for issuing CAs. Operate the offline root CA instance in a physically secure, air-gapped environment, and perform root CA key generation and signing operations only in that environment. Initialize and verify the HSM before generating any key material.
Documentation and artifacts: Record all steps, participants, and HSM details. Store the signed ceremony record and HSM backup tokens in geographically separate, physically secured offline locations.
Avviso
Root key ceremonies apply to customer-hosted deployments generating a new root CA key. For DigiCert-hosted Private CA, DigiCert manages root key generation internally.
Intermediate CAs are created under the root. If your hierarchy design includes a policy CA tier, create those intermediates first and use them as the signing CA for your issuing intermediates rather than signing directly from the root. For each intermediate, configure:
The signing CA (root or intermediate)
A use-case-specific name (for example, Internal TLS, Device Identity, or Code Signing)
Validity period (typically 10 years for issuing CAs; shorter periods require more frequent CA rekeying but may be appropriate based on policy, risk, or cryptographic transition requirements)
CRL distribution points and OCSP responder URLs (configured and accessible before the CA issues any end-entity certificates)
Suggerimento
Best practice
Keep your root CA offline. Only bring it online to sign new intermediate CA certificates or perform root recertification. Intermediate CAs should be the only CAs actively issuing end-entity certificates.
HSM backup, key escrow, and CA recovery
A CA whose key material cannot be recovered after an HSM failure is effectively destroyed; all its certificates become unverifiable and the PKI must be rebuilt from scratch. If you manage your own HSM, plan for backup and recovery before your CA goes into production.
Before placing the CA into production:
Configure backup tokens during the initial key ceremony, before any CA keys are generated.
Store tokens offline in geographically separate, physically secured locations. Maintain at least two copies in separate sites.
Test restore procedures before your CA goes live. An untested backup is not a backup.
If your compliance framework requires key escrow, define the custodians, access procedures, and audit requirements before generating any key material.
Define and test recovery procedures for the following scenarios:
HSM failure: Restore CA key material from backup tokens to a replacement HSM and validate issuance before declaring recovery complete.
Revocation service failure: Ensure CRL and OCSP services can be restored within your SLA. Consider a hot standby OCSP responder for high-availability environments.
Site failure (Active/Passive): Test the procedure for promoting the passive instance, including HSM activation and any DNS or load balancer changes required.
Suggerimento
Best practice
Document recovery runbooks and test them at least annually. Include drills that simulate issuing CA compromise, requiring revocation of the CA and issuance from a replacement.
Configuring revocation infrastructure
Revocation allows relying parties to verify that a certificate has not been revoked. DigiCert Private CA supports two mechanisms: Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP). Configure both before any issuing CA begins production issuance.
A CRL is a signed, periodically published list of revoked certificate serial numbers. Key configuration decisions:
Scope: decide whether the CRL covers all certificate types or only end-entity certificates. Consider a separate Authority Revocation List (ARL) for subordinate CA certificates.
Validity and freshness: set a validity period and regeneration schedule that reflects your revocation latency requirements. Relying parties cache CRLs for their full validity period, so shorter validity improves freshness at the cost of increased distribution point load.
Use HTTP for CRL distribution points to avoid the certificate validation dependency cycles and performance overhead that can occur with HTTPS-hosted revocation endpoints.
For DigiCert-hosted Private CA, DigiCert publishes CRLs to DigiCert ONE endpoints on your behalf. Your responsibilities are:
Configure the default CRL distribution point URLs to embed in issued certificates. To use a custom CDP URL, first add the domain in DigiCert Private CA using the Domains function, then coordinate with DigiCert to complete the required CDN configuration. Contact your account representative to initiate this process.
Ensure relying parties in your environment can reach the configured CRL endpoints. If your environment uses outbound allowlists, allow by FQDN instead of IP as DigiCert ONE endpoints are delivered through CDNs and underlying IP addresses may change. To find the applicable CRL FQDN for your environment, see Platform IP addresses and URLs.
For customer-hosted (on-premises) Private CA, you are responsible for operating your own CRL distribution points. Key considerations:
Host CRL distribution points on highly available infrastructure. An unreachable endpoint causes validation failures where hard-fail revocation checking is enforced.
Revocation endpoints must be accessible to all relying parties that validate certificates from your hierarchy.
Configure and verify CRL distribution points before any issuing CA enters production. Certificates issued without a valid CDP extension may fail validation where strict revocation checking is enforced.
OCSP provides more timely revocation status information than CRLs and is commonly used for interactive TLS validation, where clients require timely revocation information without downloading a full revocation list. Key configuration guidance:
OCSP responses are cryptographically signed by the issuing CA or a delegated OCSP responder certificate and cached by relying parties for the duration of the response validity period. Set response validity to balance freshness against responder load: shorter validity improves revocation latency but increases request volume.
Enable OCSP stapling on TLS servers where supported to reduce responder load and improve validation performance. Stapling may not be suitable for OCSP configurations that require nonce extensions in responses.
For DigiCert-hosted Private CA, DigiCert operates OCSP responders on your behalf. Your responsibilities are:
Configure the default OCSP responder URLs to embed in issued certificates. To use a custom AIA URL, first add the domain in DigiCert Private CA using the Domains function, then coordinate with DigiCert to complete the required CDN configuration. Contact your account representative to initiate this process.
Ensure relying parties in your environment can reach the configured OCSP endpoints. If your environment uses outbound allowlists, allow by FQDN instead of IP as DigiCert ONE endpoints are delivered through CDNs and underlying IP addresses may change. To find the applicable OCSP FQDN for your environment, see Platform IP addresses and URLs.
For customer-hosted (on-premises) Private CA, you are responsible for deploying and maintaining your own OCSP responders. Key considerations:
Configure OCSP responder URLs as part of your deployment setup and verify they're accessible before production issuance begins.
Deploy responders behind a load balancer for high availability.
Consider a hot standby responder for environments with strict availability requirements.
Configure OCSP responder URLs before any issuing CA enters production. Certificates issued without a valid AIA extension may fail validation where strict revocation checking is enforced.
Importante
Currently, post-quantum (PQC) certificates only support CRL-based revocation in DigiCert Private CA. OCSP-based revocation of PQC certificates is not yet supported.
High availability for customer-hosted Private CA
A single customer-hosted (on-premises) Private CA instance is a single point of failure. For enhanced fault tolerance, production deployments should implement an Active/Passive model across two geographically separated sites.
Avviso
Active/Passive high availability applies to customer-hosted (on-premises) Private CA only. DigiCert-hosted Private CA is a resilient cloud service managed by DigiCert.
In this model, the active DigiCert Private CA instance handles all issuance and revocation publishing. The passive instance is kept synchronized and promoted on site failure. Key planning requirements include:
HSM key replication: Both sites must have access to the same CA key material. Plan your HSM replication topology and configure backup tokens before generating any CA keys — retroactively adding a second site is more complex and may not be possible depending on your HSM configuration.
Load-balanced enrollment endpoints: Clients should connect to a virtual IP or DNS name, not directly to a specific CA instance, so failover is transparent to enrolling clients.
Shared revocation endpoints: Both sites must publish CRL and OCSP data to the same externally accessible endpoints to ensure revocation checking continues during a failover.
