4

We have a JavaFX application calling our backend on an https-secured resource. The application does several hundreds of requests in a row to the same url, to obtain data from the server.

This works without a problem usually, but now we have a customer reporting an SSLHandshakeException problem when connecting to the resource. He can do several hundreds of requests just fine and with the next one, the client fails with:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Java couldn't trust Server 
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
    at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
    at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
    at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
    at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
    at sun.security.ssl.Handshaker.processLoop(Unknown Source)
    at sun.security.ssl.Handshaker.process_record(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.AccessController.doPrivileged(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
    at java.net.HttpURLConnection.getResponseCode(Unknown Source)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
    at com.project.common.ws.client.HttpUrlConnectionRestClient.b(ProGuard:339)
    at com.project.common.ws.client.HttpUrlConnectionRestClient.a(ProGuard:227)
    at com.project.common.ws.client.HttpUrlConnectionRestClient.a(ProGuard:56)
    at com.project.common.ws.client.HttpUrlConnectionRestClient.a(ProGuard:387)
    at com.project.projects.map.client.manager.GeomanagerWorker.readGeocodingChunk(ProGuard:5640)
    at com.project.projects.map.client.manager.n.readGeocodingChunk(ProGuard:4337)
    at com.project.projects.map.client.manager.modules.fx.imports.b.nF(ProGuard:199)
    at com.project.projects.map.client.manager.modules.fx.imports.b.call(ProGuard:174)
    at javafx.concurrent.Task$TaskCallable.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertificateException: Java couldn't trust Server 
    at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)
    at com.sun.deploy.security.X509Extended7DeployTrustManagerDelegate.checkServerTrusted(Unknown Source)
    at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
    ... 30 more

Our SSL Certificate is signed by GeoTrust SSL CA - G3 and valid until December 13, 2016. The customer client uses Java 1.8.0_40

I have researched different articles. This one says, it might be related to a bug with case sensitivity of the certificate domain name. But we use all lower case on both, the certificate and the request, so should be no problem.

This article shows, the problem might be related to the Java Version, because "maybe the new Java version is more strictly enforcing SSL CAs". Also it says, upgrading to newest java version might solve the problem. I didn't yet check this option, because its not always possible for a customer to just upgrade a java version due to company's IT constraints.

Even more, we require Java Version 1.8 to run, so would be bad, if it doesn't work with the 1.8.0_40 version.

Does anyone know, if there is a precise reason for this problem?

ulrich
  • 1,431
  • 3
  • 17
  • 46

1 Answers1

0

I had the same issue. I had to downgrade to Java 1.6 in order for the ASDM-IDM connector to work.

Janou
  • 125
  • 1
  • 9