ssl handshake failed что за ошибка на смарт тв
Почему возникают ошибки SSL-соединения и как их исправить?
Зачастую после установки SSL-сертификатов многие пользователи сталкиваются с ошибками, которые препятствуют корректной работе защищенного протокола HTTPS.
Предлагаем разобраться со способами устранения подобных ошибок.
Что такое SSL?
SSL (Secure Socket Layer) — это интернет-протокол для создания зашифрованного соединения между пользователем и сервером, который гарантирует безопасную передачу данных.
Когда пользователь заходит на сайт, браузер запрашивает у сервера информацию о наличии сертификата. Если сертификат установлен, сервер отвечает положительно и отправляет копию SSL-сертификата браузеру. Затем браузер проверяет сертификат, название которого должно совпадать с именем сайта, срок действия сертификата и наличие корневого сертификата, выданного центром сертификации.
Причины возникновения ошибок SSL-соединения
Когда сертификат работает корректно, адресная строка браузера выглядит примерно так:
Но при наличии ошибок она выглядит несколько иначе:
Существует множество причин возникновения таких ошибок. К числу основных можно отнести:
Давайте рассмотрим каждую из них подробнее.
Проблемы с датой и временем
Если на устройстве установлены некорректные дата и время, ошибка SSL-соединения неизбежна, ведь при проверке сертификата происходит проверка срока его действия. Современные браузеры умеют определять такую ошибку самостоятельно и выводят сообщение о неправильно установленной дате или времени.
Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.
Ненадежный SSL-сертификат
Иногда при переходе на сайт, защищенный протоколом HTTPS, появляется ошибка «SSL-сертификат сайта не заслуживает доверия».
Одной из причин появления такой ошибки, как и в предыдущем случае, может стать неправильное время. Однако есть и вторая причина — браузеру не удается проверить цепочку доверия сертификата, потому что не хватает корневого сертификата. Для избавления от такой ошибки необходимо скачать специальный пакет GeoTrust Primary Certification Authority, содержащий корневые сертификаты. После скачивания переходим к установке. Для этого:
После вышеперечисленных действий можно перезагрузить устройство и проверить отображение сайта в браузере.
Брандмауэр или антивирус, блокирующие сайт
Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет. Однако таким образом вы снизите безопасность своего устройства, так как содержимое сайта может быть небезопасным, а контроль сайта теперь отключен.
Также SSL может блокировать антивирусная программа. Попробуйте отключить в антивирусе проверку протоколов SSL и HTTPS и зайти на сайт. При необходимости добавьте сайт в список исключений антивируса.
Включенный экспериментальный протокол QUIC
QUIC — это новый экспериментальный протокол, который нужен для быстрого подключения к интернету. Основная задача протокола QUIC состоит в поддержке нескольких соединений. Вы можете отключить этот протокол в конфигурации вашего браузера.
Показываем как отключить QUIC на примере браузера Google Chrome:
Этот способ работает и в Windows и в Mac OS.
Отсутствие обновлений операционной системы
Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.
Использование SSL-сертификата версии 3.0
Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):
Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера
В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:
Как исправить ошибки безопасности SSL в браузере
При открытии сайтов в браузере иногда возникают ошибки – домен в адресной строке выделяется красным с зачеркиванием или ресурс вообще не открывается. Типовая причина скрывается в сбоях работы сертификата SSL. Исправить их может только администратор сайта, но перед обращением к нему стоит проверить собственный компьютер.
Что такое SSL
Текущие тенденции сайтостроения предполагают высокую безопасность соединения пользователя с веб-ресурсом. Это необходимо для защиты персональных данных, секретных номеров банковских карт и информации о проводимых сделках. Организуется безопасность подключением протокола шифрования Secure Sockets Layer (сокращенно SSL).
Работа сайта возможна и без SSL, но поисковые системы «не доверяют» таким ресурсам и помечают их в браузере как неблагонадежные. Поэтому лучше разобраться, как решить проблему с защитой и полноценно пользоваться протоколом HTTPS. Сертификат актуален на сайтах, где присутствует регистрация, предлагается покупка товаров или онлайн-оплата различных сервисов.
При появлении любых сомнений в исправности защиты регистрироваться на сайте или вводить ранее выданные логин и пароль не рекомендуется. Тем более не стоит осуществлять онлайн-оплату с банковских карт или электронных кошельков, ведь не исключено, что проблема возникла из-за взлома ресурса злоумышленниками.
Причины появления ошибок SSL
Существует всего две причины, почему браузер отображает ошибку сертификата SSL со стороны сервера. Первая заключается в окончании срока активации, вторая – это покупка сертификата у поставщика без достаточных полномочий для выдачи «полноценной защиты». Например, виной может быть выбор самоподписанного сертификата, лишь эмулирующего работу реального протокола.
Остальные проблемы обычно скрываются на локальном компьютере:
Чтобы выяснить настоящую причину, пользователю браузера рекомендуется проверить все перечисленные факторы. При том же заражении компьютерными вирусами возможно проявление сразу нескольких симптомов – от изменения текущего времени и блокировки антивирусом до подключения перенаправления страниц в браузере и других неприятностей.
Изредка встречаются ситуации, когда проблема возникла со стороны администратора, если он ошибся при подключении нового сертификата или забыл продлить его действие. Обычно такие неполадки устраняются быстро, потому что после активации сайт проверяется и, в случае неработоспособности сертификата, проводится повторное подключение вплоть до получения положительного результата.
Время и дата
Сертификат SSL имеет четко обозначенный срок действия с датой активации и деактивации. Такой подход отчасти дает дополнительную защиту, потому что в случае технического сбоя в системных часах компьютера сайты перестают открываться. Сброс времени обычно происходит «назад», на дату изготовления материнской платы, на что и реагирует система.
Варианты исправления ситуации:
Каждый раз после изменения времени рекомендуется ручное обновление страницы или перезапуск браузера. Такой шаг активирует повторное соединение с сервером и позволяет зайти на сайт «с нуля», но уже с правильным временем, соответствующим сроку действия сертификата SSL (после активации и до ее завершения).
Настройки антивируса и брандмауэра
Программы для защиты компьютера от вирусов и хакерских атак иногда блокируют и «полезные» соединения, например, определенные домены или сразу весь протокол HTTPS, используемый при подключении сертификата SSL. Большинство антивирусов и брандмауэров проверяют его работу, и это становится причиной блокировки сайта как «злоумышленника, пытающего украсть данные».
Варианты исправления ситуации:
Функция временного отключения имеется в любой защитной программе, даже интегрированной в операционную систему Windows. Но это не гарантирует полную деактивацию приложения. В этом случае разобраться в ситуации поможет открытие сайта на другом компьютере или запуск безопасного режима (актуально для проводного подключения к интернету).
Браузер и операционная система
Наличие проблемы с браузером проще всего определить открытием сайта на другом устройстве или в другой программе. Иногда решение заключается в банальном обновлении версии приложения до актуальной. То же относится к операционной системе, если используется интегрированный браузер вроде Edge. Пакеты обновлений для того и выпускаются, чтобы устранять неполадки в ПО.
Варианты исправления ситуации:
Остается еще один вариант – сбросить настройки браузера до состояния «по умолчанию». Способ аналогичен переустановке, но экономит время. Правда, он неэффективен, если проблема возникла из-за сбоя в одном из служебных файлов программы. Отдельное внимание стоит уделить расширению, выполняющему функции антивирусной защиты, ведь оно часто блокирует даже безопасное соединение.
Заражение компьютерными вирусами
Выдачей ошибки SSL браузер, вероятно, предупреждает о попытке его подмены, переадресации на сайт-клон или иной угрозе. В это случае рекомендуется провести полную проверку компьютера на наличие вирусов. Если присутствуют другие признаки заражения, стоит скачать парочку программ со свежими антивирусными базами (например, CureIt).
Варианты исправления ситуации:
Выполняются перечисленные действия программами типа CCleaner. Они дают прямой доступ как к автозагрузке операционной системе, так и к списку расширений установленных браузеров. Также в таких программах обычно есть функция удаления ненужных системных файлов, в которых запросто может быть тело компьютерного вируса.
Если предложенные способы устранения ошибки SSL не помогли, остается ждать, пока проблему устранит администратор, или воспользоваться любым другим тематическим сайтом с аналогичным контентом.
Ssl handshake failed что это
Пытаюсь использовать FTP на моем сайте. Я удостоверился, что мой IP-адрес не заблокирован, и я использую правильные порты, но я все еще получаю этот журнал ошибок:
Ошибка: От сервера получено TLS оповещение: Handshake failed (40)
Ошибка: Невозможно подключиться к серверу
1 ответ 1
Везде пишут, что причиной тому то, что сервер и клиент не имеют общих протоколов шифрования. И скорее всего сервер хочет rc4, которій біл отключен в FileZilla. Варианты решения
Недавно мне пришлось прикручивать SSL с двухсторонней аутентификацией (mutual authentication) к Spring Reactive Webclient. Казалось бы, дело нехитрое, но вылилось оно в блуждание в исходниках JDK с неожиданным финалом. Опыта набралось на целую статью, которая может оказаться полезной инженерам в повседневных задачах или при подготовке к собеседованию.
Постановка задачи
Есть REST-сервис на стороне заказчика, который работает через HTTPS.
Необходимо обращаться к нему из клиентского Java приложения.
Далее следовало правильно сконфигурировать клиентское Java приложение.
Для REST-запросов я использовала Spring Reactive WebClient с неблокирующим вводом-выводом.
В документации есть пример, как его можно кастомизировать, прокинув ему объект SslContext, который как раз хранит сертификаты и приватные ключи.
Моя конфигурация в упрощённом варианте была практически копипастой из документации:
Придерживаясь принципа TDD, я также написала тест, в котором вместо WebClient используется WebTestClient, выводящий кучу отладочной информации. Самый первый assertion был таким:
Этот простой тест сразу же не прошёл: сервер вернул 500 с таким же body, как и в случае, если в Postman не указать клиентский сертификат.
Отдельно отмечу, что на время отладки, я включила опцию «не проверять серверный сертификат», а именно — передала инстанс InsecureTrustManagerFactory в качестве TrustManager для SslContext. Эта мера была избыточной, но исключала половину вариантов наверняка.
Отладочная информация в тесте не проливала свет на проблему, но выглядело всё, будто что-то пошло не так на этапе SSL handshake, поэтому я решила более подробно сравнить как происходит соединение в обоих случаях: для Postman и для Java клиента. Всё это можно посмотреть используя Wireshark — это такой популярный анализатор сетевого трафика. Заодно увидела как происходит SSL handshake с двухсторонней аутентификацией, так сказать, вживую (это очень любят спрашивать на собеседованиях):
После пятнадцати минут втыкания в траффик, я заметила, что Java клиент в ответ на Certificate Request от сервера, по какой-то причине не отправляет свой сертификат, в отличие от Postman клиента. То есть, Certificate message есть, но он пустой.
Дальше мне нужно было бы посмотреть сначала в спецификацию протокола TLS, которая говорит буквально следующее:
If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.
Речь идёт о списке certificate_authorities, указанном в Certificate Request message, приходящем от сервера. Клиентский сертификат (хотя бы один из цепочки) должен быть подписан одним из issuers, перечисленных в этом списке. Назовём это проверкой X.
Я об этом условии не знала и обнаружила его, когда дошла в отладке до глубин JDK (у меня это JDK9). Netty HttpClient, который лежит в основе Spring WebClient, использует по умолчанию SslEngine из JDK. Альтернативно можно переключить его на OpenSSL провайдер, добавив необходимые зависимости, но мне это, в конечном счёте, не потребовалось.
Итак, я расставила брейкпоинты внутри sun.security.ssl.ClientHandshaker класса и в хэндлере для serverHelloDone сообщения обнаружилась проверка X, которая не проходила: ни один из issuer-ов в цепочке клиентского сертификата не находился в списке issuer-ов, которым доверяет сервер (из Certificate Request message от сервера).
Я обратилась к заказчику за новым сертификатом, но заказчик возразил, что у него всё работает отлично, и вручил Python скрипт, которым он обычно проверял работоспособность сертификатов. Скрипт не делал ничего лишнего, кроме отправки HTTPS запроса с использованием Requests библиотеки, и возвращал 200 OK. Окончательно я удивилась, когда старый добрый curl тоже вернул 200 OK. Сразу вспомнился анекдот: «Вся рота идет не в ногу, один поручик шагает в ногу».
Curl — это, конечно, авторитетная утилита, но и TLS стандарт тоже не кусок туалетной бумаги. Не зная, что ещё можно проверить, я полезла бесцельно бродить по документации к curl, и на Github, где обнаружила вот такой известный баг.
Репортер описывал точь-в-точь проверку X: в curl с дефолтным бекэндом (OpenSSL) она не выполнялась, в отличие от curl с GnuTLS бекендом. Я не поленилась, собрала curl из исходников с опцией –with-gnutls, и отправила многострадальный реквест. И, наконец-то, ещё один клиент, кроме JDK, вернул HTTP статус 500 вместе с «Secutiry exception»!
Я написала об этом заказчику в ответ на аргумент «Ну curl-же работает» и получила новый сертификат, заново сгенеренный и аккуратно установленный на сервере. С ним моя конфигурация для WebClient заработала отлично. Happy End.
Эпопея с настройкой SSL заняла со всеми переписками больше двух недель (туда же вошло изучение подробных логов Java, ковыряние кода другого проекта, который у заказчика работает, и просто ковыряние в носу).
Что меня долго сбивало с толку, помимо разницы в поведении клиентов, так это то, что сервер был настроен таким образом, что сертификат запрашивал, но не проверял. Однако, и на это есть пояснения в спеке:
Handshake (рукопожатие) SSL/TLS состоит из того, что сервер и клиент идентифицируют друг друга и начинают общение через шифрованный SSL/TLS-туннель (который является безопасным).
Данный процесс и называется handshak-ом или рукопожатием из-за того, что они (сервер и клиент) видятся первый раз. Такой процесс, начинается с идентификации и заканчивается генерированием секретного ключа.
Что такое SSL/TLS-рукопожатие?
SSL handshake – это общение сервера и клиента между собой, где каждый хочет достичь одной и той же цели – безопасно общаться с помощью симметричного шифрования. При таком шифровании у двух сторон один ключ для шифрования и дешифрования сообщений. Такой ключ называется общим секретным – у всех пользователей, которые обмениваются данными, один и тот же ключ.
Принцип работы handshake (рукопожатие) SSL/TLS
Расмотрим диалог сервера и клиента:
Клиент: «Здравствуйте сервер! Я бы хотел установить безопасное соединение между нами. От себя, я отсылаю свои шифры и совместимую SSL/TLS версию».
Сервер: «Здравствуйте, клиент! Я проверил шифр который получил от тебя и SSL/TLS версию, которую ты используешь. Нет повода отсоединятся, так что — продолжаем…. От себя, я хотел бы отправить свой сертификат-файл и публичный ключ. Клиент, проверь их пожалуйста».
Клиент: » Такс, твой сертификат в порядке. Но мне необходимо, чекнуть твой закрытый ключ. Для этого, я сейчас сгенерирую и зашифрую общий секретный ключ с помощью твоего открытого ключа. Выполни расшифровку с помощью своего приватного ключика. Если все пройдет гладко, — ты в свою очередь, создашь главный секрет, который мы в дальнейшем, будем использовать для шифрования и расшифрования информации».
Сервер: «Понял! Все сделано».
С этого момента, когда сервер и клиент доверяют друг другу, то инфу которую они будут передавать между собой, будет зашифрована с помощью главного секрета (После проверок, информация будет зашифрована только через главный секретный ключ).
Клиент: «И так, для тестирования — я отправлю тестовое сообщение, дабы удостоверится, что созданный главный секрет корректно работает. Сервер, ты в свою очередь, когда получишь это тестовое сообщение — отправь мне расшифрованную версию этого сообщения. Если все получится, наши данные — в безопасности».
Сервер: «Да, все прочто отлично. Работает!».
Вот такое вот SSL/TLS-рукопожатие. С этого момента, когда сервер и клиент будут передавать файлы, они будут зашифрованы.
Решение некоторых проблем с handshake (рукопожатием) SSL/TLS
Ошибка «SSL_do_handshake errors с nginx или haproxy»
Если вы загружаете https трафик с haproxy в tcp-режиме, и вы выполняете это с помощью nginx, и вы получаете 502 ошибки, сопровождаемые этими ошибками SSL в журнале ошибок nginx:
То вам нужно отключить опцию proxy_ssl_session_reuse:
По умолчанию nginx пытается повторно использовать сеансы ssl для https upstream; но когда HAProxy циклично обрабатывает tcp-соединения между разными бэкендами, сеанс ssl не будет действителен с одного подключения tcp к другому.
Вот и все, статья «Принцип работы handshake (рукопожатие) SSL/TLS» завершена.
Как исправить ошибку SSL подключения
SSL — так называется криптографический протокол, с помощью которого обеспечивается безопасность подключения связи.
Когда при работе в сети Интернет выдаётся «ошибка SSL», то это действительно может обозначать, что кто-то случайно или умышленно пытается получить данные, отсылаемые вами в Сеть. Но далеко не всегда стоит опасаться и сразу пытаться исправить ошибку SSL. Нередко такая ошибка может означать лишь неверные настройки браузера, перехват соединений вашим же антивирусом (антивирус принимают за злоумышленника, а получаемых им данных уж опасаться не следует), или вообще проблемы не у вас, а с сайтом, на который вы пытаетесь зайти.
Если всё-таки есть малейшие сомнения, лучше переподключитесь к Интернету, зайдите с другого браузера и проверьте, появится ли ошибка SSL подключения в этом случае.
Рассмотрим возможные варианты исправления ошибки SSL в конкретных ситуациях.
Как исправить ошибку SSL в Google Chrome и Yandex браузере.
Итак, вам не удаётся зайти на тот или иной сайт — «выскакивает» проблема с сертификатом безопасности. Как уже и говорилось, беспокоиться не стоит — вначале просто переподключитесь и поменяйте браузер. Если ошибка продолжает появляться, то:
Если всё это не помогло устранить ошибку ssl, можете отключить проверку SSL в браузере, но вот это уже может быть не совсем безопасным. Лучше перед этим изучите всю информацию о подозрительном сайте.
Устранение ошибки SSL на планшете — куда более актуальный вопрос, чем на компьютере.
Дело в том, что, начиная с Android 2.3, алгоритмы шифрования на планшетах стали заметно слабее и вероятность их дешифровки злоумышленниками (т.е. получения доступа к вашим данным) — значительно выше. Это приводит к не самой благоприятной ситуации:
Основные меры безопасности и устранения ошибок приведены выше и многие из них подойдут для планшетов, но, если вам дорога безопасность тех или иных данных, пока что лучше воздержаться от того, чтобы вводить их на планшетах без особой необходимости на подозрительных сайтах.
Если у Вас не получается что то сделать самостоятельно, то советуем обратится в скорую компьютерную помощь — pchelp24.com, приемлемые цены, опытные специалисты, бесплатный вызов и диагностика.
Сбои SSL-рукопожатия
Специализированный учебник по сбоям SSL-квитирования и тому, как их исправить.
1. Обзор
Защищенный уровень сокета (SSL) – это криптографический протокол, который обеспечивает безопасность при передаче данных по сети. В этом уроке мы обсудим различные сценарии, которые могут привести к сбою SSL-квитирования, и как это сделать.
Обратите внимание, что наше введение в SSL с использованием JSSE более подробно описывает основы SSL.
2. Терминология
Важно отметить, что из-за уязвимостей безопасности SSL как стандарт заменяется TLS (Transport Layer Security). Большинство языков программирования, включая Java, имеют библиотеки для поддержки как SSL, так и TLS.
С момента создания SSL многие продукты и языки, такие как OpenSSL и Java, имели ссылки на SSL, которые они сохраняли даже после того, как TLS взял верх. По этой причине в оставшейся части этого руководства мы будем использовать термин SSL для обозначения криптографических протоколов.
3. Настройка
Для целей этого урока мы создадим простые серверные и клиентские приложения, использующие API сокетов Java для имитации сетевого подключения.
3.1. Создание Клиента и Сервера
Давайте начнем с определения простого сервера:
Сервер, определенный выше, возвращает сообщение “Hello World!” подключенному клиенту.
Далее давайте определим базовый клиент, который будет подключаться к нашему Простому серверу:
Наш клиент печатает сообщение, возвращенное сервером.
3.2. Создание сертификатов на Java
SSL обеспечивает секретность, целостность и подлинность сетевых коммуникаций. Сертификаты играют важную роль в установлении подлинности.
Как правило, эти сертификаты приобретаются и подписываются Центром сертификации, но в этом руководстве мы будем использовать самозаверяющие сертификаты.
Для достижения этой цели мы можем использовать инструмент для ключей, который поставляется с JDK:
Обратите внимание, что serverkeystore.jks хранится в формате хранилища ключей Java (JKS), который является собственностью Java. В эти дни keytool напомнит нам, что мы должны рассмотреть возможность использования PKCS#12, который он также поддерживает.
Далее мы можем использовать keytool для извлечения открытого сертификата из сгенерированного файла хранилища ключей:
Теперь мы создали хранилище ключей для сервера и соответствующее хранилище доверия для клиента. Мы рассмотрим использование этих сгенерированных файлов, когда будем обсуждать возможные сбои при рукопожатии.
4. SSL-рукопожатие
Это очень организованная процедура, и понимание ее деталей может помочь понять, почему она часто терпит неудачу, о чем мы намерены рассказать в следующем разделе.
Типичными шагами в SSL-рукопожатии являются:
Хотя большинство шагов одинаковы для любого SSL-рукопожатия, существует тонкая разница между односторонним и двусторонним SSL. Давайте быстро рассмотрим эти различия.
4.1. Рукопожатие в одностороннем SSL
4.2. Рукопожатие в двустороннем SSL
5. Сценарии Сбоя Рукопожатия
Проведя этот краткий обзор, мы можем с большей ясностью взглянуть на сценарии сбоев.
SSL-рукопожатие при односторонней или двусторонней связи может завершиться неудачей по нескольким причинам. Мы рассмотрим каждую из этих причин, смоделируем сбой и поймем, как мы можем избежать таких сценариев.
5.1. Отсутствует сертификат Сервера
Теперь это указывает на то, что что-то пошло не так. Исключение SSLHandshakeException выше, абстрактно, указывает, что клиент при подключении к серверу не получил никакого сертификата.
Для решения этой проблемы мы будем использовать хранилище ключей, созданное ранее, передавая их на сервер в качестве системных свойств:
Важно отметить, что системное свойство для пути к файлу хранилища ключей должно быть либо абсолютным путем, либо файл хранилища ключей должен быть помещен в тот же каталог, из которого вызывается команда Java для запуска сервера. Системное свойство Java для хранилища ключей не поддерживает относительные пути.
Помогает ли это нам получить результат, который мы ожидаем? Давайте выясним это в следующем подразделе.
5.2. Сертификат ненадежного Сервера
Когда мы снова запускаем SimpleServer и Simple Client с изменениями в предыдущем подразделе, что мы получаем в качестве вывода:
Ну, это сработало не совсем так, как мы ожидали, но, похоже, это не сработало по другой причине.
Этот конкретный сбой вызван тем, что наш сервер использует самозаверяющий сертификат, который не подписан Центром сертификации (ЦС).
Действительно, каждый раз, когда сертификат подписывается чем-то другим, чем то, что находится в хранилище доверия по умолчанию, мы увидим эту ошибку. Хранилище доверия по умолчанию в JDK обычно поставляется с информацией об обычных используемых автомобилях.
Обратите внимание, что это не идеальное решение. В идеальном сценарии мы должны использовать не самозаверяющий сертификат, а сертификат, сертифицированный Центром сертификации (ЦС), которому клиенты могут доверять по умолчанию.
Давайте перейдем к следующему подразделу, чтобы узнать, получим ли мы ожидаемый результат сейчас.
5.3. Отсутствие Сертификата Клиента
Давайте попробуем еще раз запустить Простой сервер и Простой клиент, применив изменения из предыдущих подразделов:
Опять же, не то, что мы ожидали. Исключение SocketException здесь говорит нам, что сервер не может доверять клиенту. Это связано с тем, что мы установили двусторонний SSL. В нашем Простом сервере у нас есть:
Приведенный выше код указывает на SSLServerSocket требуется для аутентификации клиента через его публичный сертификат.
Мы можем создать хранилище ключей для клиента и соответствующее хранилище доверия для сервера способом, аналогичным тому, который мы использовали при создании предыдущего хранилища ключей и хранилища доверия.
Мы перезагрузим сервер и передадим ему следующие системные свойства:
Затем мы перезапустим клиент, передав эти системные свойства:
Наконец, у нас есть желаемый результат:
5.4. Неверные Сертификаты
Помимо вышеперечисленных ошибок, рукопожатие может завершиться неудачей по целому ряду причин, связанных с тем, как мы создали сертификаты. Одна распространенная ошибка связана с неправильным CN. Давайте рассмотрим детали хранилища ключей сервера, которое мы создали ранее:
Когда мы выполняем приведенную выше команду, мы можем увидеть детали хранилища ключей, в частности владельца:
Трассировка исключений выше ясно указывает на то, что клиент ожидал сертификат с именем localhost, который он не нашел.
Обратите внимание, что JSSE по умолчанию не требует проверки имени хоста. Мы включили проверку имени хоста в Простом клиенте с помощью явного использования HTTPS:
5.5. Несовместимая версия SSL
В настоящее время существуют различные криптографические протоколы, включая различные версии SSL и TLS.
Как упоминалось ранее, SSL, в целом, был заменен TLS из-за его криптографической прочности. Криптографический протокол и версия являются дополнительным элементом, который клиент и сервер должны согласовать во время рукопожатия.
В нашем Простом клиенте давайте изменим протокол на что-то, что не совместимо с протоколом, установленным для сервера:
Когда мы снова запустим наш клиент, мы получим исключение SSLHandshakeException :
Трассировка исключений в таких случаях является абстрактной и не говорит нам о точной проблеме. Для решения этих типов проблем необходимо убедиться, что и клиент, и сервер используют одни и те же или совместимые криптографические протоколы.
5.6. Несовместимый набор шифров
Клиент и сервер также должны договориться о наборе шифров, которые они будут использовать для шифрования сообщений.
В нашем Простом клиенте давайте изменим набор шифров на что-то, что не совместимо с набором шифров, используемым нашим сервером:
Когда мы перезапустим наш клиент, мы получим исключение SSLHandshakeException :
Опять же, трассировка исключений довольно абстрактна и не говорит нам о точной проблеме. Решение такой ошибки заключается в проверке включенных наборов шифров, используемых как клиентом, так и сервером, и обеспечении наличия по крайней мере одного общего набора.
Обычно клиенты и серверы настроены на использование широкого спектра наборов шифров, поэтому вероятность возникновения этой ошибки меньше. Если мы сталкиваемся с этой ошибкой, это обычно связано с тем, что сервер настроен на использование очень избирательного шифра. Сервер может выбрать принудительное применение выборочного набора шифров по соображениям безопасности.
6. Заключение
В этом уроке мы узнали о настройке SSL с помощью сокетов Java. Затем мы обсудили SSL-рукопожатия с односторонним и двусторонним SSL. Наконец, мы рассмотрели список возможных причин, по которым SSL-рукопожатия могут не сработать, и обсудили решения.