Idea Details

MQ Powerpack - connect with bindings enhancement

Last activity 05-04-2016 08:27 AM
Anon Anon's profile image
05-04-2016 08:27 AM


Hi Guys,


id like to share the following proposal for amending the connection model for MQ powerpack to look at providing an option for bindings mode, as well as connecting via svrconn. Obviously everyone has a different implementation approach for their own respective infrastructure, but for us personally this addition would bring a great reduction in maintenance overhead and ease of deployment.


Please take 5 to have a read through this high level summary, and vote up if you think this could be of use for you in your implementation! thanks in advance....


High Level Technical Summary:


Due to the number of high profile vulnerabilities exposed both within Java and also within various Ciphersuites over the past 12/18 months, the company I work for has been trying to both improve the patching process we currently have in place for our estate, and looking to move away from compromised cipher suites. Our implementation of MQ powerpack will see an agent per host across in the region of a thousand MQ instances processing a mixture of classifications of data. Our current implementation is per the CA standard installation guides and consists of :


  • Creating a client connection channel on a Qmanager
  • Creating a keystore with a valid certificate and certificate chain to connect to the Qmanager
  • Modifying various properties files within the agent installation to allow the agent to connect over the MQ listener to the Qmanager to retrieve various metrics based on the content of user defined and system queues on the Qmanager.


This approach for us has a number of flaws:


  • The way we manage certificates means that we regularly change certificate signing authorities and have an upper limit on the expiry time we give to certificates – this means we will eventually have 1000+ agents that will need certificate keystores managing and updating.
  • We are discouraged from using self signed certs in the majority of cases meaning this is not an option.
  • We regularly change the ciphersuite we use for connecting to MQ instances to ensure the cipher in use has not been compromised. This means best case we have 1000+ Qmanagers that will need the channel definition changing, agent definition changing and an agent restart for this to take effect.
  • Java  patching causes additional problems – the inbuilt security mechanisms within certain JREs are causing massive problems with us using deprecated cipher suites – we have had a longstanding issue with getting wily MQ PP to work with TLS due to the JREs that we have not supporting the cipher. We at present could break the connectivity between the MQ agent and the MQ instances each time we patch Java.


Our suggestion:


I believe the best way forward for us given our implementation model is to allow the use of a bindings connection to a MQ instance. In the vast majority of cases, as the agent is running on the same host as the Qmanager for our implementation, there is no need to connect over a svrconn channel. The use of bindings mode would bring the following benefits:


  • No need to use a client connection channel. This means no cipher suites to manage, no certificates to manage greatly reducing our overhead on maintenance.
  • Because the agent runs as the mqm user, there would be no need to amend any security settings within OAM or create an MCAuser and group as there is at present. The agent will be able to connect to the Qmanager and pull whatever information it needs further reducing implementation effort and ongoing maintenance.
  • The amount of configuration within the agent would be reduced. There would be no need to specify what cipher spec to use anymore, nor provide connection IP/DNS names, port numbers and alike further reducing the amount of configuration required.
  • Patching of Java would be less of a concern – using a bindings mode removes the risk of patching JREs adding additional security settings which could break our agent installations.





In short for our company, and I suspect for a number of other CA customers, the IT landscape is becoming more focused than ever before on providing secure IT infrastructure on which to do business. Regular patching cycles and the deprecating of standards that have been shown to have vulnerabilities is becoming increasingly more common place, meaning an element of management needs to be factored in to any solution that looks to connect into a secured messaging interface remotely. In order for our implementation to work effectively, and to reduce the ongoing maintenance of the CA MQ powerpack estate, we would find it highly beneficial to have this code change implemented.


thanks for taking the time to read!