Подтвердить что ты не робот

Javax.net.ssl.SSLHandshakeException: удаленное подключение к удаленному хосту во время рукопожатия во время веб-службы Communicaiton

Я получаю javax.net.ssl.SSLHandshakeException: удаленное закрытое соединение хоста во время исключения handshake, когда я пытаюсь сделать HTTPS сообщение веб-службы через интернет. Но тот же код работает и для других интернет-сервисов. Я много пробовал, ничто не помогает мне. Я разместил здесь свой пример кода. Может ли кто-нибудь помочь мне решить эту проблему?

public static void main(String[] args) throws Exception {

    String xmlServerURL = "https://example.com/soap/WsRouter";
    URL urlXMLServer = new URL(xmlServerURL);
    // URLConnection supports HTTPS protocol only with JDK 1.4+ 
    Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(
            "xxxx.example.com", 8083));
    HttpURLConnection httpsURLConnection = (HttpURLConnection) urlXMLServer
            .openConnection(proxy);
    httpsURLConnection.setRequestProperty("Content-Type","text/xml; charset=utf-8");
    //httpsURLConnection.setDoInput(true);
    httpsURLConnection.setDoOutput(true);
    httpsURLConnection.setConnectTimeout(300000);
    //httpsURLConnection.setIgnoreProxy(false);
    httpsURLConnection.setRequestMethod("POST"); 
    //httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY); 
    // send request
    PrintWriter out = new PrintWriter(
            httpsURLConnection.getOutputStream());
    StringBuffer requestXML = new StringBuffer();
    requestXML.append(getProcessWorkOrderSOAPXML());   
    // get list of user     
    out.println(requestXML.toString()); 
    out.close();
    out.flush();
    System.out.println("XML Request POSTed to " + xmlServerURL + "\n");
    System.out.println(requestXML.toString() + "\n"); 
    //Thread.sleep(60000);  
    // read response

    BufferedReader in = new BufferedReader(new InputStreamReader( 
            httpsURLConnection.getInputStream()));
    String line;
    String respXML = "";
    while ((line = in.readLine()) != null) {
        respXML += line;
    }
    in.close();

    // output response
    respXML = URLDecoder.decode(respXML, "UTF-8"); 
    System.out.println("\nXML Response\n");
    System.out.println(respXML);
}

Полный стек:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
       at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
       at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
       at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
       at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
       at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091)
       at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
       at com.labcorp.efone.vendor.TestATTConnectivity.main(TestATTConnectivity.java:43)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
       at sun.security.ssl.InputRecord.read(InputRecord.java:482)
       at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
       ... 8 more

На самом деле, здесь есть два сценария. Когда я работаю как автономная Java-программа, я получаю исключение выше. Но когда я пытаюсь выполнить на сервере приложений weblogic, я получаю следующее исключение: любая подсказка, что может быть причиной?

java.io.IOException: Connection closed, EOF detected
    at weblogic.socket.JSSEFilterImpl.handleUnwrapResults(JSSEFilterImpl.java:637)
    at weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515)
    at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:96)
    at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:75)
    at weblogic.socket.JSSEFilterImpl.write(JSSEFilterImpl.java:448)
    at weblogic.socket.JSSESocket$JSSEOutputStream.write(JSSESocket.java:93)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
    at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
    at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:192)
    at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:433)
    at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
    at com.labcorp.efone.service.impl.WorkOrderServiceImpl.processATTWorkOrder(ATTWorkOrderServiceImpl.java:86)
    at com.labcorp.efone.bds.WorkOrderBusinessDelegateImpl.processATTWorkOrder(WorkOrderBusinessDelegateImpl.java:59)
    at com.labcorp.efone.actions.ATTWorkOrderAction.efonePerformForward(ATTWorkOrderAction.java:41)
    at com.labcorp.efone.actions.EfoneAction.efonePerformActionForward(EfoneAction.java:149)
    at com.labcorp.efone.actions.EfoneAction.execute(EfoneAction.java:225)
    at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:751)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at com.labcorp.efone.security.EfoneAuthenticationFilter.doFilter(EfoneAuthenticationFilter.java:115)
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
    at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
    at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
    at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
    at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
    at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3367)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3333)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
    at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
    at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2220)
    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2146)
    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2124)
    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1564)
    at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
Exception: java.io.IOException: Connection closed, EOF detected
4b9b3361

Ответ 1

Java 7 по умолчанию имеет значение TLS 1.0, которое может вызвать эту ошибку, если этот протокол не принят. Я столкнулся с этой проблемой с приложением Tomcat и сервером, который больше не будет принимать соединения TLS 1.0. Я добавил

