Skip to content
WindowsDeep Dive Published Updated 9 min readViews unavailable

Windows AD CS Certification Authority Backup and Migration Runbook

Protect Windows AD CS continuity by backing up the CA key, database, registry, CAPolicy.inf, templates, and validating CRL and AIA paths after migration.

An Active Directory Certificate Services (AD CS) Certification Authority is more than a Windows role installed on a server. Its identity, private key, database, configuration, publication paths, and template assignments in an enterprise deployment collectively determine whether it can continue issuing and revoking certificates. A migration that restores only the database can appear successful while clients later fail to validate certificates because the CA key, registry configuration, templates, CRL Distribution Point (CDP), or Authority Information Access (AIA) locations were omitted.

This runbook is for planning and validating a CA backup, recovery, or server migration. It is not a substitute for the current Microsoft procedure for the specific Windows Server version, CA type, key provider, and topology. A hardware security module (HSM) requires its vendor’s key backup and restore process. A clustered CA has additional sequencing constraints. Treat CA private-key material as high-impact cryptographic data: protect it with least privilege, encrypted storage, access logging, and an independently tested recovery procedure.

Classify the CA before choosing a procedure

Record whether the CA is enterprise or standalone, root or subordinate, software-key or HSM-backed, clustered or standalone, and which operating system versions and role services are involved. Capture the CA common name, certificate thumbprint and validity, cryptographic provider, key algorithm and length, database and log paths, service account and service state, publication URLs, templates assigned, and dependent enrollment and revocation workflows. Identify the owning team and the business services that rely on certificates from this CA.

Do not treat the CA’s Windows computer name as its complete identity. Existing certificates may contain CDP and AIA URLs that point to the old host name. If those paths disappear during a migration, clients can report revocation or chain-building errors even if the new CA issues certificates correctly. Inventory both LDAP and HTTP publication locations, the actual URLs embedded in issued certificates, DNS aliases, firewall paths, web publication jobs, and any external relying parties. Record CA configuration using supported tools and preserve the current CA certificate and chain separately from ordinary server configuration backups.

For an enterprise CA, record the certificate templates it publishes and its enrollment permissions. Template objects are stored in Active Directory and are not included in a CA database backup. Confirm the template list on the CA and the current template security descriptors and versions in AD DS. For a standalone CA, document its policy and request approval workflow. For a subordinate CA, verify the parent CA contact, subordinate CA certificate chain, and renewal/expiration dependencies. A complete server image backup is useful as an additional recovery layer but does not replace the documented CA-specific backup set.

Build and protect the backup set

Microsoft’s migration guidance identifies the CA database, private key, CA registry settings, CAPolicy.inf, and enterprise CA template list as distinct items to preserve. The database and key can be backed up through the Certification Authority snap-in, PowerShell, or Certutil. Protect the resulting .p12 file and its password as separate secrets. Never place either in a source repository, ticket, email, or a broadly readable share. Use a secured, access-controlled backup location and verify that the backup can be read by the designated recovery custodians.

The following example creates a date-stamped directory and invokes the supported backup cmdlet. Run from an elevated Windows PowerShell session with the ADCSAdministration module on the CA, after checking free space and the destination’s security. The command writes sensitive output and can take time; it is not a dry run.

$backupRoot = 'E:\ProtectedBackups\CA01-2026-10-03'
New-Item -ItemType Directory -Path $backupRoot -ErrorAction Stop | Out-Null

Import-Module ADCSAdministration -ErrorAction Stop
Backup-CARoleService -Path $backupRoot -Password (Read-Host `
    'Enter a unique backup password' -AsSecureString)

# Capture configuration artifacts separately; review them before transfer.
reg.exe export `
    'HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration' `
    (Join-Path $backupRoot 'certsvc-configuration.reg') /y

if (Test-Path "$env:windir\CAPolicy.inf") {
    Copy-Item "$env:windir\CAPolicy.inf" `
        (Join-Path $backupRoot 'CAPolicy.inf') -ErrorAction Stop
}

