A certification authority can look quiet while remaining one of the most consequential services in a Windows environment. Devices, users, Wi-Fi, VPNs, web servers, smart cards and signed code may continue trusting certificates for years after issuance. Moving the CA safely means preserving that trust system—not merely making the Certification Authority console open on a new server.

Begin with the trust contract

Before changing anything, identify what must remain true:

  • the CA’s common name, certificate and private key remain the same;
  • previously issued certificates still build a valid chain;
  • relying parties can still retrieve every required CA certificate and revocation list;
  • approved templates remain available to the intended principals;
  • new issuance, renewal and revocation are controlled and auditable; and
  • a usable CA backup exists after the move.

Changing the host name may be possible. Changing the CA identity is a different project. If the private key is suspected compromised, do not migrate it as though this were routine maintenance; use a formal CA-compromise and replacement plan.

Inventory the complete CA, not only the role

Record the CA type and hierarchy position, CA name, signing certificate and validity, serial-number history, database and log paths, operating-system and AD CS versions, crypto provider and key-storage arrangement. If an HSM is involved, confirm its vendor-supported backup, restore, driver and destination requirements before scheduling anything.

Then map the dependencies:

  • certificate templates enabled on this CA and their ownership;
  • enrolment and autoenrolment policies;
  • certificate distribution point (CDP) and authority information access (AIA) URLs;
  • online responders or web-enrolment services;
  • service accounts and permissions;
  • scheduled CRL publication, delta CRLs and their overlap periods;
  • applications that pin a CA, URL or certificate; and
  • monitoring, audit logs and backup jobs.

Check the configured extensions against what clients actually fetch. An obsolete path in a console may be harmless, while a forgotten HTTP location embedded in thousands of current certificates is not.

Build a recoverable migration set

Microsoft’s migration guidance separates several pieces because no single export contains the whole service. Protect at least:

  • the CA certificate and private key;
  • the CA database and logs;
  • relevant CA registry configuration;
  • the list of certificate templates published by an enterprise CA; and
  • the documented CDP/AIA, service-account, permission and external publication configuration.

Enterprise certificate templates live in Active Directory; they are not automatically included in the CA database backup. Record the enabled template list so it can be reconciled after restoration.

Treat the private-key backup as highly sensitive. Encrypt it, restrict access, record custody and keep its password outside the same package. Copying a CA key into an ordinary project share, ticket or technician download folder creates a far larger risk than the migration solves.

Prove that the backup can be read before relying on it. A backup job reporting success does not establish that the key is present, the password is known or the destination can load its provider.

Prepare the destination without creating a second authority

Patch and harden the destination, install any required HSM/provider components, prepare storage, service identity, firewall and publication access, and confirm time and Active Directory health. Record the source CA service state and a cutover rollback point.

Install AD CS only according to Microsoft’s migration sequence for the exact source and destination versions. Do not initialise an unrelated new CA with the old name and then try to copy data over it. The restored service must use the original CA identity and key.

Plan a clear authority transition:

  1. publish a fresh CRL with enough validity to cover the maintenance window;
  2. stop issuance on the source;
  3. take the final database/configuration backup;
  4. restore the identity and state to the prepared destination;
  5. reconcile configuration and templates; and
  6. allow issuance only after validation.

Avoid operating both machines as independent active instances of the same CA. Duplicate issuance authority complicates serial history, audit evidence, revocation and recovery.

Reconcile names, paths and policy

A different server name can affect database/log registry paths and any extension that embeds the old host. Follow Microsoft’s documented registry adjustments only after reviewing them against the current environment. Do not perform a blanket search-and-replace: some URLs must deliberately retain an old stable DNS name because certificates already contain it.

Prefer service aliases and publication locations that are independent of a physical server. Keep the old HTTP/CDP/AIA content available for as long as any valid certificate depends on it. Test from a client without a warmed cache; an administrator’s machine may appear healthy because it already possesses the chain and CRL.

For an enterprise CA, restore or re-enable only the reviewed template set. Confirm template security, supersedence, validity periods, enrolment-agent settings and autoenrolment scope. Migration is a poor moment to publish every template “temporarily.”

Prove the service from a relying party

Validate in layers:

  • the CA service starts with the expected identity and database;
  • historical issued, revoked and failed-request records are present as expected;
  • a synthetic subject can request and receive an authorised certificate;
  • renewal produces the expected template, key and validity;
  • revocation updates the correct CRL and clients can retrieve it;
  • CDP and AIA URLs respond with current, valid objects from another network path;
  • a clean client builds the complete chain and checks revocation;
  • autoenrolment succeeds for an allowed identity and fails for a denied one; and
  • monitoring, audit retention and the new backup/restore procedure work.

Test representative real certificate uses—such as one internal TLS service or test VPN profile—without exposing production private keys. “The service started” is necessary evidence, not acceptance.

Retire the source deliberately

Keep the old server isolated and recoverable for the agreed observation period, but do not let it resume issuance. After dependencies and rollback criteria are satisfied, remove or repurpose it through the approved server-lifecycle process. Retain migration evidence, secured backups and the new recovery runbook.

The migration is complete when the organisation can issue, renew, revoke, validate and recover certificates through the intended architecture—and can explain who is authorised to do each of those things.