Private CA Operations Guide: Roots, Ceremonies, HSMs

A private certificate authority is a privileged system whose signing keys can mint identities for every server, workload, device and user that trusts it, yet many organisations run one that was built in an afternoon and never formally operated. Internal PKI underpins mTLS between services, Wi-Fi and VPN authentication, smart card logon, device management and code signing, so a compromised or mismanaged CA is an identity compromise at scale. This guide covers the operations side of a private CA: the policy documents, the root key ceremony, HSM custody and role separation, issuance controls, revocation publishing, renewal and compromise recovery. It assumes you have chosen a hierarchy; for the design of tiers and trust models see the Enterprise PKI Design and CA Hierarchy Guide. It is written for PKI owners, infrastructure and identity engineers, and the PAM teams who must treat CA administrators as privileged users.

Key takeaways

The root is the identity of the whole estate. Microsoft's AD CS guidance states that if the root CA is compromised, every CA beneath it and every certificate it issued is considered compromised, which is why roots stay offline.
Write the CP and CPS before the ceremony. RFC 3647 gives a nine-part framework; the Certificate Policy says what must be done and the Certification Practice Statement says how your CA does it.
Keys belong in validated hardware. Generate and keep root and issuing CA keys in an HSM validated to FIPS 140-3 (or FIPS 140-2 while still valid), installed and configured before the CA is built.
CA operators are privileged identities. Split CA administrator, certificate manager, auditor and HSM custodian roles, require multi-person control for key operations, and log every action to a place the operators cannot alter.
Revocation publishing is an availability dependency. An expired CRL breaks validation for every relying party, so CRL periods, overlap and publication monitoring need the same care as the keys.

Policy first: CP, CPS and certificate profiles

RFC 3647 (Informational, obsoleting RFC 2527) defines the difference clearly. A Certificate Policy (CP) is a named set of rules stating what participants must do, and can apply across several CAs. A Certification Practice Statement (CPS) describes how a specific CA implements procedures and controls to meet those requirements. A private CA does not need the length of a public CA's documents, but it does need the same structure, because the structure forces the decisions that are otherwise made ad hoc.

RFC 3647 component	Decisions a private CA must record
1 Introduction	Which CAs, which certificate types, which relying parties, policy OIDs
2 Publication and Repository	Where CA certificates, CRLs and the CPS are published, and the HTTP URLs embedded in certificates
3 Identification and Authentication	How each subscriber type proves who it is: directory account, device management enrolment, workload identity, manual approval
4 Certificate Life-Cycle Operational Requirements	Request, approval, issuance, renewal, rekey, revocation reasons and time limits
5 Facilities, Management and Operational Controls	Physical security of the offline root, trusted roles, multi-person control, audit logging, archive, key changeover, compromise and disaster recovery
6 Technical Security Controls	Key generation and installation, private key protection and cryptographic module controls, activation data, computer and network security
7 Certificate, CRL and OCSP Profile	Extensions, key sizes, signature algorithms, validity periods, CRL and OCSP settings
8 Compliance Audit	Who reviews the CA, how often, and against what
9 Other Business and Legal Matters	Ownership, liability limits for internal use, change control for the documents

Profile rules that matter for CA certificates

basicConstraints: RFC 5280 requires conforming CAs to include it in CA certificates and to mark it critical. Set pathLenConstraint to stop a compromised issuing CA creating further CAs (0 on issuing CAs); RFC 5280 forbids pathLenConstraint unless cA is asserted.
keyUsage: CA certificates carry keyCertSign and cRLSign; if keyCertSign is set, the cA bit must also be set, and RFC 5280 says keyUsage should be marked critical.
nameConstraints: RFC 5280 says the extension must be used only in CA certificates and that conforming CAs must mark it critical. Constraining an issuing CA to your internal DNS suffixes limits what a compromise can impersonate.
Policy OIDs: assert your own policy OID from the CP so relying parties and auditors can tell which rules a certificate was issued under. Microsoft AD CS sets this through the [PolicyStatementExtension] section of CAPolicy.inf, with an OID, notice text and a CPS URL.

Root key ceremony

The key ceremony is the scripted, witnessed event in which the root key pair is generated, the root certificate is self-signed and the first issuing CA certificates are signed. Its purpose is evidence: anyone reviewing the PKI later should be able to see that the key was generated inside the HSM, was never exported in clear, and that every step was performed as written. The steps below are a practice outline drawn from the RFC 3647 control areas, not a regulatory requirement for private CAs.

