[MQ 10 2026][MQ 10 2026]

Secure replication for a disaster recovery queue manager

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

When you create a disaster recovery (DR) 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:
  1. Configure the required certificates.
  2. Start the TLS Replication Handshake daemon (tlshd).
  3. Specify the -re option when creating a new queue manager using crtdrprimary.
Complete the first two steps once per appliance. The certificates and tlshd configuration are shared by all DR 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 DR 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 label name to the createcertrequest, receivecert, and setrepcert commands.
To create and sign a certificate, the following sequence is required on each appliance:
  1. 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
  2. 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.
  3. 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
  4. Repeat these steps on all other appliances within the DR 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 DR Queue Manager

You create an DR queue manager with secure replication links by using the crtdrprimary command with the -re option, for example:
mqa(mqcli)# crtdrprimary -m MyQMgr -r RecoverySiteAppliance1,RecoverySiteAppliance2 -i 10.2.1.0,10.2.2.0 -p 9876 -re
Queue manager MyQMgr is prepared for Disaster Recovery replication.
Now execute the following command on appliance RecoverySiteAppliance1:
crtdrsecondary -m MyQMgr -s 32G -l MainSiteAppliance1,MainSiteAppliance2 -i 10.1.1.0,10.1.2.0 -p 9876 -t a -v 10.2.1.0,10.2.2.0 -re -san MainSite
The crtdrprimary command succeeded.
Create the Secondary DR configuration on the other appliance by running the crtdrsecondary command that was returned by the crtdrprimary command, for example:
mqa(mqcli)# crtdrsecondary -m MyQMgr -s 32G -l MainSiteAppliance1,MainSiteAppliance2 -i 10.1.1.0,10.1.2.0 -p 9876 -t a -v 10.2.1.0,10.2.2.0 -re -san MainSite

For more information about creating a DR, see Configuring disaster recovery for queue managers and crtdrprimary.