Troubleshooting SSLHandshakeException – Data Lake is not available (Java / JDBC)

ODBC PowerPack Troubleshooting
, , , ,
1

When using the ZappySys JDBC Driver to connect to Infor Data Lake, you may encounter the following error during the Test Connection step:

System.Exception: Test Connection: FAILED
JBR error: java.sql.SQLException: Data Lake is not available
	at com.infor.idl.jdbc.Driver.connect(Driver.java:422)
	at DbConnection.Init(DbConnection.java:55)
...
javax.net.ssl.SSLHandshakeException: Unable to verify trust for server certificate chain
[CN=mingle-sso.inforcloudsuite.com, CN=Cato-Networks-Server-boscatod1, CN=Cato Networks Root CA, OU=Cato Cloud, O=Cato Networks Ltd., OID.2.5.4.17=6701203, STREET=Menachem Begin 121, L=Tel Aviv, C=IL]

This error occurs during the SSL/TLS handshake when the Java runtime attempts to authenticate with Infor’s OAuth or Data Lake endpoints.
The failure indicates that Java does not trust the server certificate chain presented by the endpoint.

This is a common issue when:

  • An organization uses SSL inspection or a reverse proxy
  • A network appliance replaces the original certificate with an internal certificate
  • Required root/intermediate certificates are missing from the Java truststore
  • A firewall or proxy enforces TLS inspection policies

1. Root Cause

The Java error:

  • SSLHandshakeException
  • PKIX path building failed
  • Unable to verify trust for server certificate chain

means:

The certificate chain presented to Java during the secure connection is not trusted or cannot be validated using the certificates in the Java truststore.

This happens when:

  • The original Infor certificate is replaced by a corporate proxy
  • Intermediate certificates are missing
  • TLS inspection is enabled on the network
  • Java is using a truststore that does not include the required CA certificates
  • There is a mismatch between OS-level and Java-level trust settings

Because OAuth authentication requires a valid SSL handshake, the failure leads to:

“Data Lake is not available”
even though the service itself is online.

2. Troubleshooting Steps

Below are the recommended steps to diagnose and resolve the issue.

Step 1 — Verify Basic Connectivity

From the same machine where the connector/JDBC/ETL process is running, execute:

(Invoke-WebRequest -Uri "https://<your-cloud-endpoint>").Content

Interpretation:

  • If this fails → the problem is likely related to network, proxy, firewall, or system certificate settings.
  • If it succeeds → Windows trusts the certificate chain, and the issue is most likely within the Java truststore used by the JDBC Driver.

Step 2 — Check the Java Environment

Run this on the same server:

java -version

Collect this information:

  • Java version
  • 32-bit vs 64-bit
  • Vendor (Oracle, AdoptOpenJDK, Amazon Corretto, etc.)

This is important because each Java installation uses its own truststore, and the connector may point to a different Java path than expected.

Step 3 — Confirm Your Authentication Setup

To properly isolate the issue, confirm how the connector is performing authentication:

  • Username/password
  • API key
  • OAuth2 / token-based authentication
  • IONAPI or JSON auth file
  • Certificate-based authentication

Incorrect or incomplete authentication configuration may result in SSL validation failures.

Step 4 — Check if SSL Interception or Network Inspection Is Occurring

Some companies use:

  • SSL inspection gateways
  • Zero-trust network agents
  • Corporate proxies

These intercept SSL traffic and re-sign certificates with their internal CA.

In such cases, you must import the enterprise root CA into the Java truststore.

If your IT/network team provides a .cer or .crt file:

  • Import it using the keytool command from Step 4.

Step 5 — Test the Same Connection from Another JDBC Client

This is a critical isolation test.

Try connecting to the same endpoint using:

  • DBeaver
  • DbVisualizer

Use:

  • The same JDBC JAR file
  • The same connection string
  • The same credentials

Interpretation:

  • If it fails there also → the issue is external (certificate trust, network proxy, SSL inspection).
  • If it works → the issue is isolated to your ETL tool’s Java environment or configuration.

Step 6 — Final Verification

Once certificates are imported and Java paths are corrected:

  • Re-run the original connection
  • Capture logs if any SSL/handshake errors remain
  • Re-test in DBeaver/DbVisualizer for confirmation

If the handshake succeeds there, your environment is configured correctly.

Conclusion

SSL handshake failures are usually caused by untrusted certificates in the Java truststore.
By verifying connectivity, checking Java configuration, and importing required certificates, the issue can be resolved quickly.