SSLException: HelloRequest, а затем неожиданное сообщение подтверждения

Я пытаюсь подключиться к веб-сервису через SSL с помощью Apache Commons HttpClient 3.1, используя это:

String url = "https://archprod.service.eogs.dk/cvronline/esb/LegalUnitGetSSLServicePort";
HttpClient client = new HttpClient();
PostMethod post = new PostMethod(url);
StringRequestEntity entity = new StringRequestEntity(requestXml, "application/soap+xml", "utf-8");
post.setRequestEntity(entity);
client.executeMethod(post);
String response = post.getResponseBodyAsString();

И я получаю это исключение:

javax.net.ssl.SSLException: HelloRequest followed by an unexpected  handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)

Запрос на тот же URL-адрес на том же компьютере, с использованием curl, отлично работает, и если я изменяю URL-адрес, например, https://www.verisign.com, он отлично работает и на Java. Таким образом, это определенная комбинация Java и этого хоста, а не общая проблема.

Ubuntu 10.04 beta, Sun JDK 1.6.0_19 (та же проблема в Ubuntu в комплекте OpenJDK 6b18 ~ pre4).

Любые идеи, что пойдет не так? Спасибо!

Ответ 1

Такая же проблема, как здесь, я думаю: http://forums.sun.com/thread.jspa?threadID=5435426

По крайней мере, решение работает и для этой проблемы: добавьте "-Dsun.security.ssl.allowUnsafeRenegotiation = true"

Ответ 2

У нас есть приложение webstart, которое не работает из-за этой проблемы. Версия командной строки снова работает при добавлении:

java.lang.System.setProperty( "sun.security.ssl.allowUnsafeRenegotiation", "true" );

Но версия webstart, похоже, игнорирует это, и до сих пор мы не пытаемся установить это свойство в версии webstart.

Ответ 3

По крайней мере, решение работает и для этой проблемы: добавьте "-Dsun.security.ssl.allowUnsafeRenegotiation = true"

Спасибо вам большое за это! Я пытался использовать maven для развертывания через SSL-соединение, используя сертификаты, и у меня было то же исключение. Теперь он решен. Еще раз спасибо!

Ответ 4

Просто добавьте некоторые обновления к этому - Oracle имеет этот КБ, который обсуждает проблему.

Мы столкнулись с JRE 1.6.0_20 в Windows 7, но обновление до 1.6.0_25 устранило проблему (я понимаю, что есть более поздние версии, однако в интересах тестирования программного обеспечения, которое мы тестируем с диапазоном версий - это самое раннее, на что мы смогли положиться).