Backing up and restoring a node's configuration from EJBCA Cloud 2.0 to another version of 2.0 or later allows the node to be automatically configured in a cluster using a Relational Database Service (RDS). This automatic method will also get the CloudHSM keys as well as TLS certificates automatically.

If a version prior to EJBCA Cloud 2.0 is installed or the instance is manually configured to point to RDS, please skip the first sections below and proceed to Manual RDS Configuration.

Wizard Based Configuration EJBCA CLOUD 2.1

The following describes how to configure nodes using the wizard as of version EJBCA Cloud 2.1.

The option to install into an existing EJBCA database requires additional manual configuration to copy the public keys that are required for EJBCA to read the private keys in the CloudHSM.

If the Existing EJBCA Database option is chosen with CloudHSM backed ManagementCA keys, after completing the following Wizard Based Configuration steps, perform the additional steps in the Automatic Configuration with Backup/Restore Scripts section below if running a version older than EJBCA 7.5.

To configure nodes (using the wizard as of version EJBCA Cloud 2.1):

  1. Launch the same quantity of nodes from the AWS Marketplace as is currently in production according to the AWS Launch Guide.
  2. If using a VIP in this EJBCA cluster, add the VIP address in the wizard Step 1: Host Settings.
  3. Select the option to use an Existing EJBCA Database in the configuration wizard at launch time.
  4. Wait for the node to boot using the configuration from the existing installation.
  5. Once the new nodes are running and connected to the RDS database, remove the old nodes from the load balancer (if used) and add the new ones.
  6. Confirm the new nodes are properly serving traffic.

If you enabled Existing EJBCA Database and are using CloudHSM backed ManagementCA keys, ensure to complete the additional steps in the Automatic Configuration with Backup/Restore Scripts section.

Automatic Configuration with Backup/Restore Scripts

To automatically configure with backup and/or restore scripts, using EJBCA Cloud version 2.0:

  1. Backup your cloud node according to instructions in the EJBCA Cloud AWS Backup Guide. 
  2. Launch another instance in AWS from the AWS Marketplace, according to the EJBCA Cloud AWS Launch Guide. 
  3. Pick the wizard defaults and install a local database. Note that this configuration will be overwritten when the node is clustered to the RDS database.
  4. Copy the backup file to the new instance.
  5. Run the /opt/PrimeKey/support/system_restore.sh script pointing it to the backup file you just copied to the new instance. For information on restoring a backup, see the EJBCA Cloud AWS Restore and Upgrade Guide.
  6. Generate new TLS certificates for the EJBCA host with the /opt/PrimeKey/support/new_tls_cert.sh script. For more information on how to use the new_tls_cert.sh script, see the EJBCA Cloud TLS Certificate Generation Guide.

Manual RDS Configuration

This procedure assumes that an EJBCA instance is running in AWS and it is connected to RDS and a second node for redundancy is needed:

  1. Launch another instance in AWS from the AWS Marketplace, according to the EJBCA Cloud AWS Launch Guide. Select the defaults and install a local database. Note that this configuration will be overwritten when the node is restored.

  2. SSH into the newly launched node and edit the datasource.properties file.

    vi /opt/PrimeKey/wildfly_config/datasource.properties
    BASH
  3. Edit the configuration so that it points to the RDS database using the password you configured. You can get these values from the RDS console, or from node 1. The file contains the following properties:
    • DATABASE_ADDRESS: The RDS address of the database in AWS.
    • DATABASE_NAME: The name of the database chosen in the EJBCA Cloud Configuration Wizard.
    • DATABASE_USERNAME: The name of the user chosen in the EJBCA Cloud Configuration Wizard.
    • DATABASE_PASSWORD: The password chosen in the RDS console when configuring the database.

  4. Restart WildFly:

    systemctl restart wildfly
    BASH

  5. Ensure the EJBCA UI loads correctly and that the contents of EJBCA match the installation on Node 1.

  6. Generate a new TLS certificate for the host from the RDS database. If you are going to use a VIP to load balance between the two nodes, add that into the certificate. For example, if using pki.company.com, add that with -d. This VIP should be in the TLS certificate on both nodes. If node 1 does not have the VIP in its certificate, run the following. For more information on how to use the new_tls_cert.sh script, see the EJBCA Cloud TLS Certificate Generation Guide.

    /opt/PrimeKey/support/new_tls_cert.sh -p -d pki.domain.com
    BASH

  7. Ensure the EJBCA UI loads and the data is consistent with Node 1.