0

last version of WAS Liberty Profile seems to have broken com.ibm.watson.developer_cloud:java-sdk. I rebuilt images for my app and got last version 17.0.0.1 , and java-sdk for watson stopped working with exception above. Any idea on which tag to use in my Dockerfile to be able to rebuild version using 16.0.0.4 liberty? also... how can I have this working with 17.0.0.1?

Caused by: java.net.UnknownServiceException: Unable to find acceptable protocols. isFallback=false, modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1, TLS_1_0], supportsTlsExtensions=true), ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0], supportsTlsExtensions=true), ConnectionSpec()], supported protocols=[TLSv1]
    at okhttp3.internal.ConnectionSpecSelector.configureSecureSocket(ConnectionSpecSelector.java:72)
    at okhttp3.internal.io.RealConnection.connectTls(RealConnection.java:232)
    at okhttp3.internal.io.RealConnection.establishProtocol(RealConnection.java:196)
    at okhttp3.internal.io.RealConnection.buildConnection(RealConnection.java:171)
    at okhttp3.internal.io.RealConnection.connect(RealConnection.java:111)
    at okhttp3.internal.http.StreamAllocation.findConnection(StreamAllocation.java:187)
    at okhttp3.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:123)
    at okhttp3.internal.http.StreamAllocation.newStream(StreamAllocation.java:93)
    at okhttp3.internal.http.HttpEngine.connect(HttpEngine.java:296)
    at okhttp3.internal.http.HttpEngine.sendRequest(HttpEngine.java:248)
    at okhttp3.RealCall.getResponse(RealCall.java:243)
    at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:201)
    at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:163)
    at okhttp3.RealCall.execute(RealCall.java:57)
    at com.ibm.watson.developer_cloud.service.WatsonService$1.execute(WatsonService.java:179)
    ... 53 more

Edit: I have tried adding the system property as explained here: https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/matchsslcontext_tls.html And I check ps in my docker instance to see that JDK has the property correctly configured:

root@apiqa:/# ps xuww                       
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  4.9  9.4 8512396 3131596 ?     Ssl  17:35  10:32 /opt/ibm/java/jre/bin/java -javaagent:/opt/ibm/wlp/bin/tools/ws-javaagent.jar -Djava.awt.headless=true -Xms950m -Xmx3500m -Dcom.ibm.jsse2.overrideDefaultTLS=true -jar /opt/ibm/wlp/bin/tools/ws-server.jar defaultServer

But the problem is not solved with that. Am I not configuring Liberty profile to get the system property so JDK executes with -D ? (I use jvm.properties file)

icordoba
  • 1,834
  • 2
  • 33
  • 60
  • Do you have a development environment where you could look at the properties of both versions' handshakes? – covener Mar 20 '17 at 14:01
  • Thanks for your reply. I had to rebuild the docker images some days ago after a full docker host corruption and I don't have the 16.0.0.4 version anymore. It does not seem possible to do a docker pull of that version, so I can't test on 16.0.0.4 anymore. i just know it was working before the new docker build that fetched 17.0.0.1 from docker hub. Besides, what do you exactly mean by both versions' handshakes? How can I enable that logging for okhttp3? Thanks. – icordoba Mar 20 '17 at 14:03
  • (Of course, If you can think of a way to pull 16.0.0.4 image, that will bring my Conversation chat bot to work until I fix the problem with 17.0.0.1) – icordoba Mar 20 '17 at 14:04
  • It also seems very complicated to get Liberty 16.0.0.4 as IBM seems to fully erase previous versions from the download page for Liberty. i am sure there is a reason for that but makes things very complicated when someone, as in this case, needs to roll back into a previous version of liberty. – icordoba Mar 20 '17 at 14:05
  • Seems like the old builds are still there, follow the yaml link here https://github.com/WASdev/ci.docker/blob/d4bbe6c7382cecde5d1993a266cc1bc3df6d29d9/ga/developer/kernel/Dockerfile – covener Mar 20 '17 at 14:15
  • re: handshake debugging -- it all happens in the clear, so I would just use a packet capture. Barring that, javax.net.debug=all is the nuclear option. – covener Mar 20 '17 at 14:16
  • OK, thanks! I found 16.0.0.4 at least in a zip version. I will try to build a docker file with it to bring my system back again. Any idea of how to do a "docker pull ..." for that version, right? – icordoba Mar 20 '17 at 14:19
  • I got the Dockerfile from the link you sent me and managed to build a 16.0.0.4 docker image (also using the docker-server command referenced there). I'll see if I did it correctly and it works... – icordoba Mar 20 '17 at 14:30

3 Answers3

1

This is a known issue due to a change in the IBM JDK.

We are working on it (see this).

The workaround is to use an old buildpack for liberty or a different JDK. Use cf push -b liberty-for-java_v3_7-20170118-2046 to use a liberty version that works with the SDK.

You can also change to OpenJDK by running:

cf set-env myapp JVM 'openjdk'

More information here

German Attanasio
  • 22,217
  • 7
  • 47
  • 63
  • Do you know how to do this in the specific case of Liberty profile? I have tried adding that in jvm.properties using -D but does not work. Thanks. – icordoba Mar 20 '17 at 18:14
  • Take a look at https://console.ng.bluemix.net/docs/runtimes/liberty/customizingJRE.html#customizing_jre I think you need `IBM_JAVA_OPTIONS` or `JAVA_OPTS`. Try to update them in your `manifest.yml` you can also specify another version of the IBM JDK – German Attanasio Mar 20 '17 at 18:17
  • I am not using it in Bluemix directly but in a Docker image. I'll see this though. – icordoba Mar 20 '17 at 18:18
  • Yes, I can't use that as I run it in Bluemix as a Docker container. I need to pass it as a standard Liberty. -D is not working. – icordoba Mar 20 '17 at 19:14
0

My team ran into this issue as well. I'm not 100% sure but we came to the conclusion that Liberty 17.0.0.1 is using Java 8 which we believe no longer supports TLS 1.0. You can see that the service you are trying to connect to only supports TLS 1.0:

"supported protocols=[TLSv1]"

It seems that some of the Bluemix services have moved up to TLS 1.1 and some haven't. TLS 1.0 is evidently not very secure so I'm not positive but I believe that Java 8 no longer supports TLS 1.0. This means either the Bluemix service will need to upgrade to TLS 1.1 or you'll need to run Liberty on a previous version of the JVM.

bpulito
  • 646
  • 4
  • 7
  • OK. Seems Liberty version is not the problem as I created a new Dockerfile to generate a Liberty 16.0.0.4 but problem persists. Seems the problem is sin image used: ibmjava:8-jre. Maybe IBM has updated it and does not support TLS 1.0... but Watson conversation needs that TLS so now I need to figure out how to go back to a previous version of IBM JRE compatible with Watson conversation API library client... I'll post any results here. – icordoba Mar 20 '17 at 16:19
-1

I solved this issue setting OpenJDK 1.8 on Liberty instance, just setting env variable JBP_CONFIG_OPENJDK. In my case, was important to set also memory_sizes to overcome an OutOfMemory error, related to the use of OpenJDK

$ cf set-env myapp JBP_CONFIG_OPENJDK: '[version: 1.8.+, memory_sizes: { metaspace: 256m }]'

For complete reference https://console.ng.bluemix.net/docs/runtimes/liberty/customizingJRE.html

gianpa
  • 44
  • 5