Prove an AD CS certification authority can be restored—not merely backed up

A CA database copy without its private key, configuration, publication paths, and hardware-security-module procedure may be impossible to use safely. The recovery proof is a functioning isolated CA and validated certificate lifecycle, not a green backup job.

Source fact:

Microsoft’s Windows Server guidance for migrating an Active Directory Certificate Services certification authority identifies the artifacts needed to move and restore CA operation. Its process includes backing up the CA database and private key, exporting CA registry settings, retaining CAPolicy.inf where used, recording enterprise certificate templates, and preserving information needed for certificate-revocation-list publication. It also directs customers using a hardware security module to follow the HSM vendor’s backup procedure.

The guidance describes restoring the CA role and data and then verifying the migrated service. Although framed as migration, those documented dependencies are directly relevant to recovery planning. Successful restoration of files alone does not prove that issuance, revocation, enrollment, chain building, or relying-party access to CRLs works.

Boundary

The exact process depends on supported Windows Server versions, CA type and hierarchy, cryptographic provider, HSM, key exportability, host identity, database state, extensions, publication URLs, Active Directory, web enrollment, NDES, OCSP, and custom integrations. Microsoft guidance and HSM-vendor procedures must be checked for the exact environment. A recovery exercise must not create a second active CA with the same identity in production or publish test revocation data into live paths.

Applicability questions

• Which root, policy, issuing, and subordinate CAs exist, and what order must they recover?
• Where are CA database, private key, registry settings, CAPolicy.inf, templates, HSM material, and passwords protected?
• Which DNS, HTTP, LDAP, file, OCSP, and firewall paths publish or serve chain and revocation information?
• Can recovery operators access media and HSM support without the failed identity infrastructure?
• What issuance pause prevents conflicting database or serial-number state?

DSE recommendation:

Document the CA topology and collect the supported backup set through an approved, protected process. Separate private-key material from ordinary operational backups and test access by authorized recovery roles. Preserve installed role services, configuration, URLs, templates, service identities, HSM dependencies, and recovery order. Establish criteria for declaring the original CA unavailable before an alternate instance can issue.

Restore into an isolated network with production publication blocked. Confirm service start, database integrity, CA identity, key access, extensions, templates, and configuration. Issue a test certificate from a dedicated template, revoke it, publish a test CRL to an isolated endpoint, and validate both the good and revoked states from a representative relying party. Measure the process and correct undocumented dependencies before destroying the exercise environment securely.

Verification and evidence

Keep backup logs, media inventory, key-custody approvals, configuration exports, HSM procedure and test evidence, restore transcript, CA identity checks, issued and revoked test certificates, CRL validation, relying-party results, recovery time, and improvements. Do not place private keys or passwords in the evidence package. Repeat after CA renewal, HSM, OS, hierarchy, template, or publication-path changes.

Official references

• Microsoft Learn: Migrate a certification authority