Using SSL with JMS

Integration Server can send and receive messages to a JMS provider in a secure manner using SSL. If the connection between Integration Server and the JMS provider is to use SSL, you must configure SSL capabilities on the JMS provider and Integration Server. For requirements and information about configuring SSL on the JMS provider, consult the JMS provider documentation.

To configure SSL on Integration Server (the JMS client), you must provide certificates that can be used during the SSL handshake. Because certificates are stored in keystores and truststores, part of configuring Integration Server for using SSL is specifying the location of the keystores and truststore to be used for establishing the SSL connection. You can accomplish this a few different ways in Integration Server, specifically:

Set the javax.net.ssl properties in the Integration Server JVM to provide certificate location and password information. When connecting to the JMS provider, Integration Server uses the javax.net.ssl property values for creating the SSL context of the SSL handshake.

While you can set the keystore location, truststore location, and password information directly in the javax.net.ssl properties for the JVM, this approach represents a security vulnerability because the properties take String values. Storing keystore and password information in plain text on the file system is not secure. If you do not want to store certificate location and password information in plain text, you can assign a keystore alias and/or truststore alias to be used by the JVM when establishing the default SSL context. At start up, Integration Server sets the javax.net.ssl properties by obtaining the store locations and passwords from the aliases and then creates the default SSL context. For more information, see Storing SSL Information for the Integration Server JVM in a Secure Manner.

If you use the javax.net.ssl properties to provide the certificate and password information, you do not need to specify SSL configuration information in the JMS connection alias or for the initial JNDI context in the JNDI provider alias. However, using the javax.net.ssl properties for establishing an SSL connection with the JMS provider limits Integration Server to using one set of certificates for all SSL connections.

Some JMS providers require that JMS clients use the JVM default SSL context for the SSL handshake. Review your JMS provider documentation for requirements.

Set JMS provider-specific SSL properties in the JNDI provider alias used with the JMS connection alias. Some JMS providers use a set of properties (key-value pairs) to supply certificate details. You can add these properties to a JNDI provider alias. Integration Server adds the certificate information to the JNDI context when the context is created. Supplying certificate and password information via the JNDI provider alias makes it possible to use multiple certificates with the JMS provider and allows the use of a different set of certificates than the ones configured for the JVM. This approach is applicable when the JNDI provider and JMS provider use the same set of certificates such as when using Universal Messaging as the JMS and JNDI providers.

For more information about supplying certificate details via the JNDI provider alias, see Including SSL Configuration Information in the JNDI Provider Alias.

When webMethods Broker is the JMS provider and using the native webMethods API to connect to the webMethods Broker, set the SSL information (Keystore, Keystore Type, Truststore, and Truststore Type) when you create the JMS connection alias.

Note:
If Integration Server connects to the webMethods Broker using JNDI, you need to configure the connection factory on the webMethods Broker. For more information, see Administering webMethods Broker.