Message Image  

Some guidelines for using SSL with IBM Integration Bus

 View Only
Tue June 02, 2020 06:44 AM

Using SSL in IBM Integration Bus is a great way to increase your security. Secure Sockets Layer (SSL) is a method for encompassing a stream of data in an encrypted “tunnel”, providing confidentiality, integration, some levels of authentication and coarse-grained authorization.

Even though SSL should be easy to apply, there are caveats, and since it’s security it’s hard to debug, here are some guidelines we recommend when setting up SSL with IBM Integration Bus:

1. Do not modify / use the cacerts store.

cacerts is part of the installed environment and may be overwritten on reinstall or upgrade. Instead, keep your keystores and truststores in a separate location, e.g. /var/mqsi/security/keys for keystores and /var/mqsi/security/certificates for truststores.

Note: Make sure the “keys” directory is protected by filesystem security as it’s holding your private keys (Although the keystore itself is password protected, it’s always better to be doubly safe).

2. Use separate stores for your keys and certificates (keystores and truststores)

When you use the same store for your keys and certificates, you might accidentally end up distributing your private keys when copying a truststore from one place to another.

3. Use CA-signed keys. Don’t use self-signed keys

Use CA-signed keys in your development, test, and production environments. Certain SSL implementations outright reject certificates that are self signed, thereby causing more time spent debugging.

If you just need some keys for development purposes, you can create a mini certificate authority on your local system to create some “proper” subkeys. Remember to import your CA certificate into the truststore for both ends of the SSL conversation.
For example, search for TinyCA (other small CA implementations are also available) if you want to create your own certificate authority.

4. Have a complete chain in your keystore, including private key with associated certificate and the signing (issuing / CA) certificate.

You’ll be duplicating your CA certificate in both keystore and truststore, but certain security providers check for a complete chain (i.e. Your certificate signed by Intermediate Certificate Authority signed by Root Certificate Authority) to be present in the keystore and don’t look in the truststore.

5. Always use Java .jks format for keystores and truststores.

Both Java .jks keystores and other keystore formats are capable of holding multiple keys and certificates, but you’ll find that all instructions and tools used with the Integration Bus will reference jks stores, so using them will make your life easier.

You can import pfx / p12 keystores into java keystores using ikeyman or keytool.

6. Debug the server SSL setup by using a separate tool such as openssl

When you’re having trouble making SSL work either when acting as a consumer or a provider of a service, it helps to use different tools to provide more information about the endpoint. You might want to check whether your integration server is sending the right certificate or asking for the right domains.

For example, use the following command

openssl s_client -connect server:port

to see openssl establish an SSL session. Then, see what’s being sent back to you in the output of the command. Additionally, point it to your CA certificate to check the chain being sent is valid. For lots of detailed guidance on using this and similar commands, your local search engine is of great help.

Note: These recommendations are also valid for setting up SSL in WebSphere Message Broker v8.