Edit:
I don't think this is related to Watson so I posted a different question regarding javax.net and ssl here
I have 3 Watson services, TTS, STT and Conversation, incorporated into a Java Spring web app and all three work fine running the app in Eclipse/localhost. I recently updated the production server configuration (Apache/Tomcat) to be a secure site (HTTPS/SSL with a LetsEncrypt cert) in order to access the microphone in Chrome. Now when I deploy the app I'm seeing an SSLException when executing the getVoices() TTS method.
javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
I can't find any documentation or questions in SO related to accessing Watson services from a secure site, but I should think that it's possible given the Chrome requirement that apps that access the mic must be secure.
Is there a setting, flag or other config that is required to make this work?
Here's the relevant portion of the log:
Caused by: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[?:1.7.0_80]
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) ~[?:1.7.0_80]
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979) ~[?:1.7.0_80]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086) ~[?:1.7.0_80]
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332) ~[?:1.7.0_80]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359) ~[?:1.7.0_80]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343) ~[?:1.7.0_80]
at okhttp3.internal.io.RealConnection.connectTls(RealConnection.java:239) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.io.RealConnection.establishProtocol(RealConnection.java:196) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.io.RealConnection.buildConnection(RealConnection.java:171) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.io.RealConnection.connect(RealConnection.java:111) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.http.StreamAllocation.findConnection(StreamAllocation.java:187) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:123) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.http.StreamAllocation.newStream(StreamAllocation.java:93) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.http.HttpEngine.connect(HttpEngine.java:296) ~[okhttp-3.3.1.jar:?]
at okhttp3.internal.http.HttpEngine.sendRequest(HttpEngine.java:248) ~[okhttp-3.3.1.jar:?]
at okhttp3.RealCall.getResponse(RealCall.java:243) ~[okhttp-3.3.1.jar:?]
at okhttp3.RealCall$ApplicationInterceptorChain.proceed(RealCall.java:201) ~[okhttp-3.3.1.jar:?]
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:163) ~[okhttp-3.3.1.jar:?]
at okhttp3.RealCall.execute(RealCall.java:57) ~[okhttp-3.3.1.jar:?]
at com.ibm.watson.developer_cloud.service.WatsonService$1.execute(WatsonService.java:179) ~[core-3.5.0.jar:?]
Update #1
Just to make sure, I flipped the Apache/Tomcat config back to HTTP, restarted both and the exception did not occur. So, my guess is it must either be an issue with maybe Okhttp (used by the Watson JDK) or a config issue with Apache/Tomcat. Or maybe Watson doesn't recognize the LetsEncrypt cert?
Update #2
I've been trying to research the exception and I'm thinking that it's likely an Apache/Tomcat config issue, possibly with the SSL protocol. I added this to the Apache httpd.conf but the issue is still present.
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3
I added the Apache & Tomcat tags in the hopes someone more familiar than me with their configuration might point me in the right direction to solve this.
I believe I found the cause of the problem. After more research and debugging, I realized it had nothing to do with Watson, Apache or Tomcat. As I indicated in an edit to this question, I posted another question more specific to javax.net.ssl here: Intermittent javax.net.ssl failure bad_record_mac. The answer I posted there contains the details of my findings, but the bottom line is it appears the cause was a bug in Java7. I fixed it by disabling all Diffie-Hellman cipher suites in the java.security file.