+

Search Tips | Advanced Search

Protecting channels with SSL/TLS

TLS support in IBM MQ uses the queue manager authentication information object, and various MQSC commands. We must also consider your use of digital certificates.


Digital certificates and key repositories

It is good practice to set the queue manager certificate label attribute ( CERTLABL ) to the name of the personal certificate to be used for the majority of channels, and override it for exceptions, by setting the certificate label on those channels that require different certificates.

For many channels with certificates that differ from the default certificate set on the queue manager, we should consider dividing the channels between several queue managers or use an MQIPT proxy in front of the queue manager to present a different certificate.

We can use a different certificate for every channel, but if you store too many certificates in a key repository, you might expect performance to be affected when starting TLS channels. Try to keep the number of certificates in a key repository to less than about 50 and consider 100 to be a maximum as GSKit performance decreases sharply with larger key repositories.

Allowing multiple certificates on the same queue manager increases the chances that multiple CA certificates will be used on the same queue manager. This increases the odds of certificate Subject Distinguished Name namespace clashes for certificates issued by separate certificate authorities.

While professional certificate authorities are likely to be more careful, in-house certificate authorities often lack clear naming conventions and you could end up with unintended matches between one CA and another.

We should check the certificate Issuer Distinguished Name in addition to the Subject Distinguished Name. To do this, use a channel authentication SSLPEERMAP record and set both the SSLPEER and SSLCERTI fields to match the Subject DN and Issuer DN respectively.


Self-signed and CA-signed certificates

It is important to plan your use of digital certificates, both when we are developing and testing the application, and for its use in production. We can use CA-signed certificates or self-signed certificates, depending on the usage of our queue managers and client applications.

Self-signed certificates are not suitable for production use, for the following reasons:

  • Self-signed certificates cannot be revoked, which might allow an attacker to spoof an identity after a private key has been compromised. CAs can revoke a compromised certificate, which prevents its further use. CA-signed certificates are therefore safer to use in a production environment, though self-signed certificates are more convenient for a test system.
  • Self-signed certificates never expire. This is both convenient and safe in a test environment, but in a production environment it leaves them open to eventual security breaches. The risk is compounded by the fact that self-signed certificates cannot be revoked.
  • A self-signed certificate is used both as a personal certificate and as a root (or trust anchor) CA certificate. A user with a self-signed personal certificate might be able to use it to sign other personal certificates. In general, this is not true of personal certificates issued by a CA, and represents a significant exposure.


CipherSpecs and digital certificates

Only a subset of the supported CipherSpecs can be used with all of the supported types of digital certificate. It is therefore necessary to choose an appropriate CipherSpec for the digital certificates. Similarly, if your organization's security policy requires that a particular CipherSpec be used, then we must obtain suitable digital certificates.

For more information on the relationship between CipherSpecs and digital certificates, refer to Digital certificates and CipherSpec compatibility in IBM MQ


Certificate validation policies

The IETF RFC 5280 standard specifies a series of certificate validation rules which compliant application software must implement in order to prevent impersonation attacks. A set of certificate validation rules is known as a certificate validation policy. For more information about certificate validation policies in IBM MQ, see Certificate validation policies in IBM MQ.


Plan for certificate revocation checking

Allowing multiple certificates from different certificate authorities potentially causes unnecessary additional certificate revocation checking.

In particular, if you have explicitly configured the use of a revocation server from a particular CA, for example by using an AUTHINFO object or Authentication information record (MQAIR) structure, a revocation check fails when presented with a certificate from a different CA.

We should avoid explicit certificate revocation server configuration. Instead, we should enable implicit checking where each certificate contains its own revocation server location in a certificate extension, for example, CRL Distribution Point, or OCSP AuthorityInfoAccess.

For more information, see OCSPCheckExtensions and CDPCheckExtensions.


Commands and attributes for TLS support

The Transport Layer Security (TLS) protocol provides channel security, with protection against eavesdropping, tampering, and impersonation. IBM MQ support for TLS enables you to specify, on the channel definition, that a particular channel uses TLS security. We can also specify details of the type of security we want, such as the encryption algorithm we want to use.

  • The following MQSC commands support TLS:

      ALTER AUTHINFO
      Modifies the attributes of an authentication information object.

      DEFINE AUTHINFO
      Creates an authentication information object.

      DELETE AUTHINFO
      Deletes an authentication information object.

      DISPLAY AUTHINFO
      Displays the attributes for a specific authentication information object.

  • The following queue manager parameters support TLS:

      CERTLABL
      Defines a personal certificate label to use.

      SSLCRLNL
      The SSLCRLNL attribute specifies a namelist of authentication information objects which are used to provide certificate revocation locations to allow enhanced TLS certificate checking.

      SSLCRYP
      On Windows, UNIX and Linux systems, sets the SSLCryptoHardware queue manager attribute. This attribute is the name of the parameter string used to configure the cryptographic hardware you have on the system.

      SSLEV
      Determines whether a TLS event message is reported if a channel using TLS fails to establish a TLS connection.

      SSLFIPS
      Specifies whether only FIPS-certified algorithms are to be used if cryptography is carried out in IBM MQ, rather than in cryptographic hardware. If cryptographic hardware is configured, the cryptographic modules provided by the hardware product are used, and these might be FIPS-certified to a particular level. This depends on the hardware product in use.

      SSLKEYR
      On UNIX, Linux, and Windows systems, associates a key repository with a queue manager. The key database is held in a GSKit key database. The IBM Global Security Kit (GSKit) enables you to use TLS security on Windows, UNIX and Linux systems.

      SSLRKEYC
      The number of bytes to be sent and received within a TLS conversation before the secret key is renegotiated. The number of bytes includes control information sent by the MCA.

  • The following channel parameters support TLS:

      CERTLABL
      Defines a personal certificate label to use.

      SSLCAUTH
      Defines whether IBM MQ requires and validates a certificate from the TLS client.

      SSLCIPH
      Specifies the encryption strength and function (CipherSpec), for example TLS_RSA_WITH_AES_128_CBC_SHA. The CipherSpec must match at both ends of channel.

      SSLPEER
      Specifies the distinguished name (unique identifier) of allowed partners.

This section describes the setmqaut, dspmqaut, dmpmqaut, rcrmqobj, rcdmqimg, and dspmqfls commands to support the authentication information object. It also describes the runmqckm (iKeycmd) command for managing certificates on UNIX and Linux systems, and the runmqakm tool for managing certificates on UNIX, Linux, and Windows. See the following sections:

For an overview of channel security using TLS, see

For details of MQSC commands associated with TLS, see

For details of PCF commands associated with TLS, see

Parent topic: Channel authorization

Last updated: 2020-10-04