Troubleshooting JMS Connectivity Failure with Informatica JMS Queue Due to Truststore self-signed certificate Issues

Issue Description

The Mule application attempts to connect to the Informatica JMS Queue using the JMS Connector. During the SSL handshake process, the connection fails with the following error:

javax.net.ssl.SSLHandshakeException:
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target

Although the Informatica certificate was added to the truststore, the SSL connection continued to fail.

Error Logs

javax.net.ssl|ERROR|Fatal (CERTIFICATE_UNKNOWN):
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target

Caused by:
sun.security.validator.ValidatorException:
PKIX path building failed

Caused by:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target

org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException:
AMQ219007: Cannot connect to server(s).

Root Cause

The issue is not related to the MuleSoft JMS Connector implementation.

The root cause originates from the WildFly/Apache ActiveMQ Artemis SSL and transport configuration.

Key Findings

1. The Informatica JMS server was initially configured with a self-signed certificate.
2. Java could not validate the certificate chain during SSL handshake.
3. The server returned an ActiveMQJMSConnectionFactory through JNDI instead of an ActiveMQSslConnectionFactory.
4. Apache ActiveMQ Artemis handles SSL at the Netty transport layer rather than through a dedicated SSL connection factory.
5. The MuleSoft <tls:context> configuration cannot be propagated to Artemis JNDI-managed connection factories due to architectural limitations.
6. WildFly client libraries require a properly configured wildfly-config.xml file available in the Mule application classpath.