we are trying to connect a cloud-based system vie JMS to webMethods. According to the “webMethods Broker Messaging Programmer’s Guide”, we need to define a property “com.webMethods.jms.naming.truststore” to point to a truststore on disk.
Now, we don’t have access to the filesystem, thus we do not have this option. The service is maintaining its own keystore and it provides a UI where we could upload certificates to.
And we could get a reference to an according “java.security.KeyStore” object in code…
… but, the webMethods client seems to accept only filesystem-paths in that property. And the connection fails, if that property is not set. The client fails with “[BRM.10.5072] JMS: SSL truststore “bkServerTrustStore.jks”: not found”. “bkServerTrustStore.jks” seems to be a default.
So actually we are looking for a way to either
a) pass to the JNDI context the Keystore object we derive in the code or
b) have the webMethods client use the JDKs truststore.
c) something I haven’t thought of?
I have been told, that the server is some 9.2 version and it seems that the client is an 8.something version.
You might have guessed, that we are working on a migration of a pretty old codebase. And if the answer is, that we need to upgrade the client that could be an option (though I a looking at the documentation of version 9.6).
This is my first time I am working with webMethods and JMS… so bare with me if I am not using the correct terminology (or get things completely wrong )
Property “com.webMethods.jms.naming.truststore” must point to a file name. Passing an existing KeyStore Java object or a serialized KeyStore object is not supported.
bkServerTrustStore.jks is not default truststore in Broker JMS/JNDI. Most likely, you are setting the property “com.webMethods.jms.naming.truststore” to “bkServerTrustStore.jks”. That fails as Broker JNDI cannot find the file.
a) Passing of KeyStore object won’t work as Broker JNDI creates its own KeyStore objects from the given file paths.
b) I don’t think you can use JDK’s truststore either as Broker JNDI code will use SSLSocketFactory only if those properties are set to valid keystore/truststore files.
Broker JNDI eventually creates FileInputStream object for the given trust store file path. If somehow you can bundle your truststore file somewhere on the file system, you just may be able to pass a relative path to that file.
Upgrading the Broker client version will not help. It is same implementation in 8.x, 9.6, and now 10.5.
You may still consider upgrading the client version, just to get latest patches.
I am definitely not setting the value to “bkServerTrustStore.jks” in the client code ()… but maybe that value is returned from the JNDI environment? I’ll have to check with the server admins.
Setting a file is not an option, as we don’t have access to a filesystem. The only way I can think of is providing a truststore in the classpath… Would that be an option? I mean… you already mentioned it has to be a file, but maybe you forgot about that?
I am wondering, why the client insists on a private truststore at all. I mean… that wouldn’t be necessary if we are using a proper PKI with trusted and signed certificates in the first place. What am I missing here?
“why the client insists on a private truststore at all. I mean… that wouldn’t be necessary if we are using a proper PKI with trusted and signed certificates in the first place. What am I missing here?”
That is how it was implemented. It is client limitation that is supports only a file. Broker is deprecated, so I don’t think this Broker will ever support using Java object, or a serialized truststore, or some system defined global truststore that is available to all processes, however small that code change may be. But, you could try reporting a support incident with reasons and get some basic thing done, e.g. com.webMethods.jms.naming.truststore=SYSTEM should use JVM truststore.
“The only way I can think of is providing a truststore in the classpath”
It has to be a file. You’ll need to explore and find a workaround, however ugly that workaround may be.
You can try something like following, just one of the hack if all I could put on target system is wm-jmsnaming.jar
Copy cacerts.jks at location /resources/cacerts.jks inside the jar file.
Now, In some static initializer do following, before you execute your Broker JNDI code.
getResourceAsStream(“/resources/cacerts.jks”).
Create a copy using FileOutputStream. Now, you have a file in the file system.
Eventually Broker JNDI will call ctor FileInputStream(“somewhere/somefile”). I don’t think it picks up the file from the classpath. So, again you’ll need to use some extra logic to pick the file from the classpath, copy it somewhere on the disk, and set the parameter to this file. All this before Broker JNDI code is triggered.
)