2016-12-02 9 views
0

Edit:Проблема с Уотсоном и HTTPS

Я не думаю, что это связано с Уотсоном, поэтому я отправил другой вопрос о javax.net и SSL here


У меня есть 3 Уотсон сервисы, TTS, STT и разговоры, встроенные в веб-приложение Java Spring, и все три работают отлично, работая в приложении Eclipse/localhost. Недавно я обновил конфигурацию производственного сервера (Apache/Tomcat) как безопасный сайт (HTTPS/SSL с сертификатом LetsEncrypt), чтобы получить доступ к микрофону в Chrome. Теперь, когда я развертываю приложение, я вижу SSLException при выполнении метода getVoices() TTS.

javax.net.ssl.SSLException: Received fatal alert: bad_record_mac

Я не могу найти никакую документации или вопросы SO, связанные с доступом к услугам Ватсона из безопасного места, но я думаю, что это возможно, учитывая требование Chrome, что приложения, имеющий доступ к микрофону должны быть безопасными ,

Есть ли настройка, флаг или другая конфигурация, необходимая для выполнения этой работы?

Вот соответствующая часть журнала:

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

Просто чтобы убедиться, я перевернул Apache/Tomcat конфигурации обратно в HTTP, перезапущен как и исключение сделал не возникает. Итак, я предполагаю, что это должна быть проблема с Okhttp (используется Watson JDK) или проблема с конфигурацией с Apache/Tomcat. Или, может быть, Уотсон не признает сертификат LetsEncrypt?

Update # 2

Я пытался исследовать исключение, и я думаю, что это, вероятно, конфигурационный вопрос Apache/Tomcat, возможно, с помощью протокола SSL. Я добавил это в Apache httpd.conf, но проблема все еще присутствует.

SSLProtocol all -SSLv3 
SSLProxyProtocol all -SSLv3 

Я добавил теги Apache Tomcat & в надежде кого-то более знакомым, чем мне с их конфигурацией может указать меня в правильном направлении, чтобы решить эту проблему.

ответ

0

Я считаю, что я нашел причину проблемы. После дополнительных исследований и отладки я понял, что это не имеет никакого отношения к Watson, Apache или Tomcat. Как я указал в редактировании этого вопроса, я добавил еще один вопрос, более конкретный для javax.net.ssl ​​здесь: Intermittent javax.net.ssl failure bad_record_mac. Ответ, который я разместил там, содержит подробные сведения о моих выводах, но, судя по всему, причина была ошибкой в ​​Java7. Я исправил это, отключив все шифровальные пакеты Diffie-Hellman в файле java.security.