-Dhttps.protocols=TLSv1.1,TLSv1.2

для параметров Java и исправил его. (Tomcat запускал Java 7.)

Ответ 2

Я столкнулся с той же проблемой и решил ее, добавив:

System.setProperty("https.protocols", "TLSv1,TLSv1.1,TLSv1.2");

перед методом openConnection.

Ответ 3

Еще не ответ, но слишком много для комментария. Это явно не проблема сертификата сервера; симптомы этого совершенно разные. Из вашей системы POV сервер, кажется, закрывается во время рукопожатия. Возможны две возможности:

Сервер действительно закрывается, что является нарушением протокола SSL/TLS, хотя и довольно незначительным; существует немало причин, по которым сервер может не согласиться с вами, но он должен сначала отправить фатальное предупреждение, которое должно указывать ваш JSSE или эквивалент weblogic. В этом случае может быть некоторая полезная информация в журнале сервера, если вы можете (и разрешено) связываться со знающим администратором сервера (ов). Или вы можете попробовать разместить сетевой монитор на своей клиентской машине или один достаточно близко, чтобы увидеть весь свой трафик; лично мне нравится www.wireshark.org. Но это обычно показывает только, что закрытие произошло сразу после ClientHello, что не сильно сужает его. Вы не говорите, хотите ли вы и настроили "клиентский сертификат" (на самом деле key & cert, в форме Java privateKeyEntry) для этого сервера; если это требуется сервером, а не правильно, некоторые серверы могут воспринимать это как атаку и сознательно нарушать протокол, закрывая, хотя официально они должны отправить предупреждение.

Или, какой-то средний ящик в сети, чаще всего брандмауэр или якобы прозрачный прокси, решает, что ему не нравится ваше соединение и заставляет закрыть. Прокси, который вы используете, является очевидным подозреваемым; когда вы говорите, что "тот же код" работает с другими хостами, подтвердите, означает ли вы через тот же прокси (а не только прокси) и используете HTTPS (непонятный HTTP). Если это не так, попробуйте протестировать другие хосты с помощью HTTPS через прокси (вам не нужно отправлять полный запрос SOAP, просто GET/if enough). Если вы можете, попробуйте подключиться без прокси-сервера или, возможно, другого прокси-сервера, и подключить HTTP (не S) через прокси-сервер к хосту (если обе поддержки ясны) и посмотреть, работают ли они.

Если вы не возражаете опубликовать фактический хост (но определенно не какие-либо учетные данные), другие могут попробовать его. Или вы можете зайти на сайт www.ssllabs.com и попросить их протестировать сервер (без публикации результатов); это попробует несколько общих вариантов соединения SSL/TLS и сообщит о любых обнаруженных ошибках, а также о любых слабых сторонах безопасности.

Ответ 4

Первым шагом для диагностики проблемы является запуск клиента - и, если вы запускаете сервер самостоятельно, частный тестовый экземпляр сервера - путем запуска Java с параметром VM:

-Djavax.net.debug=all

Смотрите также https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https

Ответ 5

Я думаю, что вам не хватает ваших сертификатов.

Вы можете попробовать создать их с помощью приложения InstallCerts. Здесь вы можете увидеть, как его использовать: https://github.com/escline/InstallCert

Как только вы получите сертификат, вам нужно поместить его под свой каталог безопасности в свой дом jdk, например:

C:\Program Files\Java\jdk1.6.0_45\jre\lib\security

Дайте мне знать, если это сработает.

Ответ 6

Я столкнулся с аналогичной проблемой с сервером приложений Glassfish и Oracle JDK/JRE, но не в Open JDK/JRE.

При подключении к домену SSL я всегда сталкивался с:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
...
Caused by: java.io.EOFException: SSL peer shut down incorrectly

Решение для меня состояло в том, чтобы установить файлы политики защиты от переопределения Java Cryptography Extension (JCE) Unlimited Strength, потому что сервер понимал только сертификаты, которые не включены в Oracle JDK по умолчанию, только OpenJDK включает их. После установки все работает как charme.


JCE 7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

JCE 8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

Ответ 7

Я столкнулся с подобной проблемой и обнаружил, что попал в неправильный порт. После исправления порт все отлично работало.

Ответ 8

Спасибо всем за обмен вашими ответами и примерами. Одна и та же автономная программа работала для меня небольшими изменениями и добавила строки кода ниже.

В этом случае файл хранилища ключей был предоставлен поставщиком webservice.

// Small changes during connection initiation.. 

