You might encounter the situation whereby you have a connection between two WebSphere MQ queue managers working successfully, confirming that network traffic can flow between your queue managers, however, when you enable SSL, you do not receive SSL related errors, and your channel appears to hang until eventually the connection times out.
There are two reasons typically responsible for this type of behavior.
The first and most common cause is that your queue manager is attempting to contact an external OCSP server to perform revocation checking of a digital certificate. This check is performed when certificates have AIA extensions containing OCSP URLs, such as Verisign and Entrust.
Note that in WebSphere MQ versions 7.0.1 and later, OCSP checking is turned on by default.
If there is no allowed route to the external OCSP server from the queue manager host, the local firewall will route the outbound tcp packets to the bit bucket without informing the sender. This leads to an eventual timeout on the sender side based on the local system's tcp settings. The default tcp timeout is typically 2 hours for most systems. Therefore, if you do not wait a full two hours before manually stopping the channel, you may never see the timeout occur.
There are a few ways to get around this issue if it is the cause of your channel staying in the binding status.
1. Enable outbound access from the queue manager to any OCSP servers needed
2. Turn off OCSP checking.
To do this, you edit the qm.ini of the affected queue manager, and under the SSL stanza, add OCSPCheckExtensions=NO
Note: You should only do this if you are sure you do not need to enforce AIA extensions checking.
Restart your queue manager after making changes to the qm.ini.
The second most common cause of channels remaining in binding status once you enable SSL is that ICMP messages are not able to flow between the sender and receiver hosts which would normally contain MTU messages. This type of traffic is needed when MTU Path Discovery is enabled on your systems which is used to negotiate TCP packet sizes between the sending and receiving queue managers.
Once you turn on SSL, packet sizes are often much larger because they contain certificate data during the certificate handshake phase. If the packet size is too large for the receiving end of the connection to accept, the packet is dropped. Since the sending side is not able under this circumstance to receive the ICMP message from the receiving end telling it to reduce its packet size before resending the packet, the sending side sends the same packet again. This behavior continues until the socket times out.
You can resolve this in one of two ways.
1. The preferred method is to allow ICMP messages to flow between both endpoints. Refer to your system documentation for further information.
2. You can reduce the MTU value to a value both systems can accept. Changes to MTU values usually require a system reboot in order to take affect.