CA source and trust anchor governance
Trust Architecture Playbook: Governance pillar
CA source registry
DigiCert® Trust Lifecycle Manager can manage certificates from multiple CA sources under a unified governance model. That flexibility is valuable, but only if every CA source is governed before it is used. The CA source registry is the inventory of every CA approved to issue certificates into the estate, with ownership and trust chain documented for each one.
Registry field | Required content |
|---|---|
CA source name | Friendly name and system identifier. |
Trust type | Public, private, internal, partner, cloud private, lab, decommissioning, or exception. |
Approved use cases | Certificate types, business units, environments, domains/namespaces, and criticality tiers allowed. |
Owner | Central PKI owner, platform owner, CA operator, and vendor relationship owner where applicable. |
Connector/integration | Connector type, sensor requirement, credential owner, network path, and operational prerequisites. |
Chain and trust anchor | Root/intermediate identifiers, chain files, trust store distribution, path building expectations. |
Revocation/status | CRL/OCSP availability, publishing cadence, monitoring, and emergency revocation process. |
Policy mapping | CP/CPS or internal policy reference and any OID mapping. |
Evidence | Audit logs, connector logs, issuance records, validation records, and exception records. |
Exit plan | Migration, decommission, or contingency plan if CA source becomes unavailable, distrusted, or no longer approved. |
Example CA source registry entry
A well-designed CA source registry is the control that prevents a technically supported CA integration from becoming an approved issuing authority by default. The following example shows the typical level of detail expected for a governed CA source.
Registry field | Example entry |
|---|---|
CA source name | DigiCert Private CA - Enterprise Server Issuing CA. |
Trust type | Private, internal enterprise, production. |
Approved use cases | Private TLS server authentication for approved production and non-production enterprise server profiles. |
Owner | Central PKI/security; platform operations delegated by business unit. |
Connector/integration | On-premises DigiCert Private CA instance with managing sensor, CA connector, and approved service credential and network path. |
Chain and trust anchor | Enterprise root and enterprise server intermediate registered in Trust Lifecycle Manager. |
Revocation/status | CRL and/or OCSP behavior documented; emergency revocation path tested for Tier 0/1 populations. |
Policy mapping | Enterprise PKI Policy and private TLS certificate profile standard. |
Evidence | Issuance records,Trust Lifecycle Manager audit logs, connector (sensor) logs, owner metadata, deployment validation, and exception records. |
Exit plan | Migrate active profiles and remove trust anchor from managed trust stores before CA retirement. |
Public-trust CA governance
Public-trust CA governance must account for validation, monitoring, validity changes, and security events, among other things. The CA/Browser Forum Baseline Requirements describe an integrated set of requirements for issuance and management of publicly trusted TLS server certificates. Governance should explicitly scope those obligations to public TLS rather than accidentally applying the entire public Web PKI model to private PKI or, worse, failing to apply it where it does apply.
Maintain an approved public CA list and restrict public TLS profiles to approved CA sources.
Centralize domain and subdomain authority for public domains; do not allow business units to independently prove control without governance oversight.
Monitor CT logs for every primary domain and route discoveries into triage queues.
Track public validity reductions and ensure automation readiness for shorter renewal cycles.
Document emergency replacement process for CA distrust, mis-issuance, key compromise, or domain validation failure.
Retain audit evidence that connects domain approval, profile, requester identity, issuance event, deployment target, and validation result.
Private-trust CA governance
Private CA governance is where many enterprise programs are weakest because there is no browser root program forcing discipline. That absence of external enforcement should not be mistaken for lower risk. Private CAs often issue credentials used for privileged access, workload identity, internal TLS, device authentication, and administrative control planes. Private CA governance must account for CA lifecycle, key protection, role separation, and issuance oversight, among other things.
Maintain a root and intermediate CA inventory with owner, purpose, policy, validity, key protection, issuing scope, and status; forbid unregistered private CAs in production trust stores.
Require root and intermediate keys to be generated and stored in an HSM (or equivalent KMS), with root keys kept offline except to sign new intermediate CA certificates; for self-managed CA deployments, require key ceremony procedures to be documented and witnessed.
Define backup and recovery procedures for root and intermediate keys, including who can authorize recovery and how recovery is tested.
Require CA source approval before creating profiles tied to that CA; separate CA operation from profile approval where practical.
Define revocation and status service availability requirements for relying applications.
Require a decommission plan for legacy CAs, including trust store cleanup and certificate migration.
Review private CA issuance for unexpected EKUs, broad SANs, weak algorithms, duplicate names, and policy drift.
CA onboarding checklist
Business justification, approved use cases, and scalability for future use cases documented.
Trust domain and relying-party population defined.
CA source owner, platform owner, and policy owner assigned.
Root/intermediate chain, validity, algorithms, and revocation/status endpoints documented.
Connector prerequisites, sensor requirements, service credentials, and network access approved.
Profiles and business units defined before issuance begins.
Audit log visibility and evidence retention confirmed.
Emergency revocation and CA outage procedures published.
Exit plan and migration path defined before the CA is approved for production use.