Protecting channels with SSL/TLS

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.

You 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 your application, and for its use in production. You 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 your application you can use self-signed certificates or certificates issued by a local CA, depending on platform:

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

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

On z/OS®, you 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.

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.

Planning 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.

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. You can also specify details of the type of security you want, such as the encryption algorithm you want to use.