The call fails from SAP with the following error:
SOAP:1,023 SRT: Processing error in Internet Communication Framework: ("ICF Error when receiving the response: ICM_HTTP_SSL_ERROR")
We reviewed the certificate chain presented by the CloudHub 2 endpoint and imported the following certificates into SAP STRUST:
- CloudHub server certificate: *.xxxr.usa-e2.cloudhub.io
- Let's Encrypt YR1
- ISRG Root YR
- ISRG Root X1
The certificate chain validates successfully outside SAP.
However, SAP ECC still reports ICM_HTTP_SSL_ERROR when calling the MuleSoft endpoint.
Has anyone experienced this issue with SAP ECC and the newer Let's Encrypt certificate chain used by CloudHub 2?
Specifically, I would like to confirm:
- Which SAP STRUST PSE should contain the CA certificates for an outbound HTTPS SOAP call: SSL Client Anonymous or SSL Client Standard?
- Is the CloudHub leaf/server certificate required in STRUST, or should only the CA/intermediate certificates be trusted?
- Are there known compatibility issues between older SAPCRYPTOLIB versions and the newer YR1 / ISRG Root YR Let's Encrypt chain?
- Does SAP ICM need to be restarted/reloaded after updating the certificate list?
- Is there any special TLS/SNI configuration required when SAP ECC calls a CloudHub 2 endpoint?
MuleSoft itself is available and the endpoint can be reached successfully from other HTTPS clients.
Any guidance on what to check in SAP SMICM/STRUST or CloudHub 2 would be appreciated.
Thanks!
#MuleSoft DataWeave
@Oscar Blancas ICM_HTTP_SSL_ERROR means the handshake is dying inside ICM before any SOAP response. Other clients working, and the chain validating outside SAP, fits that.
For an outbound HTTPS call that does not present a client certificate, the CAs belong in SSL Client (Anonymous), and the destination has to use ANONYM. If the destination is set to DFAULT, ICM reads SSL Client (Standard) instead. Importing the chain into the other PSE looks done and still fails.
Trust the intermediate and the root, not the CloudHub leaf. The leaf is what the server presents during the handshake. Putting that server certificate in the PSE certificate list does not replace trusting the issuer.
Saving STRUST is not enough for a running ICM. Restart ICM from SMICM after the PSE change. On the Let's Encrypt YR chain and SNI, I wouldn't call a specific incompatibility from here. CloudHub picks the certificate from the hostname, and an older CommonCryptoLib that does not send SNI can fail this handshake even with the right CAs. The ICM trace at a higher level is what names the TLS alert. That trace is the next fact, not another import of the leaf.