CA backup, migration and recovery

Recover the authority, not just the server

A CA’s ability to issue certificates and sign revocation information depends on its existing signing key. The certificate database records issuance and revocation state; it does not contain the CA private key. A database-only backup therefore cannot recover the authority. Microsoft explicitly separates CA database backup from private-key backup.

Record the CA type and name, OS, certificate/key history, cryptographic provider, database/log paths, publication locations and dependent services. A planned server move and suspected key compromise need different recovery plans. Restoring a possibly exposed key doesn’t make the authority trustworthy again.

Choose hierarchy, cryptography, CA name and operational controls before installation. An offline root still has recurring CRL and backup obligations. A tier per site is not a requirement. Microsoft PKI design considerations.

Take a backup whose contents you can explain

On the source CA, using an authorized elevated session and a protected backup location, this exports CA private-key material and the database:

Import-Module ADCSAdministration
$backupPassword = Read-Host 'CA key backup password' -AsSecureString
Backup-CARoleService -Path 'D:\CA-Backup\BeforeMigration' `
    -Password $backupPassword

The default backs up both. -DatabaseOnly omits the key; -KeyOnly omits the database. Keep the backup password separate from the backup media. The Backup-CARoleService reference documents the parameter sets. For an HSM, follow the vendor’s supported recovery procedure; a software-key PKCS #12 export may not be possible.

For a software-key backup, Microsoft’s migration procedure describes a CA .p12 plus a Database directory containing the database and related backup/log files. Check what’s actually there, then rehearse the restore.

Back up again after CA certificate/key renewal and whenever configuration changes require it. Retain earlier CA keys/certificates according to the lifecycle of certificates they issued; a new signing key does not eliminate all dependencies on the old one.

Capture configuration outside the database

These are local backup/export actions on the CA:

reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" "D:\CA-Backup\BeforeMigration\CA-configuration.reg"
certutil -config "CA01\Contoso Issuing CA" -catemplates

Save the template output with the recovery material and copy %SystemRoot%\CAPolicy.inf if it exists and is part of the deployment. Certificate templates and the CA’s template association live in AD, so the CA database/configuration backup does not replace that inventory. Microsoft’s CA migration procedure covers these separately.

Record any enrollment web services, OCSP configuration, IIS publication shares, scheduled publication jobs and access permissions separately. The recovery scope for those components is broader than the CA role alone.

Where the CA archives subscribers’ encryption keys, preserve the KRA recovery capability as a separate dependency. Restoring the CA’s signing key is not equivalent to restoring a KRA’s private key, and a public KRA certificate cannot decrypt an archived subscriber key. Retain the older recovery-agent keys still associated with archived requests and rehearse recovery of representative data. EFS and key recovery separates CA archival, user keys and file-level recovery agents.

Keep one issuing instance during migration

For a planned move, decide when issuance stops and take the final backup at that point. Stop the source CA service as the migration procedure requires, and keep the two copies from issuing independently. The destination needs the existing CA certificate and private key. A fresh CA with a similar display name is a different authority.

The source-role removal order matters. Normally, remove the source CA role before installing the destination role. Uninstalling the old role afterward can remove shared AD configuration required by the new CA. Microsoft’s documented alternative for administrators retaining the source for fallback is to disable CertSvc and shut that source down before destination installation, and not uninstall its CA role afterward. Choose and record that branch before cutover. Source CA removal ordering.

Plan the outage around enrollment, renewal and CRL publication deadlines. Existing certificates can remain valid while the CA is down if their validation requirements are still met. New enrollment and renewal need the appropriate services. Check the whole hierarchy: an expired parent CRL can affect the issuing CA as well as its clients.

Restore in the documented order

Rehearse the version-appropriate procedure in an isolated recovery environment before relying on it:

1. Restore/import the existing CA certificate and signing key, or reconnect the HSM key using the vendor procedure.
2. Review any restored CAPolicy.inf and copy it to the destination %windir% before adding/configuring the CA role. Use the existing CA identity and correct CA type.
3. Restore the database and logs from the intended backup; stop the service where the restore procedure requires it.
4. Restore reviewed CA settings, adjusting database/log paths and host-dependent configuration for the destination.
5. Restore the enterprise template issuance list and verify the CA can read those templates.
6. Start the service and test publication, enrollment and relying-client validation.

Restore-CARoleService restores database/key information, with separate parameter sets for each. It does not turn an arbitrary restored registry file into a safe destination configuration. Its reference and the migration procedure supply the supported sequence. Use the parent backup directory expected by the database restore operation, not a guessed nested path.

Prove continuity from the client

Check CA certificate thumbprints and key/provider association, request/revocation records, available templates and a controlled request. Then test an existing certificate and a newly issued certificate from representative client networks. Check the published CRL bytes and dates too. Starting the service won’t tell you whether external clients can validate the chain.

Keep old AIA/CDP locations serving the required data while certificates still reference them. A server rename cannot modify certificates already issued. Use chain and revocation diagnostics and Microsoft’s migration verification checklist as test inputs, adapting the older checklist to the actual supported OS/provider configuration.