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.
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.
- 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.
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.
- 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:
- Defines a personal certificate label to use.
- The SSLCRLNL attribute specifies a namelist of authentication information objects which are used to provide certificate revocation locations to allow enhanced TLS certificate checking.
- On Windows , UNIX and Linux systems, sets the SSLCryptoHardware queue manager attribute. This attribute is the name of the parameter string that you can use to configure the cryptographic hardware you have on your system.
- Determines whether a TLS event message is reported if a channel using TLS fails to establish a TLS connection.
- 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.
- 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.
- 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:
- Defines a personal certificate label to use.
- Defines whether IBM MQ requires and validates a certificate from the TLS client.
- 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.
- Specifies the distinguished name (unique identifier) of allowed partners.