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 an Azure Database for MariaDB servers.

If an older version before the wizard-based installation is configured or the instance is manually configured to point to the Azure Database for MariaDB server, please skip the first sections below and proceed to Manual Azure Database for MariaDB 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.

If the Existing EJBCA Database option is chosen with Azure Key Vault backed ManagementCA keys, you must supply the Azure Key Vault Credentials to join the cluster.  Please see the documentation on configuring Azure Key Vault with EJBCA Cloud.

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 Azure 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 Azure Database for MariaDB server 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.

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 Azure Backup Guide. 
  2. Launch another instance in Azure from the Azure Marketplace, according to the EJBCA Cloud Azure 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 Azure 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 Azure Database for MariaDB Configuration 

This procedure assumes that an EJBCA instance is running in Azure and it is connected to Azure Database for MariaDB server and a second node for redundancy is needed:

  1. Launch another instance in AWS from the AWS Marketplace, according to the EJBCA Cloud Azure 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 Azure Database for MariaDB server database using the password you configured. You can get these values from the Azure Database for MariaDB server 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 Azure Database for MariaDB server 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.