Secure replication for DR/HA RDQM

To configure your certificates complete the following steps for each node in your RDQM configuration:

1. Use the following command to generate a private key:

   openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out key_file

   where key_file is the name of the file that is created to store the private key.
2. Create a certificate signing request.
   In a RDQM DR/HA configuration, the certificate that you create must meet the following requirements:

   • The certificate Common Name (CN) must be set to the hostname of the RDQM node.
   • The certificate Subject Alternative Name (SAN) must contain both the hostname of the RDQM node and a group DNS name. The group DNS name defaults to the value encrypted.remote. If required, you can specify a different group DNS name.

     The same group DNS name can be used by both HA groups, or you can specify a different name for each HA group.

     Every node in a HA group must use certificates with the same group DNS name in the SAN.

     If you do not use the default value of encrypted.remote in the SAN when the certificate is created, you must specify the group DNS name for the local and remote HA groups by using the -san parameter on the crtmqm command when the queue manager is created.

   Use the following command to create a certificate signing request:

   openssl req -key key_file -subj "/CN=hostname"
               -addext "subjectAltName = DNS:hostname,DNS:group_dns_name"
               -new -out cert_req_file

   where:

   • key_file is the file that contains the private key that you created in step 1.
   • hostname is the hostname of the node.
   • group_dns_name is the group DNS name. To use the default value for the group DNS name, specify encrypted.remote.
   • cert_req_file is the file that is created to store the certificate signing request.
3. Send the certificate signing request to your certificate authority (CA) to be signed. When you receive the signed certificate from the CA, copy the private key, signed certificate, and CA certificate files to the directory where you want to store these files. For example, the /etc/drbd.d/ directory.
4. Set the file permissions and ownership of the private key and certificate files to ensure that only the root user can view the private keys.
   • Change the ownership of the private key and certificate file to the root user.
   • Set the permissions on the private key file so that only the root user has read and write access.

The following example script creates an internal certificate authority and three certificates for use in a RDQM DR/HA configuration.

Run the following script on one of the nodes in your primary HA group:

#!/bin/bash

# The CA name
ca_name="RDQM Test CA"

# The CA filename
ca_filename="rdqm_test_ca"

# Host certificates to generate
test_hosts=("alice" "bob" "charlie")

mkdir certificates && cd ./certificates

# Create private key for use with private CA using OpenSSL
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 \
-out $ca_filename.key

# Create a private CA certificate using OpenSSL
openssl req -key $ca_filename.key -new -x509 -days 3650 -subj "/CN=$ca_name" \
-out $ca_filename.crt

# Create certificates for each node
for host in ${test_hosts[@]}; do

    # Create a private key
    openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 \
    -out $host.key

    # Generate a CSR
    openssl req -key $host.key -subj "/CN=$host"  \
    -addext "subjectAltName = DNS:$host,DNS:encrypted.remote" \
    -new -out $host.csr

    # Create a valid certificate signed by the private CA
    openssl x509 -req -in $host.csr -CA $ca_filename.crt \
    -copy_extensions copyall -CAkey $ca_filename.key -CAcreateserial \
    -days 365 -out $host.crt

    # Remove sequential serial number
    rm -f $ca_filename.srl

    # Remove CSR
    rm -f $host.csr

done

The example generates the following files in the certificates directory on the node in the primary group:

• rdqm_test_ca.crt
• rdqm_test_ca.key
• alice.crt
• alice.csr
• alice.key
• bob.crt
• bob.csr
• bob.key
• charlie.crt
• charlie.csr
• charlie.key

Deploy the certificates by completing the following steps:

