Secure replication for a high availability queue manager

You can specify that replication links in your HA configuration are secured with TLS.

When you create a high availability (HA) queue manager, you can specify that the links used to replicate data between the queue manager instances are secured with TLS.

To configure secure replication, complete the following steps:

Configure the required certificates.
Start the TLS Replication Handshake daemon (tlshd).
Specify the -re option when creating a new queue manager using crtmqm.

Complete the first two steps once per appliance. The certificates and tlshd configuration are shared by all HA queue managers on the appliance that are configured to use secure replication links.

Configuring certificates

You must configure the certificates to be used by the replication links. The certificates that you create for each appliance can be used by any replication links. If you have more than one HA queue manager on an appliance that uses secure replication links, the same certificate is used.

Note:

If any queue manager that runs on an appliance might ever be part of a DR/HA configuration, then the certificates that are used by the replication links must contain a Subject Alternative Name (SAN) that contains the HA group name. The createcert and createcertrequest commands set the SAN to the HA group name when the certificate, or certificate request, is created. Ensure that the SAN is copied to the signed certificate when the certificate request is signed by the certificate authority.

The HA group name of HA pairs connected with DR can be the same for both HA groups, or unique to each HA group. In both cases, the name of the remote HA group must be specified by using the -san parameter of the crtdrprimary command. The crtdrprimary and dspdrsecondary commands will generate the crtdrsecondary command with the required value for the -san parameter.

The private key required for encryption replication is created on the appliance, with a certificate signing request (CSR) generated. The CSR is made available in the mqpubcert: URI for downloading and sending for signing. The signed certificate and CA certificates are uploaded to the mqpubcert: URI, from which the certificate management commands add them to the key store.

Note: The examples use the default certificate label of mq_replication, to use a different certificate label add the -l parameter to the createcertrequest, receivecert, and setrepcert commands.

To use secure replication links in an HA configuration you need two certificates, one certificate per appliance in the HA group.

To create and sign a certificate, the following sequence is required on each appliance:

Use the following command to generate a private key and a certificate signing request (CSR):

mqa(mqcli)# createcertrequest -replication -dn CN=MainSiteAppliance1.example.com,O=JOJO;C=UK;OU=Hillesden

The CSR is created in mqpubcert:. Copy the CSR from the appliance and send it for signing by the CA. On return, copy the signed certificate to mqpubcert:, along with the full chain of CA certificates.

Add the CA certificates and receive the signed certificate:

mqa(mqcli)# addcert -replication -file mqpubcert://TheCA.crt -label CA
mqa(mqcli)# receivecert -replication -file mqpubcert:///mq_replication.signed

Repeat these steps on all other appliances within the HA configuration.

TLS Replication Handshake daemon

The implementation of encryption on replication links relies on the TLS Replication Handshake daemon (tlshd) to handle the TLS replication handshake. This daemon needs to be configured and started before any TLS handshakes can be completed. A single tlshd certificate configuration is used for all encrypted replication for any given appliance.

The key and certificates, and underlying files are managed by the certificate management commands (see Configuring certificates).

You use the setrepcert -e command to enable the TLS replication handshake daemon. This command starts the daemon, after which it is monitored to ensure it is running, and restarted as required (including during appliance restart). If the key and certificate configuration are incomplete or invalid, the setrepcert -e command fails.

You can disable the TLS replication handshake daemon by using the setrepcert -d command. This command fails if any HA or DR queue managers exist with replication encryption enabled.

If the key or certificates are changed, for example, to replace expiring certificates, the TLS replication handshake daemon continues to use the existing configuration until it is next restarted. To trigger an immediate restart use the setrepcert -r command.

Use the dsprepcert command to see the current state of the daemon. The following states can be reported:

Not configured - No keys and certificates have been configured and the TLS replication handshake daemon has not been enabled.
Disabled - A valid set of keys and certificates have been configured, the TLS replication handshake daemon has not been enabled.
Enabled - The TLS replication handshake daemon has been enabled but is not running.
Running - The TLS replication handshake daemon has been enabled is running.

The dsprepcert command also displays the label of the private key and certificate, and the time at which the TLS Handshake daemon was last started.

Creating the HA Queue Manager

You create an HA queue manager with secure replication links by using the crtmqm command with the -re option, for example:

mqa(mqcli)# crtmqm -sx -re HAqm

Alternatively, to add an existing queue manager to the HA group:

mqa(mqcli)# sethagrp -i -re MyQMgr

For more information about creating an HA, see Configuring high availability queue managers.