# Record published enterprise templates in the change evidence.
certutil.exe -catemplates | Out-File `
    (Join-Path $backupRoot 'published-templates.txt') -Encoding utf8

Validate the exact Backup-CARoleService syntax and password-handling requirements for the installed module before production use. If the CA uses an HSM, follow the HSM vendor procedure for backing up and restoring the key; the generic software-key export above must not be treated as an HSM key backup. Review file ACLs and encryption on the destination, record cryptographic hashes for transfer verification, and store the password in an approved secrets system that is not on the same media. The CA database backup contains sensitive issuance history and must be protected accordingly.

After the supported backup completes, Microsoft directs administrators to stop the Active Directory Certificate Services service to prevent further certificate issuance during migration. Coordinate the outage with enrollment owners, verify the database and log files, and retain the old CA in a state that matches the documented cutover procedure. Do not take a database copy while issuance continues and assume it is a consistent migration backup. Ensure backups for registry data and CAPolicy.inf are stored alongside the CA backup, and confirm the enterprise template list was captured because it is not restored from the database.

Plan the cutover and restore sequence

Use Microsoft’s current CA migration guide for the supported step-by-step sequence. Confirm administrative access to both servers, destination OS support, domain membership, DNS and network reachability, storage paths, role service availability, and a secured backup transfer. Preserve the CA common name, CA type, key pair, and configuration expected by relying clients. If the destination uses a different computer name, plan how existing CDP/AIA URLs remain available; changing CA host names does not rewrite URLs embedded in certificates already issued.

For a typical supported migration, back up the source CA, publish an extended-validity CRL before taking the source out of service, stop certificate issuance, and remove the CA role service from the source before installing it on the destination. Microsoft’s guide permits a rollback design that retains the source role only if the source service stays disabled and that server is shut down before installing the destination CA; do not remove the source role after destination installation because the shared CA common name can cause required AD DS configuration to be removed. Then prepare the destination, import or access the existing CA certificate and key, install the same CA type, restore the database and configuration, and restore template publication. Do not run the old and new CA instances concurrently with the same identity and key. A failover-cluster migration requires role installation on the cluster nodes and shared storage; the database restore is performed on only one node according to Microsoft’s procedure.

At the destination, place CAPolicy.inf before configuring the CA if the file is used. Import the CA certificate and key using the supported wizard or HSM procedure. Restore the database to the planned path, restore CA registry configuration carefully, and compare the resulting registry values to the recorded source configuration. Not every machine-specific setting should be copied unchanged. Review provider names, database and log paths, publication URLs, validity periods, exit modules, policy modules, audit configuration, and service permissions before enabling issuance.

For registry restoration, inspect the .reg content and target path before importing. Do not blindly double-click it on a new host. The same source export may contain machine or path assumptions. Use the relevant Microsoft migration steps and have a reviewer validate the settings before importing. Keep a rollback checkpoint that does not create two active CAs with the same identity. If an HSM is used, verify the key association and provider state by vendor instructions before starting certsvc.

Validate issuance, chain building, and revocation

Before reopening enrollment broadly, confirm that the CA service starts without errors, the CA certificate has the expected thumbprint and key association, the restored database is present, issued and revoked certificate records are visible, the correct templates are published, and the template permissions match the approved configuration. Review the Certification Authority event log and service state. Compare the restored CA configuration against the recorded baseline and inspect each publication extension.

Test a controlled certificate request from a representative client using the real enrollment path and template. Validate the issued certificate’s subject, SAN, EKU, validity, key usage, issuer, and embedded CDP/AIA extensions. Then build the chain on a machine that has not cached the old CRL, retrieve the CRL from every relevant URL, confirm it is current and signed by the expected CA, and test revocation status for a known revoked test certificate. A successful issuance test does not prove revocation checking works. Test both domain-connected and external client paths if both are in scope.

If old certificates reference a retired host name, preserve publication at the old URLs through an approved DNS alias, web path, or other documented method. Do not redirect all CA publication URLs blindly: LDAP and HTTP distribution locations have different clients and authorization models. Verify that the CRL’s NextUpdate period and publication schedule satisfy relying systems. Confirm that AIA locations provide the expected issuer certificates and that clients can build the chain when intermediate CA caches are empty.

For enterprise CAs, verify the template list and ensure enrollment agents, autoenrollment, permissions, and group policy still behave as intended. Check the relevant Active Directory objects and test enrollment from a standard user and computer account, not only an enterprise administrator. For standalone CAs, run the documented approval workflow. Reconcile newly issued serial numbers and requests against the change window, and confirm that old monitoring, backup, and alerting systems now target the destination.

Recovery and rollback safeguards

Keep the source machine and original backup until the destination has passed acceptance and the rollback period has expired. If migration fails, follow the documented decision tree rather than starting the source CA while the destination remains active. A CA database restore may reissue or expose state differently than expected; keep one active authority for a given identity unless the supported high-availability configuration explicitly defines otherwise. Protect the CA private key and any .p12 export as a critical asset throughout rollback.

Store a recovery record with backup timestamp, hashes, key custody, password custodian, database version, CA certificate thumbprint, registry export, CAPolicy.inf, templates, CRL/AIA paths, source and destination host identities, and test results. Conduct a periodic restore exercise in an isolated environment using the same HSM or key protection strategy. A backup that has never been restored is only a claim of recoverability.

Related:

Sources:

Comments