Advanced Event Mesh Adapter - PKIX Path Building Failed During Deployment

[suresh4u9696m]

Hello Experts,

We are using the Advanced Event Mesh (AEM) Adapter in SAP Integration Suite (Cloud Integration) to connect to a Solace-based event broker using the SMF/JCSMP protocol over TLS.

The adapter configuration includes:

• SMF/JCSMP endpoint
• Basic Authentication
• Secure TLS connection (tcps)
• Security Material maintained in Cloud Integration

Issue

The integration flow deployment fails with the following error:

ValidatorException: PKIX path building failed

sun.security.provider.certpath.SunCertPathBuilderException:

unable to find valid certification path to requested target

What has already been verified

1. TLS Connectivity Test from SAP Cloud integration can successfully reach the target host and port.
2. DNS resolution is working.
3. Firewall/network connectivity appears to be working.
4. Required Root CA certificates have been imported into the Cloud Integration Keystore.
5. Additional corporate CA certificates are already available in the tenant keystore.
6. The endpoint credentials and VPN configuration have been verified.
7. Using an internal/private hostname results in:

com.solacesystems.jcsmp.JCSMPTransportException:

Login request timeout

while using the public secure endpoint results in the PKIX error above.

Questions

1. Has anyone encountered a PKIX error with the Advanced Event Mesh Adapter even when the root certificates already exist in the tenant keystore?
2. Does the AEM Adapter use the same trust validation mechanism as the standard Cloud Integration TLS Connectivity Test?
3. Are there known cases where the Solace broker presents an incomplete certificate chain (missing intermediate certificates), resulting in PKIX failures?
4. Is there a way to determine the exact certificate or trust anchor that Cloud Integration cannot validate during adapter deployment?
5. Are there any SAP Notes or troubleshooting guides specifically addressing PKIX errors with the Advanced Event Mesh Adapter?

Any guidance or similar experiences would be greatly appreciated.

Thank you in advance…

[Sunil-solace]

Hi @suresh4u9696m, this is expected behavior rather than a bug in your setup.

With Basic Authentication, the AEM Adapter doesn’t automatically use SAP CPI’s Security Material for TLS trust validation — that’s a separate mechanism from the platform’s TLS Connectivity Test. The certs you imported into the tenant keystore aren’t picked up by the adapter’s JCSMP session unless you explicitly opt in.

Fix: On the adapter’s Connection tab, add this to the JCSMP Properties map:

ADAPTER.CUSTOM_PROP.USE_CPI_TRUSTSTORE = true

(Added in v1.4.1, works for both Sender and Receiver adapters.) This makes the adapter build its TLS trust store from the CA certs already in your tenant’s Security Material — exactly what you’ve already imported — instead of relying on the JVM default trust store.

Let us know how it goes!

Thanks,

Sunil

[suresh4u9696m]

Hi Sunil,

thank you for your response. I tried the suggested fix by adding the parameter and performed a TLS connectivity test from CPI, but the issue still persists as observed in the results. The same error behavior continues after the test, and no improvement has been seen so far. Could you please advise on the next troubleshooting steps or any additional checks we should perform? Please let me know the next steps at your convenience.

Did TLS connectivity test from CPI after adding that parameter but still the same issue…

[suresh4u9696m]

Did TLS connectivity test from CPI after adding that parameter but still the same issue…

[Sunil-solace]

Thanks for confirming, Suresh — that’s still the exact same underlying exception as before (SunCertPathBuilderException: unable to find valid certification path), just wrapped in the CPI error structure. That confirms the adapter isn’t erroring out while applying the property, but it can’t tell us on its own whether the trust store it built actually contains the certificate needed for this specific host.

Couple of things worth checking next:

1. The platform’s TLS Connectivity Test doesn’t actually go through the adapter — it’s a separate code path that isn’t affected by USE_CPI_TRUSTSTORE either way. Could you confirm you fully undeployed and redeployed the iFlow itself after adding the property, and that the PKIX error is now coming from the actual iFlow deployment/runtime (not the connectivity test)?

2. Double-check the exact key/value in the JCSMP Properties table — it must be exactly ADAPTER.CUSTOM_PROP.USE_CPI_TRUSTSTORE (case-sensitive, no extra spaces) with value true.

3. Ask SAP Support to temporarily raise the log level to INFO for this iFlow/tenant (system logs default to ERROR only, so this needs an SAP request). We’re looking specifically for either:

   • Successfully configured in-memory truststore from CPI keystore service with N trust managers, or
   • No trust managers found from CPI keystore service

   The second line would mean the certificates in your Security Material aren’t being returned by SAP’s own Keystore Service API — a CPI-side keystore configuration issue, separate from the adapter setting.

4. Independently verify which CA actually signs the certificate on that exact host:port (tcps://:55443), rather than assuming the CA you already imported is the right one — e.g. via openssl s_client -connect :55443 -showcerts from a machine on the same network path, or by asking your network/security team if outbound traffic to this host passes through a TLS-inspecting proxy that re-signs with an internal corporate CA. That would explain why the platform’s TLS Connectivity Test (likely a different network path/protocol) succeeds while the raw SMF/TLS connection on port 55443 doesn’t — they may not be seeing the same certificate chain at all.

Could you share the issuer/CA chain returned by the openssl s_client command against the same host and port the adapter uses, if you’re able to run it?