About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Many organisations run a certification authority without thinking about it much. It was set up years ago, it issues certificates for wireless access, VPNs, internal websites or device sign-ins, and it rarely needs attention. That quiet reliability is also why its backup is so often incomplete.
Microsoft's overview What is Active Directory Certificate Services? describes the role: Active Directory Certificate Services (AD CS) is a Windows Server role for issuing and managing public key infrastructure (PKI) certificates used in secure communication and authentication protocols.
This article sets out what a backup of that role must contain and what a restore depends on, drawing mainly on Microsoft's guide to migrating a certification authority, which documents the same pieces a recovery needs.
Why a certification authority cannot just be rebuilt
In our reading, the defining fact about a certification authority is that its identity is its key pair. Every certificate it issues is signed with its private key, and every device that trusts it does so because it holds the matching certificate. Microsoft's guide on how to Renew root CA certificate in Windows Server illustrates this: when a CA certificate is renewed with the existing key pair, renewal can reuse the existing key pair; the public certificate does not contain the private key. Previously issued certificates still chain up to it.
The reverse is also true, in our understanding. A new certification authority installed from scratch, even with the same name, has a new key pair. Certificates issued by the old authority do not chain to it, devices do not trust it until its certificate is distributed again, and it cannot publish revocation information for certificates it did not issue.
That makes the private key the single most important thing to protect. Without a usable recovery path for the signing key, restoring that CA identity is not possible. The PKI owner must plan replacement trust, revocation handling and any required reissuance; the scope depends on which CA and keys were lost.
What the backup must contain
Microsoft's Migrate a Certification Authority guide lists what to back up before moving a CA. In our view, the same list defines a complete recovery backup:
The following is our summary of the listed items and their recovery purpose.
| Item | What it holds | Why it matters in recovery |
|---|---|---|
| CA database | Records of issued, revoked and pending certificates | Revocation and auditing depend on it |
| Private key(s) | The CA's signing identity | Without it, the CA cannot be recovered |
| CA registry settings | The CA's configuration | Publication locations, validity periods and policy |
| Custom CAPolicy.inf file, if used | Settings used when the CA was installed | Preserves the custom installation policy |
| Templates list | Certificate templates the CA issues (enterprise CAs only) | Without it, the CA issues nothing it used to |
A database-and-key backup alone does not cover every listed dependency. Microsoft says enterprise template assignments are not included in the CA database or registry backup because the templates and their associations are stored in AD DS; record the assigned list separately. A CA restored without its registry settings may publish revocation lists to the wrong places, or issue certificates with different settings from before.
The guide notes that these items can be backed up with the Certification Authority snap-in, with PowerShell, or with the command-line utility. Microsoft's article on the CA Backup and Restore Windows PowerShell cmdlets describes the two cmdlets added for this purpose. This article does not give their syntax.
The key password is part of the backup
When the private key is backed up, it is exported into a file protected by a password. Microsoft's migration guide is direct about what that means: You must retain a copy of the password to access the key during CA installation on the destination server.
In our view, this is one of the easiest ways for a certification authority backup to fail. The key file is safely stored, but the password was chosen by someone who has since left, or written down somewhere that was lost with the server. The password belongs in the organisation's secure credential store, recorded alongside the backup's location and date, and someone other than the person who made the backup should check it can be found.
The exported key is also, in our view, one of the most sensitive files an organisation holds. Anyone with the file and its password can issue certificates the organisation's devices will trust. The backup should be kept with matching protection: restricted access, offline or protected storage, and a record of who can reach it.
When the key is in a hardware security module
Some organisations keep the CA's private key in a hardware security module, a device designed so that the key cannot be copied out in plain form. The migration guide states: If a hardware security module (HSM) is used by the CA, back up the private keys by following procedures provided by the HSM vendor.
In our reading, that means a Windows backup of the CA server does not include a usable copy of the key. The key's recovery depends on the hardware vendor's own backup and restore process, which may involve separate devices, cards or people. In our view, that process belongs in the same recovery plan, tested on the same schedule.
Keep planned migration and routine backup distinct
The guide also says that once the backup is complete, the certificate service should be stopped: The service must be stopped to prevent issuance of more certificates.
That advice is for a planned move. In our reading, its logic applies to recovery as well: any certificate issued after the last database backup is not recorded in the restored database. The restored database lacks those issuance records, so revocation and audit reconciliation need specialist review; do not assume the older database is complete. For a busy issuing CA, that is an argument for frequent database backups. For a root CA that issues rarely, it is an argument for taking a backup after each issuance.
Revocation lists set the deadline
Every certificate a CA issues tells devices where to check whether it has been revoked. If those revocation lists expire and are not replaced, devices that check them may stop trusting the certificates.
The migration guide's advice for a planned move is: You should publish a CRL with an extended validity period for each CA being migrated. For a planned migration, it says the CRL validity period should cover at least the planned migration duration. It explains why: This procedure is particularly important for a root CA because of the potentially large number of certificates that would be affected by the unavailability of a CRL.
In our reading, an unplanned loss gives no chance to publish a longer list first. The expiry and availability of published revocation information create important recovery deadlines, alongside issuance and authentication needs. In our view, every recovery plan for a certification authority should record, for each CA, how long its revocation lists are valid and how much overlap is configured, because that is the time available before certificate checks start failing.
The server name is built into the certificates
The guide's restore steps include a notable instruction: Before joining the destination server to the domain, change the computer name to the same name as the source server.
In our understanding, the reason is that the CA's computer name typically appears in the publication locations written into every certificate it has issued: where to fetch the CA's certificate and where to fetch its revocation list. The guide describes what must change if the name is different: registry settings need editing, new publication locations need adding, and the destination server must be granted permissions on the source server's CDP and AIA containers in AD DS to publish CRLs and CA certificates.
In our view, recovering a certification authority under its original name is far simpler, and the recovery plan should assume it unless there is a reason not to. Where the CA name, or the published web locations, are already independent of the server name, recovery onto a new server is easier still. That is a design decision best made before it is needed.
Two CAs must not run at once
The guide notes that some administrators choose to leave the original CA installed during a migration so that it can be brought back quickly, and that it isn't recommended. If it is done, the guide requires disabling the source Certsvc service and shutting down the source server before installing the destination CA role. In our reading, the same caution applies in recovery: if a failed CA server comes back to life after its replacement has been restored, two servers with the same key and name could both issue certificates, with separate databases. The recovery plan should make sure the original stays off.
Root and issuing CAs recover differently
Many organisations run more than one CA: a root CA at the top, often kept switched off, and one or more issuing CAs below it that handle everyday requests. Microsoft's renewal guide lists, among its prerequisites, an Understanding of your organization's PKI hierarchy and certificate policies. In our view, the same understanding is a prerequisite for recovery planning, because each tier fails differently.
In our reading, an issuing CA is busy, changes daily, and its loss is felt quickly as revocation lists age. Its backup needs to be frequent and its restore rehearsed. A root CA is the opposite: it changes rarely, so its backup can be taken whenever it is used, but losing its key is far more serious, because every CA below it depends on it. An offline root also needs to be switched on periodically to publish a fresh revocation list, which makes its storage, its startup and its key password part of routine operations as well as recovery.
Checking a restored CA
In our view, a restored certification authority is not recovered until it has been shown to work. That means confirming it starts with its original certificate, publishes a revocation list to the expected locations, lists previously issued certificates from its database, and issues a test certificate from an expected template. Each check corresponds to one of the backup items above, which makes a missing item easy to spot.
What we recommend
- Back up all five items: database, private key, registry settings, custom CAPolicy.inf if used and, for enterprise CAs, the templates list.
- Store the key password securely and separately, and check that someone else can find it.
- Protect the key backup as one of the organisation's most sensitive files.
- Include the hardware vendor's process if the key is in a hardware security module.
- Back up the database often on issuing CAs, and after each issuance on a root CA.
- Record revocation list validity for each CA as the recovery deadline.
- Plan to recover under the original name, and make sure the original server stays off.
Protect certificate history and template definitions
Keep the CA certificates and all private-key generations required by retained certificates and backups, not only the newest export. A CA renewal can change which key signs new certificates; the recovery inventory must explain which certificates and revocation lists depend on each key. For an HSM, record the vendor-supported recovery mechanism and the people or devices required to use it without placing key material in the general runbook.
For an enterprise CA, the list of issued templates is not a backup of the template definitions themselves. Those definitions and permissions live in Active Directory and require directory protection. Acceptance should distinguish a root CA from an issuing CA: not every CA issues template-based end-user certificates. Rehearse on an isolated PKI with controlled publication locations, so that a test cannot publish production revocation information or create a second active issuer. Validate the relevant chain and revocation behaviour from a representative relying client.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026, chiefly the CA migration guide applied to recovery.
- Applying migration steps to recovery, and the reasons given for name and key dependencies, are our reading and understanding.
- Hardware security module procedures vary by vendor and are not covered.
- No certification authority was backed up or restored for this article, and no commands, registry paths or key material are given.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: What is Active Directory Certificate Services?
- Microsoft Learn: Migrate a Certification Authority
- Microsoft Learn: CA Backup and Restore Windows PowerShell cmdlets
- Microsoft Learn: Renew root CA certificate in Windows Server
This article was originally published on .