I have to call external API from IFS Connect. I used to had a problem with certificate but now I have different issue. For testing connection to external system I’ve prepared sql script and I run it in pl/sql developer. The result is error message:
ORA-20105: PlsqlapServer.ERRINV: ExecutionException from Sender thread
Caused by: ifs.fnd.connect.senders.ConnectSender$TemporaryFailureException: Exception while sending data
Caused by: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
Caused by: java.io.EOFException: SSL peer shut down incorrectly
ORA-06512: przy "IFSAPP.ERROR_SYS", linia 150
ORA-06512: przy "IFSAPP.ERROR_SYS", linia 368
ORA-06512: przy "IFSAPP.PLSQLAP_SERVER_API", linia 2079
ORA-06512: przy "IFSAPP.PLSQLAP_SERVER_API", linia 2338
ORA-06512: przy "IFSAPP.PLSQLAP_SERVER_API", linia 517
ORA-06512: przy "IFSAPP.PLSQL_REST_SENDER_API", linia 1884
ORA-06512: przy "IFSAPP.PLSQL_REST_SENDER_API", linia 1034
ORA-06512: przy linia 28
I’ve set up routing path and address in IFS Connect. All looks ok. I also tested this connection outside IFS and it works correctly.
Have you some suggestion what is the problem?
Thank you.
Best answer by martin.surasky
That error pattern points much more to a TLS/SSL handshake problem than to anything in the IFS Connect routing path.
The key clues are:
SSLHandshakeException: Remote host terminated the handshake
EOFException: SSL peer shut down incorrectly
That means the remote side closed the connection during TLS negotiation, before the REST call was really established. In other words, the address/routing may be correct, but the two sides are not agreeing on the SSL/TLS session
The most likely causes are these.
1. The certificate chain is still not trusted by the Java runtime that IFS Connect is using. Testing “outside IFS” often succeeds because Postman, a browser, curl, or another tool is using a different trust store than the IFS application server. In IFS documentation, certificates for outbound Java-based communication are handled through the Java truststore (cacerts). In remote-install IFS Cloud docs, imported certificates are explicitly added to the Java truststore.
2. TLS protocol mismatch. If the external API only accepts certain protocol versions, and the IFS JVM offers something different, the remote side may simply drop the handshake. IFS remote-install documentation shows TLS versions are configurable and defaults commonly include TLSv1.2 and TLSv1.3. If the endpoint only allows one side of that equation, or your Java runtime is older, you can get exactly this symptom.
What I would do next, in order:
Confirm the exact URL configured in IFS Connect is the same FQDN that works outside IFS. Avoid IP addresses.
Verify the full server certificate chain is imported into the truststore used by the IFS middle tier JVM, not just into Windows cert store, browser store, or Oracle wallet.
Check whether the external API requires mTLS. If yes, make sure IFS is configured to present the client certificate/private key.
The single most important practical point is this: “It works outside IFS” does not prove “it should work in IFS.”. It only proves that some other client runtime can negotiate TLS with that server. IFS Connect is using the JVM and trust configuration of the IFS application tier, which may be different.
That error pattern points much more to a TLS/SSL handshake problem than to anything in the IFS Connect routing path.
The key clues are:
SSLHandshakeException: Remote host terminated the handshake
EOFException: SSL peer shut down incorrectly
That means the remote side closed the connection during TLS negotiation, before the REST call was really established. In other words, the address/routing may be correct, but the two sides are not agreeing on the SSL/TLS session
The most likely causes are these.
1. The certificate chain is still not trusted by the Java runtime that IFS Connect is using. Testing “outside IFS” often succeeds because Postman, a browser, curl, or another tool is using a different trust store than the IFS application server. In IFS documentation, certificates for outbound Java-based communication are handled through the Java truststore (cacerts). In remote-install IFS Cloud docs, imported certificates are explicitly added to the Java truststore.
2. TLS protocol mismatch. If the external API only accepts certain protocol versions, and the IFS JVM offers something different, the remote side may simply drop the handshake. IFS remote-install documentation shows TLS versions are configurable and defaults commonly include TLSv1.2 and TLSv1.3. If the endpoint only allows one side of that equation, or your Java runtime is older, you can get exactly this symptom.
What I would do next, in order:
Confirm the exact URL configured in IFS Connect is the same FQDN that works outside IFS. Avoid IP addresses.
Verify the full server certificate chain is imported into the truststore used by the IFS middle tier JVM, not just into Windows cert store, browser store, or Oracle wallet.
Check whether the external API requires mTLS. If yes, make sure IFS is configured to present the client certificate/private key.
The single most important practical point is this: “It works outside IFS” does not prove “it should work in IFS.”. It only proves that some other client runtime can negotiate TLS with that server. IFS Connect is using the JVM and trust configuration of the IFS application tier, which may be different.