// Please add this static block 

      static {

        HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()

            {   @Override

        public boolean verify(String hostname, SSLSession arg1) {

        // TODO Auto-generated method stub

                if (hostname.equals("X.X.X.X")) {

                    System.out.println("Return TRUE"+hostname);

                    return true;

                }

                System.out.println("Return FALSE");

                return false;

              }
               });
         }


String xmlServerURL = "https://X.X.X.X:8080/services/EndpointPort";


URL urlXMLServer = new URL(null,xmlServerURL,new sun.net.www.protocol.https.Handler());


HttpsURLConnection httpsURLConnection = (HttpsURLConnection) urlXMLServer               .openConnection();

// Below extra lines are added to the same program

//Keystore file 

 System.setProperty("javax.net.ssl.keyStore", "Drive:/FullPath/keystorefile.store");

 System.setProperty("javax.net.ssl.keyStorePassword", "Password"); // Password given by vendor

//TrustStore file

System.setProperty("javax.net.ssl.trustStore"Drive:/FullPath/keystorefile.store");

System.setProperty("javax.net.ssl.trustStorePassword", "Password");

Ответ 9

Я столкнулся с этой проблемой с Java 1.6. Запуск под Java 1.7 исправил мою конкретную реализацию проблемы. Я думаю, что основная причина заключалась в том, что сервер, к которому я подключался, должен был требовать более сильного шифрования, чем доступный под 1.6.

Ответ 10

У меня была такая же ошибка, но в моем случае она была вызвана режимом DEBUG в Intellij IDE. Отладка замедляла библиотеку, а затем завершала связь с сервером на этапе установления связи. Стандартный "RUN" работал отлично.

Ответ 11

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

Я испытал эту ошибку при использовании Джерси-Клиента для подключения к серверу. То, как я решил это, было отладка библиотеки и наблюдение, что она действительно получила EOF в тот момент, когда она пыталась прочитать. Я также попытался подключиться с помощью веб-браузера и получил те же результаты.

Просто напишите это здесь, если это поможет кому-то.

Ответ 12

Вы можете написать этот код ниже, в вашей текущей Java-программе

System.setProperty("https.protocols", "TLSv1.1");

или же

System.setProperty("http.proxyHost", "proxy.com");

System.setProperty("http.proxyPort", "911");

Ответ 13

Я запускаю свое приложение с Java 8 и Java 8, принося сертификат безопасности в свой магазин доверия. Затем я переключился на Java 7 и добавил следующие опции VM:

-Djavax.net.ssl.trustStore=C:\<....>\java8\jre\lib\security\cacerts

Просто я указал на место, где находится сертификат.

Ответ 14

Я использовал p12, который я экспортировал с помощью Keychain в своем MacBook, однако он не работал на моем коде сервера java-apns. Мне нужно было создать новый ключ p12, как указано здесь, используя мои уже сгенерированные клавиши pem:

openssl pkcs12 -export -in your_app.pem -inkey your_key.pem -out your_app_key.p12

Затем обновлен путь к этому новому файлу p12, и все работает отлично.

Ответ 15

Я столкнулся с той же проблемой один раз. Я думаю, что из-за URL

Строка xmlServerURL = " https://example.com/soap/WsRouter";

Проверьте, является ли он правильным или нет?

javax.net.ssl.SSLHandshakeException заключается в том, что сервер не может подключиться к указанному URL из-за следующей причины -

  • Личность веб-сайта не проверяется.
  • Сертификат сервера не соответствует URL-адресу.
  • Или сертификату сервера не доверяют.

Ответ 16

Как вы решаете это, зайдя в

  1. настройки

  2. Поиск "Сеть"

  3. Выберите "Использовать общие настройки прокси-сервера IDEA в качестве Subversion по умолчанию"

Ответ 17

Добавление сертификатов в папку Java\jdk\jre\lib\security работало для меня. Если вы используете Chrome, нажмите зеленую лампу [https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1] и сохраните сертификат в папке безопасности.

Ответ 18

Это то, что решает мою проблему.

Если вы пытаетесь использовать отладчик, убедитесь, что точка останова не указана в URL или URLConnection, просто установите точку останова на BufferReader или внутри цикла while.

Если ничего не работает, попробуйте использовать apache-библиотеку http://hc.apache.org/index.html.

нет SSL, нет необходимости в JDK-обновлении, нет необходимости устанавливать свойства даже, просто простая трюка :)

Ответ 19

SSL занимает больше памяти, чем обычные порты. Просто сделайте доступную память для порта SSL Поиск в конфигурации порта вашего приложения в "headerBufferSize" Я меняю его с 16k на 64k.