Certificates and Trust
Every connection to the Manager is encrypted with TLS, and every certificate involved is issued by the Manager's own certificate authority (CA). Cygna Forest Recovery does not use a domain certificate service or a public CA, so secure connections keep working when the directory is down. This topic explains the certificates, the two values you handle when installing agents—the CA fingerprint and the enrollment token—and how browsers and cdr come to trust the Manager.
The Manager CA
The Manager creates its CA the first time its service starts. The installer creates no certificates. The CA uses an ECDSA P-256 key and is valid for 20 years. Its private key is kept in the Manager's database, protected for that machine. When you set the recovery passphrase at first sign-in, a copy of the key is protected with that passphrase so that the Manager can be restored on another machine. For more information, see Protecting the Manager.
The Manager uses the CA to issue:
- Its own server certificate—Valid for 365 days and renewed automatically. It covers the Manager's host name, its fully qualified name,
localhost, and every IP address of the machine. If the machine's names or addresses change, the Manager issues a new certificate when it starts. - A client certificate for each agent—Issued when the agent enrolls, valid for 365 days, and renewed automatically when two-thirds of its lifetime has passed.
Connections use TLS 1.2 or TLS 1.3. Plain HTTP is refused, except on the optional redirect port, which only sends browsers to the HTTPS address.
CA fingerprint
The CA fingerprint is the SHA-256 hash of the Manager's CA certificate. It is shown as 16 groups of four hexadecimal characters separated by hyphens. Agents use it to make sure they are talking to your Manager and not to an impostor: an agent connects only to a Manager whose CA matches the fingerprint it was installed with.
The fingerprint is public, not secret. It identifies a certificate that the Manager presents to anyone who connects, so you can copy, email, or print it freely. You can find it in these places:
- In the Windows Application event log on the Manager machine, every time the Manager service starts, in a line that begins
Cygna DR manager CA fingerprint:. This is the most reliable source, because you read it on the Manager machine itself. The same line appears in the currentmanager-yyyyMMdd.logfile in%ProgramData%\Cygna Labs\Disaster Recovery Suite Manager\logs. - On the Agents screen of the console, in the installation command for each agent, including before any agent has enrolled. The Manager recovery card on the License screen also shows it.
- In the output of
cdr trust list, aftercdrhas connected to the Manager.
Before you rely on a fingerprint, compare it from two of these sources. A manual agent installation requires it as the MANAGERCAFINGERPRINT property. When you install agents from the console or with cdr agent deploy, the fingerprint is supplied automatically.
The fingerprint changes only if you replace the Manager CA. For what that involves, see Re-Keying the Manager CA.
Enrollment token
The enrollment token is a secret that you choose and give to the Manager installer as the ENROLLMENTTOKEN property. Every agent presents the same token the first time it connects. An agent with a valid token is enrolled immediately, with no approval step; the enrollment is recorded in the audit trail.
Note: Important: Treat the enrollment token like a password. Anyone who has it and can reach the Manager can enroll an agent. Windows Installer masks it in installer logs, including a verbose log (/l*v), but not on the msiexec command line. Where process-creation auditing records command lines (event 4688), the token is in that event: install DC agents from the console or with cdr agent deploy, which put no token on a command line, and keep commands that contain it out of scripts.
- The console never shows the token.
- Each installation keeps its token in the registry, readable only by SYSTEM and Administrators, so an agent can enroll again if its certificate expires or the Manager no longer recognizes it. Upgrades keep the stored token.
- Store a copy offline with your other recovery secrets. You need it to rebuild the Manager on a new machine without re-enrolling every agent. See Manager Day-One Checklist.
Why IP addressing works
Agents check the Manager's certificate against the pinned CA and against a marker that only the Manager's certificate carries. They don't compare it with the address they connected to. This means:
- Agents can reach the Manager by IP address, without DNS.
- A stolen agent certificate cannot be used to impersonate the Manager, because it lacks the Manager marker.
- A Manager restored onto a machine with a different address is still trusted by every agent, with nothing reissued.
The Manager identifies each agent by its client certificate in the same way, without checking its address.
Browser trust
The console uses a certificate issued by the Manager CA. Browsers don't know this CA, so they show a certificate warning until you trust the Manager CA on the operator's workstation. Trust it on each workstation used to operate Cygna Forest Recovery, and confirm the fingerprint when you do. For the steps, see Trusting the Manager Certificate.
Because the server certificate covers every address of the Manager, a browser accepts it whether you open the console by IP address or by name, once the CA is trusted.
How cdr trusts the Manager
cdr checks the Manager's certificate the same way agents do: by CA fingerprint, not by address. The first time you connect to a Manager from an interactive prompt, cdr shows the fingerprint and asks you to confirm it against the console or the event log. If you confirm, it remembers the fingerprint for that Manager address and your Windows user, and checks it on every later connection.
A script or scheduled task has no prompt to answer, so it must supply the fingerprint explicitly with the --manager-ca option or the CYGNADR_MANAGER_CA environment variable. If the fingerprint is missing or does not match, cdr refuses to connect. For details, see Connecting and Signing In.