IBM App Connect Enterprise (ACE)- TLS Configuration

6 min readNov 11, 2020

Introduction

Once you successfully build an API you have to start thinking of non-functional requirements. One of the most important non-functional is security. There are so many ways to implement security for a REST API in App Connect. This post, we will discuss one of the widely used methodology, Transport Level Security (TLS) configuration for App Connect Enterprise. At first, configuring TLS to any application may seem to be a daunting task, but if we understand the key terms and concepts this will be just as any other configuration.

There are few key terms which we need to understand before implementing TLS. There are so many resources in the internet explaining in detail, the terms I’m about to discuss. You can go through them and get a better understanding. In this post I’ll try to explain them as simple as possible.

TLS - is a predecessor to now deprecated version of Secure Socket Layer (SSL). A detailed explanation on what is TLS is provided in this post. In brief TLS is a mechanism that ensures secure communication between systems over networks. Data transmitted through communication channels are encrypted using keys meaning it will be impossible to tamper or eavesdrop transmitted data.

Public key/Private key -Keys are factors of very large prime numbers, once data is encrypted by a public key it can be only decrypted by it’s pair private key. During a TLS transmission we share the public key to a client application, ask them to encrypt the data using the shared public key. That encrypted data can only be decrypted by the private key at our end which we only own.

Keystore - Is a repository which we store key pairs (public/private keys) and certificates.

Truststore - Is a repository we store certificates of trusted third parties.

Certificate - Simply put, certificates are small data files which bind a public key and organizations details.

Certificate Authority - Is an entity that issues digital certificates. Digital certificates proves the ownership of public keys. A certificate approved by a Certificate Authority ensures the communication can be trusted.

Self-signed certificate - Is a certificate that is not signed by a Certificate Authority. Self-signed certificates are used for testing purposes and must not be used in production.

There are heap of resources in the internet which you can read and understand these concepts. For simplicity I’ll stick to the App Connect Enterprise TLS configuration part.

Configuring TLS for App Connect consist of two main parts.

Generating a self signed certificate and adding that certificate to a keystore.
Configuring the keystore to be used by App Connect.

1. Certificate generation

Certificate generation is a complicated process and involves lots of technicality. In this post I will just concentrate on the generation steps and try to keep the explanation as simple as possible. I completely followed this IBM support portal to generate the certificates. Java developers would be familiar with keytool utility which helps us generating certificates and keystores. This post we will use ikeycmd, a similar utility which works well for IBM applications.

We start with generating two keystores. One is to act as a certificate signing authority (keyselfsigned.jks), since we are creating a self signed certificate, and the other as our App Connect keystore(keypersonalcert.jks).

ikeycmd -keydb -create -db keyselfsigned.jks -pw abc@123 -type jks
ikeycmd -keydb -create -db keypersonalcert.jks -pw abc@123 -type jks

Next we’ll create a certificate which will function as our Certificate Authority. Second command will allow us to view the created certificate.

ikeycmd -cert -create -db keyselfsigned.jks -pw abc@123 -label testesb -dn "cn=testesb ou=sample o=mycompany c=LK" -size 2048 -expire 365 -ca true
ikeycmd -cert -details -label testesb -db keyselfsigned.jks -pw abc@123

Next we’ll create a certificate request file. The subsequent command will allow us to view this certificate request.

ikeycmd -certreq -create -db keypersonalcert.jks -pw abc@123 -label testesb -dn “cn=testesb ou=sample o=mycompany c=LK” -size 2048 -file personalcertreq.arm
more personalcertreq.arm

Take note that an .arm file is the IBM version of .csr file(certificate signing request). Both are the same file types. In a real world scenario we will provide thia .arm/.csr file to a global certificate signing authority and get it signed. By the following command we can verify the certificate request exist in the keystore.

ikeycmd -certreq -details -label testesb -db keypersonalcert.jks -pw abc@123

Nex we submit the certificate sign request and get it signed (self signed).

ikeycmd -cert -sign -db keyselfsigned.jks -pw abc@123 -label testesb -target signedpersonalcert.cer -format ascii -file personalcertreq.arm

We can view the content of the generated signed personal certificate by the following command.

more signedpersonalcert.cer

Next we extract the signed certificate and add it to our own keystore.

ikeycmd -cert -extract -db keyselfsigned.jks -pw abc@123 -label testesb -target signer.cer -format ascii
ikeycmd -cert -add -db keypersonalcert.jks -pw abc@123 -label testesb -file signer.cer -format ascii -trust enable

Using below commands we can verify whether our certificate imports have errors.

ikeycmd -cert -receive -file signedpersonalcert.cer -db keypersonalcert.jks -pw abc@123 -format ascii
ikeycmd -certreq -list -db keypersonalcert.jks -pw abc@123

If no errors are given our certificate generation part is complete. keypersonalcert.jks would be our App Connect Enterprise keystore and signer.cer will be our certificate which should be shared to third party systems. This signer.cer should be added in their truststores for secure communication. We are done with the self signed certificate creation part. Next we’ll move on to App Connect configuration.

2. App Connect configuration

Assume that I have an integration node named ACE1 and and integration server is1. I place my keystore in location /home/user/keypersonalcert.jks and provide the necessary permissions. Following commands will add the keystore file to the integration server and do the password configuration

mqsichangeproperties ACE1 -e is1 -o ComIbmJVMManager -n keystoreFile -v /home/user/keypersonalcert.jks
mqsichangeproperties ACE1 -e is1 -o ComIbmJVMManager -n keystorePass -v is1Keystore::password

Take note of the is1Keystore::password value in the second command. This should be identical with your integration server name, mine being is1.

Following command will set the password value given above.

mqsisetdbparms ACE1 -n is1Keystore::password -u ignore -p abc@123

abc@123 would be my keystore password value. It is always good to set the truststore also. Command would be similar to keystore setup. Once all the configuration are done don’t forget to do a restart for the changes to be effective.

If we want we can set the HTTPS connection port explicitly by the following command.

mqsichangeproperties ACE1 -e is1 -o HTTPSConnector -n explicitlySetPortNumber -v 7843

This completes the App Connect Enterprise configurations.To enable HTTPS in the REST API project, tick the Enable SSL in the projects’ rest API description.

Do a clean build for the project and deploy it in the server. Below is a image captured from one of my post man test run.

That’s it, we are done with TLS configuration for App Connect Enterprise.

Conclusion

In this post we saw how we can implement TLS for secure communication between IBM App Connect and external system. We created a self signed certificate, added the certificate to a keystore and configured that keystore to App Connect. We verified the configuration using Postman, by enabling SSL in the Rest API description and deploying the project to a integration server.

IBM App Connect Enterprise (ACE)- TLS Configuration

Introduction

1. Certificate generation

2. App Connect configuration

Conclusion

References

Written by Yasothar Arulnayagam