Prepare the script: every command, expected output and checkpoint, approved in advance under change control, with the CAPolicy.inf or equivalent configuration attached.
Assign roles: ceremony administrator (reads the script), operators (run commands), HSM custodians (hold smart cards or key shares for the security officer and crypto officer roles), witness or internal auditor, and a recorder. No single person holds enough activation data to use the key alone.
Prepare the environment: a clean, air-gapped workstation built from known media, the HSM with its tamper evidence verified, sealed tamper-evident bags, and video recording where policy requires it.
Generate and certify: initialise the HSM security world or partition, generate the root key inside it, create the self-signed root, export only the public certificate, then sign the issuing CA requests brought in on removable media.
Back up under split control: create HSM-encrypted key backups and split the activation data across custodians, then store backups in separate secure locations.
Close out: sign the ceremony log, record serial numbers of bags and devices, power down the root, and store it in a safe or vault with access logging.

Microsoft notes that HSMs must be installed and configured before any CA that needs HSM-stored keys is set up, so the HSM vendor's initialisation steps belong inside the script, not before it. See the HSM Deployment and Operations Guide.

Key custody and the cryptographic module

FIPS 140-3 (final, 22 March 2019, superseding FIPS 140-2) defines four increasing levels of security for cryptographic modules. For a private CA the questions are which level the module is validated at, where its key backups live, and who can activate it.

Custody option	Strengths	Weaknesses	Typical use
Software key on the CA server	No hardware cost	Key can be copied by any administrator or attacker with system access; no tamper evidence	Labs only
USB or PCIe HSM attached to an offline root	Key never leaves hardware; root stays air-gapped	Physical logistics for every ceremony; device ageing	Offline roots
Network HSM shared by issuing CAs	Centralised management; one HSM can serve several CAs, as Microsoft notes	Network path and HSM admin roles become part of the CA's attack surface	Online issuing CAs in data centres
Cloud HSM or managed private CA service	Provider operates hardware and availability; API audit logs	Trust in provider and in your cloud IAM; root offline only by policy, not by air gap	Cloud-native estates, workload mTLS

Activation data: cards, PINs or key shares that unlock the key. Store them separately from the HSM and from each other, and record every use.
Key counting: AD CS can count signing operations (EnableKeyCounting in CAPolicy.inf) where the HSM and its provider support it, which helps reconcile signatures against the issuance database.
Algorithms and lifetimes: choose key sizes and validity periods that will remain acceptable for the root's whole life, and follow NIST SP 800-57 Part 1 Rev. 5 for key management practice. Plan for post-quantum migration in the next root generation rather than retrofitting the current one. See the Cryptographic Key Management Guide.

Trusted roles and privileged access to the CA

CA administration is privileged access in its purest form, so it belongs inside the PAM programme rather than beside it.

Role	Can do	Must not also be
CA administrator	Configure the CA, its extensions, CRL settings and templates	Certificate manager or auditor
Certificate manager	Approve, issue and revoke certificates	CA administrator
Auditor	Read and archive audit logs, review issuance	Anyone who can change the CA or its logs
HSM security officer and crypto officer	Initialise HSM, manage partitions, hold activation data	A single person holding all shares
Template or profile owner	Change which identities may request which profiles	An unreviewed member of a broad admin group

Separation: enforce role separation technically where the product allows (AD CS supports role separation between CA administrator and certificate manager), and in process where it does not. This is NIST SP 800-53 AC-5 Separation of Duties.
Admin paths: reach issuing CAs only from privileged access workstations through the PAM platform, with session recording, and treat the CA servers as tier zero alongside domain controllers. See the Privileged Access Management Guide.
Templates are permissions: on AD CS, template access control lists and enrolment flags decide who can obtain authentication certificates. Misconfigured templates are a known escalation path. See the AD CS Security Guide.
Standalone approval: Microsoft notes that auto-issuance on standalone CAs is not recommended because requests are not authenticated. Keep pending-request approval for any standalone CA.

Issuance operations

Authenticate every requester: map each subscriber type to an identification method in CPS section 3: directory identity for users, MDM enrolment for devices, workload identity or an ACME, EST or SCEP flow with a strong challenge for services. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide and the ACME and Automated Certificate Management Guide.
Short-lived where automated: workloads with automated renewal can take certificates measured in days, which limits the cost of a missed revocation.
Constrain subject data: do not let requesters supply arbitrary subject alternative names on authentication profiles; build names from the authenticated identity.
Inventory: NIST SP 1800-16 recommends defined certificate policies, a certificate inventory, continuous monitoring, automation and the ability to migrate rapidly to new certificates and keys. The issuance database is the starting point for that inventory, not the whole of it. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Revocation publishing

Every certificate points relying parties at a CRL distribution point and, where offered, an OCSP responder. If the CRL they fetch has passed its next update time, strict validators reject every certificate from that CA, which turns a missed publication into an outage.

