There are some special considerations that you should be aware of when using secure sockets layer (SSL) based transports for communication with messaging engines.
Some additional steps might be required to establish SSL-based or HTTPS-based connections between messaging engines, or between messaging engines and JMS applications running in a client container. This is because, for an SSL connection to be established successfully, the party that is initiating the connection and the party that is waiting for the connection to be made must both supply a compatible set of credentials.
When you are configuring the client container to bootstrap using an SSL-based transport chain, additional SSL properties might need to be specified in the sib.client.ssl.properties properties file. This file is located in the profile_root/properties directory of the application server installation, where profile_root is the directory in which profile-specific information is stored. The properties in this file are used for all client container bootstrapping activities over both SSL and HTTPS-based bootstrap chains.
When you are configuring SSL-based connections between two messaging engines, both the messaging engines must have inbound chains with matching names. These inbound chains must be configured with compatible sets of SSL credentials. This is true for both intra-bus messaging engine connections and for connections between messaging engines that are in different buses.
It is important to note that as there is no affinity between a particular inbound transport chain and a messaging engine. Any messaging engine that is active on a server can be contacted by any enabled inbound transport chain because, by default, an application server is created with unsecured inbound transport chains. You might therefore find it necessary to disable or delete these chains to restrict access to being through secure chains only.