Re-Keying the Manager CA

Re-keying gives the Manager a new certificate authority. Every agent in your estate trusts the old CA's fingerprint, so after a re-key every agent refuses the Manager until it is re-pointed at the new fingerprint. That makes re-keying the last resort for a lost Manager, and the required step for a compromised one.

When to re-key

You have a database snapshot but not the recovery passphrase, so the CA in the snapshot cannot be recovered on a new machine. A configuration backup cannot be opened at all without the passphrase.
You have no database at all, and are installing a new Manager from scratch. A fresh installation creates its own CA, which amounts to a re-key.
The Manager was compromised: an attacker had control of it, or its CA key, database, or enrollment token may have been read. Re-key even if you have the recovery passphrase, because recovering the old CA would put a key the attacker may hold back into service.

If you have a configuration backup or a snapshot and the passphrase, and the Manager was not compromised, recover the Manager instead; agents then need nothing. See Recovering the Manager.

Re-keying a Manager database

To re-key the CA in a Manager database:

Build the Manager machine from a snapshot, following steps 1 to 5 of building a new Manager in Recovering the Manager.

Leave the service stopped.
In an elevated command prompt in the Manager's program folder, run:
```
CygnaDR.Manager.exe ca rekey
```
The command warns you if the current CA is still usable on this machine or the database holds an escrow copy. In that case you probably want ca recover instead.
Type REKEY to continue.

The CA is replaced, and an audit entry records both fingerprints.
Enter a new recovery passphrase, twice, when asked.

Store it offline with the break-glass credential. Configuration backups resume under the new passphrase once the service starts.
Start the Manager service, and sign in.
If the Manager sends email, enter the SMTP password again in the Email group on the Manager tab of the Configuration screen.

A password kept in settings cannot be read on a machine other than the one that saved it. Until you enter it, recovery plans send no notifications and no report email.
Select Administration > Agents, and read the new CA fingerprint.

Replace the copy in your recovery notes.
Re-point every agent, as described below.

With no database at all, install the Manager, sign in at once, and complete the setup. The new Manager has a new CA, no inventory, no restore points, and no history; the backups are still on the storage machine, but the Manager does not know about them. Then re-point every agent.

Re-pointing the fleet

Until an agent is re-pointed, it refuses the re-keyed Manager. When it is re-pointed, its old certificate is refused too, and it enrolls again with its enrollment token; you do not need to delete certificates by hand.

DC agents—From a machine where cdr trusts the re-keyed Manager, run cdr agent deploy with --repoint --force and --manager-address set to the Manager's agent address (TCP 5211 by default). The deployment pins the fingerprint of the Manager that cdr trusts. If the Manager has a new enrollment token, give it in CYGNADR_ENROLLMENT_TOKEN or when prompted, and the deployment writes it to every agent too. Name the domain controllers, or use --all, which also installs the agent on any domain controller that has none:
```
cdr agent deploy --all --repoint --force --manager-address https://10.0.0.10:5211 --user CORP\admin --package CygnaDR.DcAgent.msi
```
The storage agent, and agents installed by hand—Reinstall on the machine with the new fingerprint, and the new address and enrollment token if they changed:
```
msiexec /i CygnaDR.StorageAgent.msi /qn MANAGERCAFINGERPRINT=<new fingerprint>
```
cdr users—Each operator runs cdr trust remove --manager <address>, connects again, and confirms the new fingerprint.
Browsers—Operators trust the new Manager CA on their workstations. See Trusting the Manager Certificate.

The console's install and update actions do not re-point agents, so they are not a substitute for these steps. For details, see Maintaining Agents.

Replacing a compromised Manager

A compromised Manager's identity can no longer be trusted, so it is replaced, never recovered. Anyone holding a copy of its CA key could pose as the Manager to every agent.

To replace a compromised Manager:

Take the old Manager off the network, and keep its disk for investigation.

Do not start it on the network again, even to copy something off it.
Choose the database to start from.

The best choice is a snapshot from before the compromise began. A snapshot taken during the compromise brings back whatever the attacker changed, including operator accounts, roles, settings, exclusions, and plans. If no snapshot can be trusted, start from a fresh installation.
Build the new Manager machine. Giving it the old address saves re-addressing the agents.
Install the Manager with a new enrollment token, and store the new token offline in place of the old one.
If you are using a snapshot, put it in place as for any snapshot recovery, then run CygnaDR.Manager.exe ca rekey, not ca recover, and set the new recovery passphrase it asks for.
Start the service and sign in with the break-glass account.
On the Operators & Roles screen, reset the password of every named operator, and disable any account you cannot account for.
Change the break-glass password from the account menu, and update the offline record.
Read the new CA fingerprint on the Agents screen, and replace the copy in your recovery notes.
Re-point every agent at the new fingerprint, as described in Re-pointing the fleet, and give every agent the new enrollment token.

The re-pointing deployment writes the new token to every DC agent. Reinstall the storage agent, any Isolated Recovery Host agent, and any agent installed by hand on its machine with the new token, for example msiexec /i CygnaDR.StorageAgent.msi /qn MANAGERCAFINGERPRINT=<new fingerprint> ENROLLMENTTOKEN=<new token>. Until an agent is re-pointed, it still trusts the old CA and does not work with the new Manager, so re-point every agent, and do it before the backups in the next step.
Start a backup of every domain controller you back up, once its agent is re-pointed.

These are the first backups whose agent trusts the new Manager.
Have every cdr user remove the old trust and confirm the new fingerprint.
Once the Configuration backups card on the License screen shows a backup from the new Manager, delete the older configuration backups on the storage machine.

The files in <StorageRoot>\manager-backups written before the replacement hold the old CA key, the old enrollment token, and the old secret settings, and they open with the old recovery passphrase. The Manager cannot delete them, so this is done on the storage machine.

Restoring backups taken before a re-key

After a compromise, the backups worth restoring are usually ones taken before the re-key, and the DC agent inside each of them still trusts the old CA. Preflight reports this with agent.ca-changed:

It does not block an ordinary restore. The directory comes back, but the restored agent refuses the new Manager until you re-point it. Re-point it with cdr agent deploy <DC> --repoint --force --manager-address <address> as soon as the machine is on the network. The run waits in validation until the agent connects. The restored agent is then asked to check its domain controller, and the run completes or fails on its answer.
It blocks approval when the restore plans network settings for the restored system, because the restored agent would refuse the settings the new Manager signs. Plan the restored system's network as unchanged, and set the address by hand before you re-point the agent.

Note: Important: A DC restored from a backup taken before the re-key trusts the old CA from the moment it starts until you re-point it. Keep restored domain controllers on the isolated recovery network until they are re-pointed.