What is Server name Indication?

Server name indication was added to the TLS 1.2 specification to allow TLS clients to provide a hint to proxies, or servers what the connection’s destination is without the need to decrypt the TLS secured traffic. This allowed servers to correctly server the destination TLS certificate without needing to complete the TLS handshake and so enabled the destination certificate used for TLS.

Before server name indication was added, when multiple hosts were hosted on a single machine (and a single IP address) the machine would have to complete the TLS handshake with its TLS certificate as the identity and then inspect the first packets to decide which endpoint or process needed to handle the connection.

This would cause issues if multiple web servers were running on a single machine and each server wanted to use its own certificate. With the addition of Server name indication, the machines network interface could examine the SNI header and use an internal mapping table to forward the connection to the correct webserver. This allowed each webserver to use their own individual certificate and ensure complete end-to-end encryption.

How does IBM MQ use it?

In version 8 of IBM MQ included the “Multiple Certificates” feature. This feature allowed users to define a different certificate a queue manager could use for its TLS identity on a per-channel basis. Prior to this, only one certificate was used for every connection to a queue manager. The reason for this was the same issue that multi-site hosting physical servers had; to know what MQ channel a connection was destined for the TLS handshake had to resolve and the first MQ packets had to be received.

To enable different certificates on the MQ channels, Server name indication was used. But instead of the SNI header being set to the destination hostname, IBM MQ sets it to a channel name converted into a hostname. The details of how exactly IBM MQ converts a channel name into a hostname is available in this documentation page.

By doing this, IBM MQ queue managers could present different certificates for different channels. However, by using the SNI header for this mechanism any users wanting to use a proxy or routing system (such as OpenShift routes) to route IBM MQ connections would need to configure their routes appropriately. To help users who wanted to set a hostname as the routing rule the outboundSNI configuration option was added into version 9.2.1 of IBM MQ.

The outboundSNI setting.

The outboundSNI setting allows users to configure IBM MQ Clients to set the SNI header of connections to either the destination MQ channel name or the destination hostname. By changing this configuration users can control what SNI header is set by IBM MQ Clients.

The two options are:

• HOSTNAME = Set the SNI header to the hostname of the connection name (or omit if an IP address is supplied for the connection name.)
• CHANNEL = Set the SNI header to the IBM MQ channel name converted to a hostname.

To control the SNI header in C client or unmanaged .NET client users can set the outboundSNI property in the SSL stanza of the Client configuration file. For Java & JMS applications users can either use the client configuration file or via the ‘com.ibm.mq.cfg.SSL.outboundSNI’ java environment setting. For managed .NET set the property MQC.OUTBOUND_SNI_PROPERTY.

Considerations for each setting

Setting OutboundSNI to hostname or channel has its advantages and disadvantages.

Hostname

When set to hostname, multiple certificates functionality will not work. Client applications connecting to a queue manager will always receive the certificate set on the queue manager object. Additionally, if these clients connect to a channel which has a certificate set on it, the connection will fail as IBM MQ verifies the correct certificate was sent to the client.

For those users planning to connect to queue managers running in the IBM MQ Saas offering, this setting is a requirement.

Channel name.

When using channel name, the main disadvantage is having to calculate the SNI value if you plan to use that for routing. It is possible to use a channel name SNI header for routing, but any queue managers that a router could send to must have unique channel names. Additionally, channel names may have to be carefully named  to ensure that the hostname produced is valid. For example, a channel name of “chl” becomes 63-68-6c-.chl.mq.ibm.com, which is not a valid hostname.

Conclusion

In conclusion, either setting is valid, and it is a matter of planning how your client applications will connect and your business needs which will control the setting you should be using.

Converting Channel name to Hostname

If you plan to configure your routing based on the channel name and need to quickly convert what the hostname will be, i wrote a small java tool that will do that for you. You can find that here: https://github.com/parrobe/mq-chl-to-sni

#Highlights-home