CA Recovery in Active Directory

This is one of the reasons why it's highly recommended that you do not have a CA running on a domain controller. I have one on a DC in a legacy domain right now and it is a maintainability nightmare and it will be removed when another service dependency is sorted out. DCs and CA servers are highly critical, of course, and if you have one function fail while the other is fine, it makes it much more complex to deal with.

I highly recommend implementing a separate maintenance plan to backup your CA database via a scheduled task. This maintenance plan should also include processes (certutil or PKPSI Powershell) to regularly delete old rejected or pending certificate requests plus expired certificates. Not only will it help if you want to migrate, or recover the CA elsewhere, you should do a regular backup like any database to clean up the transaction logs and ensure everything is committed.

To get one going, do a full backup of the CA - including the CA key - to a directory on a local volume that doesn't have CA database on it. Call the directory something like CABackup, then create a child directory that says something like "Initial Backup". Target your first backup there. The CA private key should be archived somewhere secure with a record of the password used to save it. Also export the registry key HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\[CAName] to your backup folder.

For regular maintenance, we have a script that creates a new backup folder underneath the "CABackup" parent folder each time it runs - the directory must be empty for each backup. It backs up the CA database only. Naturally, the CA backup directory and its contents is archived to tape with the rest of the regular filesystem backup. The same script also performs the cleanup of stale REQs and expired certs if the local backup is successful.

You should have a process to delete old backups - we keep the last 5 available - but don't delete your Initial Backup folder. Of course, if you change the CA key for some reason, do a new Initial Backup of both the DB and CA key.

In the domain where a CA and DC coexist, in the event the entire domain needed recovery, I would not use the DC hosting the CA as a recovery target. Any alternate DC would be preferable. If the actual domain is healthy but something was wrong with ADDS on the shared server, I would simply remove ADDS and build another DC.

If the CA required recovery, but not the DC, I'd take the opportunity to migrate the CA. The exported reg key helps expedite the process, but ensure you configure the recovered CA instance with the new server FQDN in the Registry. This procedure to migrate a CA describes the process. Also, naturally, test the CA recovery process in an isolated environment.

It might be perfectly fine recovering both DC and CA with a system state recovery, but to be honest, one or other of those is stressful enough by itself. I've only done it myself once in very long-ago days in an environment with a single "everything" DC/CA/file server.

I do recommend moving your CA as soon as possible, though, before you incur much more "technical debt". It can coexist with some other less-critical roles, like a KMS server or WSUS, if you have constraints on the number of systems you can have. If you aren't constrained, you should do a two-tier offline root plus intermediate CA setup. The migration article linked above is worth a read even just for your info - a basic migration isn't a very difficult process.

Also, what you should definitely do, if you keep your current config (for a while) is as soon as possible try a system state recovery in an isolated environment, including adding at least one new DC to the recovered domain and ensuring the CA can issue certs to the kind of clients it does currently. That should help clarify any potential pain points.