Why This Is Important

If a certificate is not added to either the Windows trust store or the Java trust store, the following exception may occur:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This indicates that the system is attempting to connect to a host with an SSL certificate that is not trusted. This can lead to issues, such as failing to download dependencies from an artifact repository.

To resolve this, you need to add the target host’s SSL certificate to a trust store.

By default, Maven looks for certificates in the Java trust store, which is located here:

For Java 8:

JAVA_HOME/jre/lib/security/cacerts

For Java 11:

$JAVA_HOME/lib/security/cacerts

To add a certificate, use the following command:

keytool -import -trustcacerts -alias <your-alias> \
 -file /somewhere/in/filesystem/CACert.crt \
 -keystore "$JAVA_HOME/lib/security/cacerts"

If obtaining the certificate is problematic, you can try retrieving it with the following openssl command:

echo | openssl s_client -connect your_server:443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > CACert.crt

Using the Windows Trust Store

Alternatively, you can add the certificate to the Windows trust store. This can be done by right-clicking the certificate file and selecting "Install."

To make Maven recognize certificates from the Windows trust store, you need to update Maven’s settings by either:

• Adding the following line to the .mavenrc file in your user home directory:

MAVEN_OPTS="-Djavax.net.ssl.trustStoreType=Windows-ROOT"

• Setting the MAVEN_OPTS environment variable with the same value.

For instance in Intellij IDEA this setting is here:

After adding the new certificate to the Windows trust store, a system reboot may be necessary for the changes to take effect.

How to connect Windows trust store in Maven Java project was originally published in Where 3 Worlds Meet on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article describe how to establish connection between two parts, Client and Server using mutual TLS (mTLS). Client side is where JAVA Spring Boot service is deployed and Server side is an infrastructure where IBM MQ is. Below, I outline the necessary steps to configure an mTLS connection, with a primary focus on the client side.

Client-Side Prerequisites

The client must have its own keystore and truststore. The server’s certificate, used in the SSL handshake, should be imported into the client’s truststore (see the “Testing mTLS” section, step 2).

Regarding the client’s keystore:

• Generate an RSA keypair with a specific length.
• Use this keypair to generate a CSR (Certificate Signing Request). Ensure the provided information is correct, as it will be used to generate the certificate. For example:

CN = example.com
OU = ACME Dep
O = ACME
L = California
S = San Francisco
C = US

• Request a public or organizational Certificate Authority (CA) to sign your certificate.
• Based on the CSR, the CA will issue the certificate along with any root or intermediate certificates.
• Attach the signed certificate to the client’s keypair by running the following command:

1 keytool -importcert -keystore your_client_keystore.jks -alias your_keypair_alias -file signed_certificate.cer

Ensure the alias matches the RSA keypair alias.

Once successful, you should see the message:

Certificate reply was installed in keystore

Alternatively, you can use KeyStore Explorer to import the CA reply by clicking on the keypair and selecting “Import CA Reply,” then choosing the certificate file.

Changes in Source Code

Dependencies for Spring Boot:

    <dependency>
      <groupId>com.ibm.mq</groupId>
      <artifactId>mq-jms-spring-boot-starter</artifactId>
      <version>correct_version</version>
    </dependency>

Cipher mapping for non-IBM Java SDK users:

If you’re not using the IBM Java SDK, add this Java option:

1 -Dcom.ibm.mq.cfg.useIBMCipherMappings=false

Service configuration

You can override built-in parameters to configure a standard IBM MQ TLS connection:

ibm.mq:
  queueManager: queueManager_name
  channel: channel_name
  connName: connName(50060), connName(50060)
  user: John
  password: pass

Other parameters were custom implementation needed to mTLS

 sslContextType: TLSv1.3 # it depends on server side requirements
 trustStorePassword: passwordToTrustStore
 trustStoreType: jks
 trustStoreLocation: /dir/truststore.jks
 keyStorePassword: passwordToKeyStore
 keyStoreType: jks
 keyStoreLocation: /dir/keystore.jks
 transportType: 1
 sslFipsRequired: false
 property:
 XMSC_WMQ_SSL_CIPHER_SPEC: "<put here CipherSpec>" # The name of the CipherSpec to be used on a TLS connection to a queue manager. The protocol used in negotiating the secure connection depends on the specified CipherSpec. It is important to ask server side about which algorithm was used.
 # available options: https://www.ibm.com/docs/en/ibm-mq/9.4?topic=cipherspecs-cipherspec-order-in-tls-handshake

For further CipherSpec options, refer to IBM documentation.

Note: Full code implementation is not provided here. You will need to implement the JmsListenerContainerFactory<DefaultMessageListenerContainer> and ConnectionFactory beans. In the latter, manually initialize the SSL context to specify which keystore and truststore should be loaded.

Server-Side Prerequisites

The server side must have certificate in their truststore which will be used to authenticate the client (your service). We need to send Root CA, intermediate certificate or different client certificate to server side. That certificate should be also present in client keystore, attached to client RSA keypair.

mTLS Modes

Mutual TLS in IBM MQ can be set to enforce mode. In this mode each client will need to connect to server via mTLS to establish connection.

Or we can ask to set it to optional. During the integration, we may ask server side to temporarily switch the mTLS mode to optional, so that you can run UAT tests and additionally works on the mTLS connection.

Testing mTLS

To verify that mTLS is working, enable SSL debugging by adding the following Java option:

-Djavax.net.debug=ssl,handshake

After restarting the service, you will see the full mTLS handshake process:

1. Client connects to server
2. Server presents its TLS certificate
3. Client verifies the server’s certificate
4. Client presents its TLS certificate
5. Server verifies the client’s certificate
6. Server grants access
7. Client and server exchange information over encrypted TLS connection

Note to 1) If credentials and addresses are correct, the client should pass the first step.

Note to 3) If the truststore is correctly configured, the client will pass this step.

Ad 4) The client will pass this step if:

a) The certificate is successfully attached to the keypair (in the keystore). The log should display:

 Produced client Certificate handshake message (
 "Certificates": [
   "certificate" : {
  "version"            : "v3",
...

If the certificate is missing, you’ll see an empty list:

Produced client Certificate handshake message (
 "Certificates": <empty list>
 )
...

b) The server’s truststore contains the client’s certificate or root CA.

If no exceptions appear in the logs, the integration should be ready. You can ask the server to enforce mTLS mode or manually initiate a connection to IBM MQ to verify.

IBM MQ — Spring Boot mTLS was originally published in Where 3 Worlds Meet on Medium, where people are continuing the conversation by highlighting and responding to this story.