In order to exchange data, the MQ Light client connects to the MQ Light server over a network. To protect against malicious attempts to redirect the network connection such that connectivity is established to some other server than is intended, steps can be taken to validate that the server is the MQ Light server that is expected.
The following unwanted scenarios are possible when a MQ Light client is redirected to an unknown server:
- Message data sent and received by the MQ Light client and server can be read, and potentially the message payload can be changed to contain different data.
- Username/Password values that the client uses to authenticate with the MQ Light server can be captured, and used to impersonate the client.
If you are using MQ Light in an environment where you do not have complete control over the systems connected to the same network as the MQ Light server, you can configure the MQ Light client to validate the identity of the server it connects to. The MQ Light client can use capabilities of the SSL/TLS protocols to help establish the identity of the server it is connecting to, and ensure that the client is not misdirected to some other server. For more information, see Protecting communication with the MQ Light server.
The SSL/TLS protocol provides a method for a server to be assigned a certificate that it can use to identify itself, as well as a private key that it can use to prove that it owns the certificate. Clients that need to connect to a server can confirm its authenticity by inspecting the certificate. The MQ Light client can check the validity of a server’s certificate in the following ways:
- By default, the client can check that the host name information present in the certificate matches the host name of the server that the client has connected to. This guards against the possibility that the client’s connection has been redirected to another server.
- The client can be provided with a certificate (but not a private key) which is compared to the certificate that the server presents during connection. This can be used to provide a client with specific instructions about which server, or servers, it should trust.
Depending on how SSL/TLS is used, each server can be given its own certificate either by creating self-signed certificates, or by using a certificate authority that can be used to generate a set of related certificates through a signing process. When a certificate authority is used, clients can be configured to trust the certificate authority and all certificates it has subsequently signed, which reduces the degree to which each client needs to be provided with its own unique set of certificates to trust.
When SSL/TLS security is being configured for an MQ Light deployment, the following configuration options are available to enable an MQ Light client to validate the identity of the MQ Light server:
- Create a self-signed certificate for each MQ Light server. Each certificate you create will be unrelated to any of the other certificates. Each time a client needs to connect to an MQ Light server, you will need to ensure that a copy of the server’s certificate is made available to the client.
- Use the services provided by a certificate authority to sign each certificate used by an MQ Light server. Each MQ Light client can be configured with the same certificate, so that the certificate authority is trusted.
Note: When the MQ Light server is configured to use SSL/TLS security, it will use the same certificate to identify itself to both the MQ Light client and also web browsers connecting to the MQ Light User Interface. If you decide to use a self-signed certificate, then a copy of this certificate will not be present amongst the certificates that your web browser trusts. Your web browser can display a warning when you connect to the MQ Light User Interface. To prevent this from happening, you can instruct your browser to trust the certificate provided by MQ Light, or switch to using certificates signed by a certificate authority that your browser trusts.
The following MQ Light Node.js API properties determine how a client uses SSL/TLS protocols to connect to the MQ Light server:
serviceproperty is used to determine when the SSL/TLS protocol is used. It must be set to a URL that starts with the amqps:// protocol in order for the properties to take effect.
- The optional
sslTrustCertificateproperty can be used to specify the location of a certificate that will be checked against the server’s certificate. The certificate must be in PEM format and should be stored on a filesystem which is accessible to the user running the client. To prevent the risk of an MQ Light client being redirected to an unknown server, you can restrict which operating system users are allowed to write to the file containing the certificate.
sslVerifyNameproperty controls whether the MQ Light client checks that the host name information in a server’s certificate matches the host name that it was instructed to connect to. This is set to true by default, and requires the
sslTrustCertificateproperty to be set to have any effect. Do not change this setting unless you do not have control over the configuration of the MQ Light server and it was setup with a certificate that does not contain host name information.