1. Copy the CA certificate (rdqm_test_ca.crt) to each node’s /etc/drbd.d/ directory. (These are example paths, you can choose another location if required.)
2. Copy each node’s certificate (.crt file) and private key (.key file) to /etc/drbd.d/. (These are example paths, you can choose another location if required.)
3. Change file permissions and ownership for the private keys and certificate on each node. This ensures that only the root user can view the contents of the private keys:

   chmod 600 /etc/drbd.d/*.key
   chown root:root /etc/drbd.d/*.key 
   chown root:root /etc/drbd.d/*.crt

4. Store the certificate authority's private key in a secure location.

[debug]
loglevel=0
tls=0
nl=0

[authenticate]
#keyrings= <keyring>;<keyring>;<keyring>

[authenticate.client]
#x509.truststore= <pathname>
#x509.certificate= <pathname>
#x509.private_key= <pathname>

[authenticate.server]
#x509.truststore= <pathname>
#x509.certificate= <pathname>
#x509.private_key= <pathname>

Before enabling and starting the tlshd service, you must specify values for the following properties in both the authenticate.client and authenticate.server sections (DRBD can establish its connections in either direction, unless there is a firewall blocking one direction):

x509.truststore

The path to the file that contains the certificate of the CA that signed the certificates used by the RDQM nodes. If a complex trust chain is required, it must be captured in a single file.

x509.certificate

The path to the file that contains the CA-signed certificate for the RDQM node.

x509.private_key

The path to the file that contains the private key for the RDQM node. The file must be owned by root and read/write permissions must be granted to only the root user.

The paths that are specified in these properties must all identify local files.

You can also optionally specify a certificate revocation list (CRL). You must set this in both the authenticate.client and authenticate.server sections:

x509.crl

The path to a file containing PEM-encoded certificate revocation lists (CRL) that are to be used to verify the revocation status of certificates during each handshake. If this option is not specified, CRL checking is skipped.

If you created the certificates using the example script in Configuring certificates, then you would configure the file as follows for server alice:

[authenticate.client]
x509.truststore=/etc/drbd.d/rdqm_test_ca.crt
x509.certificate=/etc/drbd.d/alice.crt
x509.private_key=/etc/drbd.d/alice.key

[authenticate.server]
x509.truststore=/etc/drbd.d/rdqm_test_ca.crt
x509.certificate=/etc/drbd.d/alice.crt
x509.private_key=/etc/drbd.d/alice.key

Before you enable the service for the first time, enter the following command:

systemctl daemon-reload

To start the tlshd service, enter the following command:

systemctl enable --now tlshd

You create a DR/HA queue manager with secure HA and DR replication links by using the crtmqm command with the -re option, for example, for the primary instance in the primary group:

crtmqm -sx -rr p -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -re <DRHAQueueManagerName>

You run the following command on each of the other nodes in the primary group to create the secondary instances:

crtmqm -sxs -rr p -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -re <DRHAQueueManagerName>

You create the primary instance in the secondary group by using the following command:

crtmqm -sx -rr s -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -re <DRHAQueueManagerName>

You run the following command on each of the other nodes in the secondary group to create the secondary instances:

crtmqm -sxs -rr s -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -re <DRHAQueueManagerName>

To secure only the HA replication links in the group, specify the -reh option in the commands. For example:

crtmqm -sx -rr p -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -reh <DRHAQueueManagerName>

To secure only the DR replication link between the groups, specify the -red option in the commands. For example:

crtmqm -sx -rr p -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -red <DRHAQueueManagerName>

The previous examples assume that, where a secure DR replication link is required, you have created certificates for each of the nodes using the default value of encrypted.remote for the group DNS name in the certificate's SAN. Where you have created certificates using a different value, you must specify this value when you create the queue manager by using the -san option. For example:

crtmqm -sx -rr p -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -red -san <customSubjectAltName> <DRHAQueueManagerName>

If you have used the same group DNS name in the certificates for both groups, then specify the value by using the -san <customSubjectAltName> option in all the crtmqm commands that create the DR/HA RDQM configuration.

If you have used a different group DNS name in the certificates for each HA group, then specify the group DNS names in the certificates of both the primary and secondary HA groups as comma-separated values, when creating the queue manager in each group. The following command creates the primary queue manager in the primary HA group:

crtmqm -sx -rr p -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -red -san <primarySubjectAltName>,<secondarySubjectAltName> <DRHAQueueManagerName>

The following command creates the primary queue manager on the secondary HA group:

crtmqm -sx -rr s -rl <Local_IPs> -ri <Recovery_IPs> -rp <DRPort> -red -san <secondarySubjectAltName>,<primarySubjectAltName> <DRHAQueueManagerName>

(You can specify either the -re or -red option in these examples.)