javax.net.ssl. SSLHandshakeException: Удаленный хост закрыл соединение во время квитирования во время веб-сервиса communicaiton

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

, При попытке использовать отладчик, удостоверяются, что Вы устанавливаете контрольные точки, не находится на URL, или URLConnection просто помещают Вашу точку останова на BufferReader или в цикле с условием продолжения.

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

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

То, как Вы решили бы его, путем движения в

1. Настройки

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

3. Выбирает "Use IDEA general proxy settings as default Subversion"

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

xmlServerURL =" https://example.com/soap/WsRouter";

Проверка, является ли это надлежащим или нет??

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

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

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

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

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

Можно Записать это ниже кода в текущей программе

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

или

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

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

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

-Djavax.net.debug=all

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

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

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

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

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

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

к опциям Java, и это зафиксировало его. (Tomcat выполнял Java 7.)

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

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

Просто запись этого здесь в случае, если это заканчивает тем, что помогло любому.

У меня была та же ошибка, но в моем случае она была вызвана Режимом отладки в IDE Intellij. Отладка замедлила библиотеку, и затем сервер закончил коммуникацию в фазе квитирования. "ВЫПОЛНЕННЫЙ" стандарт работал отлично.

Я встретился с подобной проблемой с сервером приложений glassfish и Oracle, JDK/JRE, но не в Открывают JDK/JRE.

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

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

решение для меня состояло в том, чтобы установить Расширение криптографии Java (JCE) Неограниченные Файлы политики Юрисдикции Силы , потому что сервер только понял сертификаты, которые не включены в 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

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

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

Благодаря всем для совместного использования Ваших ответов и примеров. Та же автономная программа работала на меня небольшими изменениями и добавлением строк кода ниже.

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

// 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");

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

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

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

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

Я думаю, что Вы пропускаете свои сертификаты.

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

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

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

Сообщенный мне, если это работает.

Не ответ все же, но слишком много для комментария. Это - ясно не проблема сертификата сервера; признаки этого очень отличаются. От POV Вашей системы сервер, кажется, закрывается во время квитирования. Существует две возможности:

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

Или, некоторый middlebox в сети, чаще всего брандмауэр или предположительно прозрачный прокси, решает, что этому не нравятся Ваше соединение и принуждение завершения. Прокси, который Вы используете, является очевидным подозреваемым; когда Вы говорите, что "тот же код" работы к другим хостам, подтвердите, имеете ли Вы в виду через тот же прокси (не только, прокси) и использование HTTPS (не очищают HTTP). Если это не так, попытайтесь тестировать к другим хостам с HTTPS через прокси (Вы не должны отправлять полный запрос SOAP, просто ПОЛУЧЕНИЕ / если достаточно). Если Вы можете, попытаться соединиться без прокси или возможно другого прокси, и соединить HTTP (не S) через прокси к хосту (если обе ясная поддержки), и посмотрите, работают ли они.

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