Protecting channels with SSL/TLS

TLS support in IBM MQ uses the queue manager authentication information object, and various MQSC commands. You 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.

If you need many channels with certificates that differ from the default certificate set on the queue manager, you 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.

You 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 you are developing and testing our application, and for its use in production. We can use CA-signed certificates or self-signed certificates, depending on the usage of your queue managers and client applications.

CA-signed certificates

For production systems, obtain your certificates from a trusted certificate authority (CA). When you obtain a certificate from an external CA, you pay for the service.

Self-signed certificates

While you are developing our application we can use self-signed certificates or certificates issued by a local CA, depending on platform:

On Windows, UNIX, and Linux systems, we can use self-signed certificates. See Creating a self-signed personal certificate on UNIX, Linux, and Windowsfor instructions.

On IBM i systems, we can use certificates signed by the local CA. See Requesting a server certificate on IBM i for instructions.

On z/OS®, we can use either self-signed or local CA-signed certificates. See Creating a self-signed personal certificate on z/OS or Requesting a personal certificate on z/OS for instructions.

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 your digital certificates. Similarly, if your organization's security policy requires that a particular CipherSpec be used, then you 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 we 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.

You should avoid explicit certificate revocation server configuration. Instead, you 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 you want, such as the encryption algorithm you 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 that we can use to configure the cryptographic hardware we have on your 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 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:

• setmqaut
• dspmqaut
• dmpmqaut
• rcrmqobj
• rcdmqimg
• dspmqfls
• Managing keys and certificates

For an overview of channel security using TLS, see

• TLS security protocols in IBM MQ

For details of MQSC commands associated with TLS, see

• ALTER AUTHINFO
• DEFINE AUTHINFO
• DELETE AUTHINFO
• DISPLAY AUTHINFO

For details of PCF commands associated with TLS, see

• Change, Copy, and Create Authentication Information Object
• Delete Authentication Information Object
• Inquire Authentication Information Object