| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ v6.0 + JMS + SSL = no way? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Heiko Fischer |
 Posted: Mon Nov 16, 2009 3:50 am Post subject: MQ v6.0 + JMS + SSL = no way? |
 |
|
Newbie
Joined: 16 Nov 2009
Posts: 4
|
Hi community,
my scenario is as follows:
IBM Lotus Domino connecting to a remote WS MQ v6.0, utilizing the JMS API.
Since every Lotus Domino server comes with its own JRE (in my scenario v1.4.2), which is independent of the JRE on OS level, no Java client for MQ is installed on the Lotus Domino machine, simply because the Java code running in the context of Lotus Domino's JRE would not "see" that Java client (and its settings) anyway.
So the implementation is such that the required MQ JARs are deployed into the Lotus Domino server's JRE, and all required parameters are fed to the respective constructors/methods at runtime.
This works like a charm for client connections w/ user/password authentication (or no authentication).
However, for the productive system, an SSL secured transport w/ SSL client certificates is required, and here's my problem:
I seemingly cannot parameterize the initial context in a way that all properties expected by the MQ server are in place. Specifically, the server complains about a missing cipher spec upon instantiation of the initial context:
| Code: |
InitialContext ctx;
Hashtable qEnv = new Hashtable();
... add some parameters to the Hashtable ...
ctx = new InitialContext(qEnv); <- error "missing cipher spec" occurs here (error code 2397)
MQConnectionFactory qcf = null;
qcf = (MQConnectionFactory) ctx.lookup("<name_of_queue_manager>");
...
|
I know I can
- specify the cipher suite via MQC.SSL_CIPHER_SUITE_PROPERTY, but from my understanding that would require to switch to MQ base Java
- specify the cipher suite via the MQConnectionFactory.setSSLCipherSuite() method, but that would have to take place AFTER the initial context has been created, so that's no solution for my problem
Is there a way, or do I have to switch to MQ base Java?
TIA to anyone who could shed some light on this! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Nov 16, 2009 4:17 am Post subject: Re: MQ v6.0 + JMS + SSL = no way? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Heiko Fischer wrote: |
| Since every Lotus Domino server comes with its own JRE (in my scenario v1.4.2), which is independent of the JRE on OS level, no Java client for MQ is installed on the Lotus Domino machine, simply because the Java code running in the context of Lotus Domino's JRE would not "see" that Java client (and its settings) anyway. |
This shows a grave misunderstanding of the Java MQ client. The MQ Client does not come with a JRE at all, and is visible and available to ALL JREs that are installed on the same machine. You just have to configure the CLASSPATH to know where it is.
I do not say that this is the source of your SSL problem.
It is not at all clear why you think that the WMQ SSL properties apply to anything having to do with connecting to the InitialContext, unless you are trying to use the WMQInitialContextProvider. Which you haven't said you are trying to do, and you shouldn't use for production anyway.
In general for MQ, everything you need to specify for SSL should be settable in the JNDI properties of the QCF. Which you would access after you have connected to the InitialContext, through the InitialContext. |
|
| Back to top |
|
|
| Heiko Fischer |
| Posted: Mon Nov 16, 2009 5:20 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 4
|
Thanks for your quick reply.
I know that the MQ client doesn't come with its own JRE (why would it have to?), but I assume it would install itself in a way which makes it available to the JRE on OS level (only).
IBM Lotus Domino's JRE, on the other hand, is an isolated JRE which doesn't know anything about the underlying OS's Java environment. It comes with a security setup suitable for its own environment only, meaning it by default can't even access any files outside of the Lotus Domino server's installation. Changing that would require a lot of OS- and Domino-side re-configuration, with potentially unwanted consequences/problems elsewhere (this is a server which hosts lots of Domino applications, not only the one which connects to MQ). To make a long story short, the Java MQ client is not an option here (the implementation as it is adapts an IBM developerWorks article, which suggests this way of doing it).
Anyway, what I'm using here is an initial context factory:
| Code: |
qEnv.put(Context.INITAL_CONTEXT_FACTORY, "com.ibm.mq.jms.context.WMQ11InitialContextFactory");
|
Could that be the cause of the problem? If so, what would be an alternative approach (aside from switching to the MQ base Java API)? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Nov 16, 2009 5:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right, so you are using the WMQInitialContext.
Since we now both agree that the problem you have is entirely in connecting to the InitialContext, and not anything to do with any of the rest of the code, maybe you should show all of the properties you have specified on the Hashtable. Or look at the documentation on the WMQInitialContext and see what properties it exposes for configuring the SSL CipherSpec.
or chuck the WMQInitialContext, go with a FileContext or a real JNDI (perhaps Domino has one?) and configure the JMS objects in that instead of asking WMQ to pretend that it's WMQ configuration is also a JNDI repository.
And, again, it is very likely that you really can use the whole MQ client install, even without LOTS of changes, either by changing the system wide CLASSPATH or by changing where you install the whole MQ client.
On the third hand, I will admit that I do not know the intricacies of Domino Server configuration so it is possible that Domino has made this very difficult. |
|
| Back to top |
|
|
| Heiko Fischer |
| Posted: Mon Nov 16, 2009 7:54 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 4
|
The Hashtable is loaded with just a few values, in addition to the one mentioned above they are:
| Code: |
qEnv.put(Context.PROVIDER_URL, "<IP:Port/SYSTEM.DEF.SVRCONN");
qEnv.put(Context.SECURITY_AUTHENTICATION, "simple");
qEnv.put(Context.SECURITY_PRINCIPAL, "<user>");
qEnv.put(Context.SECURITY_CREDENTIALS, "<password>");
|
The last three are required because the initial connection requires authentication (a MQ server-side setting in this scenario).
According to Sun's API specification for the javax.naming package, the Context interface (or InitialContext which inherits from Context) doesn't supply any fields related to SSL except for SECURITY_PROTOCOL (value in case of SSL would be: "ssl"), so there seems to be no way to specify a cipher spec.
Here's a complete MQ log abstract for the cipher spec error:
| Quote: |
AMQ9639: Remote channel '<name_of_channel>' did not specify a CipherSpec.
EXPLANATION:
Remote channel '<name_of_channel>' did not specify a CipherSpec when the local channel expected one to be specified. The channel did not start.
ACTION:
Change the remote channel '<name_of_channel>' to specify a CipherSpec so that both ends of the channel have matching CipherSpecs.
|
|
|
| Back to top |
|
|
| zpat |
| Posted: Mon Nov 16, 2009 8:27 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 16, 2009 9:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Heiko Fischer wrote: |
The Hashtable is loaded with just a few values, in addition to the one mentioned above they are:
| Code: |
qEnv.put(Context.PROVIDER_URL, "<IP:Port/SYSTEM.DEF.SVRCONN");
qEnv.put(Context.SECURITY_AUTHENTICATION, "simple");
qEnv.put(Context.SECURITY_PRINCIPAL, "<user>");
qEnv.put(Context.SECURITY_CREDENTIALS, "<password>");
|
The last three are required because the initial connection requires authentication (a MQ server-side setting in this scenario).
According to Sun's API specification for the javax.naming package, the Context interface (or InitialContext which inherits from Context) doesn't supply any fields related to SSL except for SECURITY_PROTOCOL (value in case of SSL would be: "ssl"), so there seems to be no way to specify a cipher spec.
Here's a complete MQ log abstract for the cipher spec error:
| Quote: |
AMQ9639: Remote channel '<name_of_channel>' did not specify a CipherSpec.
EXPLANATION:
Remote channel '<name_of_channel>' did not specify a CipherSpec when the local channel expected one to be specified. The channel did not start.
ACTION:
Change the remote channel '<name_of_channel>' to specify a CipherSpec so that both ends of the channel have matching CipherSpecs.
|
|
Again,  I have pointed out that the initial context factory you are using is only fit for a quick DEMO
If you want to use a J2EE solid context factory, I'd strongly advise you to look at the file based JNDI delivered with the product (WMQ)! Or at your appserver JNDI. As I don't know enough about the Domino Appserver JNDI setup (is it much like WAS?) I'd suggest you fall back on the file based JNDI.
This should allow you to set either the url for the channel table or all the properties you need for the channel.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Heiko Fischer |
| Posted: Tue Nov 17, 2009 12:22 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 4
|
@zpat:
Thanks for your suggestion, but my implementation is already referencing a CCDT - the problem is, the code is not reaching the point where the CCDT file is being referenced via MQConnectionFactory.setCCDTURL(), because the JNDI context which is the base for instantiating the MQConnectionFactory object is not being created successfully (it's basically the same as with the setSSLCipherSuite() method, see my initial posting above).
| fjb_saper wrote: |
Again, I have pointed out that the initial context factory you are using is only fit for a quick DEMO
|
Well I've found nowhere that this implementation is feasible for demo purposes only.
| fjb_saper wrote: |
If you want to use a J2EE solid context factory, I'd strongly advise you to look at the file based JNDI delivered with the product (WMQ)! Or at your appserver JNDI. As I don't know enough about the Domino Appserver JNDI setup (is it much like WAS?) I'd suggest you fall back on the file based JNDI.
This should allow you to set either the url for the channel table or all the properties you need for the channel.
|
I'd prefer not to utilize a file based JNDI, because I don't have access to the file system of the Domino server in question, meaning any configuration change on file system level would require me to initiate a formal deployment process so complicated it takes several days to complete (which btw is true for all servers in this environment, ie also for dev and testing servers).
The Domino server doesn't come with a JNDI setup; IBM Lotus Domino is not a Java application server, it only supports Java programs in its own context through its own JRE. Domino's Java support is basically just an encapsulation of the native backend Notes C objects.
Anyway, if there's no other way, I guess I'll have to try the file based JNDI...
| fjb_saper wrote: |
Have fun
|
I surely do!  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 17, 2009 9:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
O.K. The file need not be on the Domino server...
Your Java implementation inside Domino will however need to be able to
- Recognize the MQ jar files on the classpath
- Have authority to access and read the file with the CCDT:
URL="file://hostname/path/filename";
- Have authority to communicate with the CF referenced in the JNDI
Socket open resolve + data flow to qmgr host + qmgr port...
The set up for this should be first tested in a less strict system. You can then deploy to your QA and production system something that you know will work given the right permissions have been setup.
Fun fun fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