CA tier	Base CRL	Delta CRL	Operational note
Offline root	Long period (often months), re-signed at a scheduled ceremony well before expiry	Usually none	Calendar the re-signing; it is the most common root outage
Issuing CA	Days to a week (Microsoft's CAPolicy.inf example uses one week)	Hours (the example uses four hours)	Automated publication to HTTP; alert before next update
OCSP responder	Signed by a delegated responder certificate	Not applicable	Monitor response freshness and responder certificate expiry

In AD CS these periods are set with CRLPeriod, CRLPeriodUnits, CRLDeltaPeriod and CRLDeltaPeriodUnits in CAPolicy.inf, and can be changed later with certutil -setreg followed by a service restart. Publish over HTTP from highly available endpoints; relying parties outside the domain cannot reach LDAP locations. See the Certificate Revocation Guide.

Renewal, rekey and compromise recovery

Plan root renewal years ahead: a root valid for 20 years must be replaced before subordinate certificates outlive it. In AD CS, RenewalKeyLength and RenewalValidityPeriod govern renewal of root CA certificates; Microsoft notes that the initial key size is fixed at installation.
Rekey rather than renew with the same key when algorithms change or the key has been used for a long period, and distribute the new root to trust stores before it issues anything.
Run old and new in parallel: push the new root through Group Policy, MDM and container base images, verify coverage, then switch issuance.
Compromise of an issuing CA: revoke its certificate at the root (a root ceremony), publish the root CRL, stand up a replacement issuing CA, reissue certificates, and hunt for certificates the attacker may have issued outside the database.
Compromise of the root: no revocation can fix it. Remove the root from every trust store, build a new hierarchy, and replace every certificate. Rehearse this at least as a tabletop, because it shows how many trust stores you do not control.
Roll back safely: keep the previous issuing CA operational for revocation and CRL publishing until all its certificates expire, even after issuance moves.

Detection and measurement

CA audit logs: enable CA auditing for configuration changes, template changes, issuance and revocation, and forward events to the SIEM where CA administrators cannot delete them (AU-9).
Issuance anomalies: certificates with unusual SANs, authentication EKUs on unexpected profiles, requests from new principals, or a signing count that does not match the database. Forged or stolen certificates map to ATT&CK T1649 Steal or Forge Authentication Certificates.
Trust store drift: unexpected roots added to endpoints map to T1553.004 Install Root Certificate.
Publication health: synthetic checks that fetch each CRL and OCSP endpoint and alert well before next update.

Metric	What good looks like
Days of headroom on every published CRL	Never below the agreed threshold; alerts fire long before expiry
Certificates issued without an inventory owner	Zero
CA administrative sessions outside PAM	Zero
Ceremonies performed with full script, witnesses and signed log	100%
Signing operations reconciled to issuance records	All, every review cycle
Time to reissue all certificates from one issuing CA	Measured in a drill and falling

Common failure patterns

The root that was never offline: a root CA joined to the domain and patched online "temporarily", which removes the main control protecting the hierarchy.
Root CRL expiry: the offline root's CRL lapses because nobody calendared the re-signing, and validation fails across the estate on the same day.
Software keys on issuing CAs: CA private keys stored by the operating system and copied with every server backup.
One person holds everything: the PKI engineer who is CA administrator, certificate manager, HSM officer and the only one who knows the procedure.
Unconstrained issuing CAs: no pathLenConstraint or name constraints, so a compromised issuing CA can create subordinate CAs or certificates for any name.
No CPS, no evidence: nobody can show how a key was generated, so after an incident the whole hierarchy must be assumed untrustworthy.

Framework mapping

Framework	Reference	Private CA practice
NIST SP 800-53 Rev. 5	SC-17 Public Key Infrastructure Certificates	Issue certificates under an approved certificate policy
NIST SP 800-53 Rev. 5	SC-12, SC-12(1), SC-13	Key generation, custody, backup and availability; approved cryptography
NIST SP 800-53 Rev. 5	AC-5, PE-3, AU-9	Role separation, physical protection of the offline root, protected audit logs
NIST SP 800-53 Rev. 5	IA-5(2) Public Key-based Authentication	Relying parties validate paths and revocation status
NIST CSF 2.0	GV.PO-01, PR.AA-01, ID.AM-08	Documented policy, managed credentials, lifecycle management of the CA and its certificates
MITRE ATT&CK v20	T1649, T1553.004	Detect forged certificates and rogue roots

Practitioner checklist

Publish a CP and CPS following the RFC 3647 outline, with policy OIDs asserted in issued certificates.
Keep the root offline, in an HSM, physically secured, and used only in scripted, witnessed ceremonies with signed logs.
Hold issuing CA keys in a validated HSM or managed CA service, never as software keys.
Separate CA administrator, certificate manager, auditor and HSM custodian roles, with multi-person control for key operations.
Route all CA administration through PAM from privileged access workstations, and treat CA servers as tier zero.
Set basicConstraints with pathLenConstraint and name constraints on issuing CAs, both critical.
Calendar root CRL re-signing and monitor every CRL and OCSP endpoint for freshness.
Reconcile signing operations against the issuance database and forward CA audit events to the SIEM.
Rehearse issuing CA replacement and root compromise, and keep a standby plan for new trust anchors.

Private CA Design and Operations Guide: Offline Roots, Key Ceremonies and Safe Issuance