Backup the Certificate Authority Server

This process is only meant to be used if your database machine has failed. This process is very fragile and extreme care must be taken. If any steps are performed out-of-order or incorrectly, the process will fail. It is recommended that you call Support to help with this process.

This topic is only meant for a fully-distributed multi-server ecosystem deployment.

The appliance in an FMOS ecosystem deployment that holds the certificate authority (CA) role requires a special backup and restore process. The content of the CA store is extremely sensitive, as it could be used to obtain unauthorized access to the FMOS ecosystem, potentially allowing an attacker to obtain or manipulate FireMon application data.

During normal use, the contents are encrypted using appliance-specific information. This is not possible for a backup file, so user-provided information is necessary to safely encrypt the backup.

For ecosystem deployments where the DB, ES, and AS roles are held by the same machine, backing up the CA store may not be necessary.

A new CA store can be initialized on the target appliance without disrupting any intra-ecosystem communication.

FMOS will issue an alert when a new backup should be created:

ALERT: The Certificate Authority store needs to be backed up

This alert appears in one of two circumstances:

  • The CA store has never been backed up

  • The CA store index has been modified (for example when a new certificate was issued) since the last time the CA store was backed up

The alert will clear automatically once a new backup has been created.

Backing up the CA Store

To back up the FMOS CA store, the fmos ca backup command is used. The program will prompt to enter an Export Passphrase, which will be used to derive an encryption key to protect the sensitive parts of the backup. This example will create an CA backup file in the current working directory, named for the host name of the machine and the current date:

fmos ca backup fmos-ca_$(hostname -s)_$(date +%Y-%m-%d).tar.xz

Restoring the CA Store from Backup

This process is very fragile and extreme care must be taken. If any steps are performed out-of-order or incorrectly, the process will fail. It is recommended that you call Support to help with this process.

Using certificates signed by the desired CA requires a special process. If this process is not followed, a new CA will be created, and certificates will be signed by it.

Follow this process when restoring a CA store from a backup onto a different machine, or after FMOS has been reinstalled on the same machine.

To restore the CA store from a backup file, use the fmos ca restore command, passing the name of the backup file as an argument on the command line, and then entering the Export Passphrase when prompted.

The destination machine must not hold any FMOS roles. This is achieved by choosing Existing Deployment on the Ecosystem Selection page of the Initial Configuration Wizard. If the machine already has one or more roles, it must be re-provisioned.

  1. Put the application server into maintenance mode.

fmos maintenance begin

  1. Promote a standby database VM (db2 in example).

fmos ecosystem promote

  1. Clean up glusterfs on the previous database server.

busctl call com.firemon.fmos1 / com.firemon.fmos.gluster.GlusterService remove_brick ss firemon db1.mydomain.com:/var/lib/glusterfs/volumes/firemon/brick

busctl call com.firemon.fmos1 / com.firemon.fmos.gluster.GlusterService detach_peer s db1.mydomain.com

  1. On the local machine, move ca_backup from host.

scp ca_backup user@db2.mydomain.com:/home/user/ca_backup

  1. Restore CA on promoted standby database server (db2).

fmos ca restore ca_backup

fmos ecosystem recover-ca

  1. Switch over the application server.

fmos ecosystem switchover db2.mydomain.com

  1. Restore the regular FMOS backup. See Restore a Backup for details.

The machine is now fully restored, and will operate as a CA, using the exact hierarchy as the original machine. All certificates issued by the previous machine will continue to be valid, and new certificates will be signed using the same keys.