Летучая мышь запускает hello tls зависает

Обновлено: 21.11.2024

В приведенном ниже журнале (последние две строки) сервер, похоже, отправляет ответ до завершения запроса, инициируя рукопожатие tls. Когда это происходит, curl не продолжает рукопожатие и связь зависает.

Для некоторых запросов с одного и того же сервера ответ приходит после завершения запроса, после чего все работает как положено.

клиент: Linux 5.11.7-arch1-1
сервер: Microsoft-IIS/8.5

Текст был успешно обновлен, но возникли следующие ошибки:

прокомментировал багдер 25 марта 2021 г. •

Полагаю, что авторизация сертификата клиента часто инициируется повторным согласованием.

danjohansson прокомментировал 25 марта 2021 г.

@jay вот информация о версии

danjohansson прокомментировал 25 марта 2021 г. •

@bagder Я постараюсь дать больше контекста тому, что я делаю.
Я выполняю загрузку на сервер, для которого требуется сертификат клиента. Загрузка проходит успешно, но когда я получаю ответ слишком рано, повторное согласование начинается до завершения загрузки. Потом зависает. Curl не отвечает приветствием клиента.
Похоже, что с этим сервером возникла гонка, потому что иногда ответ действительно успешен для одних и тех же данных. Когда это происходит, запрос Hello регистрируется после того, как мы полностью загружены и все в порядке.
Кроме того, если я проверю сетевой трафик, я увижу, что журнал curl находится в том же порядке, что и пакеты для запроса приветствия и завершения загрузки.

При необходимости я буду рад предоставить дополнительную информацию.
Спасибо

Джей прокомментировал 26 марта 2021 г.

Возможно ли, что вы могли бы использовать SSLKEYLOGFILE для дальнейшего изучения этого? Меня интересует зависание клиента или сервера, но у меня нет возможности воспроизвести это здесь.

danjohansson прокомментировал 27 марта 2021 г.

@jay вот pcap неудачного сеанса:
failed.pcap.zip

Я заметил, что запрос приветствия от сервера поступает до завершения POST как в успешных, так и в неудачных сеансах (в предыдущем комментарии я сказал по-другому). Но приветственный запрос всегда регистрируется до того, как мы полностью загрузимся, и нормально, когда сеанс зависает.

Джей прокомментировал 27 марта 2021 г.

danjohansson прокомментировал 27 марта 2021 г.

@jay Думаю, ты прав. Спасибо за внимание.

Джей прокомментировал 27 марта 2021 г.

Может быть, мы делаем что-то не так, но я не знаю, что именно. OpenSSL говорит, что повторные согласования должны быть прозрачными для SSL_read/SSL_write. Не могли бы вы попробовать jay:ossl_dbg_sendrecv и опубликовать подробный вывод?

danjohansson прокомментировал 28 марта 2021 г. •

@jay Спасибо за дальнейшее изучение этого вопроса. Это результат:

POST /rdtws/secure/ExternalWebServiceSecure.asmx HTTP/1.1 > Host: rdtoc.transportstyrelsen.se > User-Agent: curl/7.76.0-DEV > Accept: */* > SOAPAction: "http://www .vv.se/rdt/secure/LevereraForeteelse" > Content-Type: text/xml; charset=utf-8 > Content-Length: 48141 > ossl_send BEGIN ossl_send SSL_ERROR_WANT_WRITE ossl_recv BEGIN * TLSv1.2 (IN), рукопожатие TLS, запрос Hello (0): ossl_recv SSL_ERROR_WANT_READ ossl_send BEGIN ossl_send END * Мы полностью загружены и в порядке">

danjohansson прокомментировал 28 марта 2021 г. •

Успешный сеанс выглядит следующим образом:

POST /rdtws/secure/ExternalWebServiceSecure.asmx HTTP/1.1 > Host: rdtoc.transportstyrelsen.se > User-Agent: curl/7.76.0-DEV > Accept: */* > SOAPAction: "http://www .vv.se/rdt/secure/LevereraForeteelse" > Content-Type: text/xml; charset=utf-8 > Content-Length: 48141 > ossl_send BEGIN ossl_send SSL_ERROR_WANT_WRITE ossl_send BEGIN ossl_send END * Мы полностью загружены и в порядке ossl_recv BEGIN * TLSv1.2 (IN), рукопожатие TLS, запрос Hello (0): * TLSv1.2 (ВЫХОД), рукопожатие TLS, приветствие клиента (1): ossl_recv SSL_ERROR_WANT_READ ossl_recv BEGIN * TLSv1.2 (вход), рукопожатие TLS, приветствие сервера (2): * TLSv1.2 (вход), рукопожатие TLS, сертификат (11): * TLSv1.2 (ВХОД), рукопожатие TLS, запрос CERT (13): * TLSv1.2 (ВХОД), рукопожатие TLS, сервер завершен (14): * TLSv1.2 (ИСХОД), рукопожатие TLS, сертификат (11): * TLSv1.2 (OUT), рукопожатие TLS, обмен ключами клиента (16): * TLSv1.2 (OUT), рукопожатие TLS, проверка CERT (15): * TLSv1.2 (OUT), изменение шифра TLS, изменение спецификации шифра (1): * TLSv1.2 (OUT), рукопожатие TLS, завершено (20): ossl_recv SSL_ERROR_WANT_READ ossl_recv BEGIN * TLSv1.2 (IN), рукопожатие TLS, завершено (20): ossl_recv SSL_ERROR_WANT_READ ossl_recv BEGIN ossl_recv END * Пометить пакет как не поддерживает многоразовое использование

danjohansson прокомментировал 29 марта 2021 г.

@jay Я получаю тот же результат с последним PR. Я предполагаю, что это означает, что мы ждем, пока openssl продолжит рукопожатие, но этого не происходит?

Джей прокомментировал 29 марта 2021 г.

@jay Я получаю тот же результат с последним PR. Я предполагаю, что это означает, что мы ждем, пока openssl продолжит рукопожатие, но этого не происходит?

Я допустил ошибку в первом коммите, поэтому вы могли увидеть дополнительные SSL_WANT_. на выходе. Я скорректировал оба ваших подробных журнала вывода, чтобы удалить лишние неверные строки, что исправлено в последнем коммите (то есть в том, который вы только что протестировали), и нет причин повторно публиковать результаты.

прокомментировал багдер 16 августа 2021 г.

Действительно ли стоит оставлять этот вопрос открытым, если мы считаем, что это проблема OpenSSL? Здесь ничего не произойдет.

danjohansson прокомментировал 10 января 2022 г.

Теперь я рассмотрел этот вопрос более внимательно. И я думаю, что проблема заключается в том, что Curl больше не вызывает ossl_recv, хотя последний вызов вернул SSL_ERROR_WANT_READ.

Следующая фиксация 1650b5f делает так, что ossl_recv вызывается снова, и проблема не может быть воспроизведена с этим исправлением.

Хотя исправление работает, кажется, что оно генерирует много вызовов ossl_recv, и, возможно, его следует повторить по-другому?

Джей прокомментировал 10 января 2022 г.

Это сложно. Мы следим за их документацией. Когда SSL_read возвращает SSL_ERROR_WANT_READ, это должно означать (по крайней мере, в нашем случае), что все, что можно было прочитать, было прочитано, и поэтому мы ждем на сокете:

Затем вызывающий процесс должен повторить вызов после выполнения соответствующих действий, чтобы удовлетворить потребности функции чтения. Действие зависит от основного BIO. При использовании неблокирующего сокета ничего делать не нужно, но можно использовать select() для проверки требуемого условия

На этом этапе воспроизведения curl ожидает не только получения данных, но и их отправки из-за сбоя SSL_write, который произошел ранее. Согласно ошибке ossl, в основном они, кажется, говорят, что не могут отправить подтверждение рукопожатия во время SSL_read из-за неполного SSL_write. Если запись уже была частично отправлена ​​(что в данном случае не было, но давайте дадим им шанс), то, возможно, требуется, чтобы до тех пор, пока остальная часть этой записи не была отправлена, рукопожатие не могло быть отправлено. Так почему же они не могут отправить следующее сообщение в рукопожатии во время SSL_write? IMO, это ошибка в OpenSSL, и бремя лежит на них.

В этом руководстве описываются методология и некоторые инструменты, помогающие диагностировать проблемы и ошибки подключения TLS (предупреждения TLS). Он сопровождает основное руководство по TLS в RabbitMQ. Стратегия состоит в том, чтобы протестировать необходимые компоненты с альтернативной реализацией TLS в процессе устранения, чтобы определить проблемный конец (клиент или сервер).

Имейте в виду, что этот процесс не гарантирует выявления проблемы, если причиной проблемы является взаимодействие между двумя конкретными компонентами.

  • Проверьте эффективную конфигурацию
  • Убедитесь, что узел прослушивает соединения TLS.
  • Проверьте права доступа к файлам
  • Проверьте поддержку TLS в Erlang/OTP
  • Проверьте пары сертификат/ключ и протестируйте альтернативный клиент или сервер TLS с помощью инструментов командной строки OpenSSL
  • Проверьте доступные и настроенные комплекты шифров и параметры использования ключа сертификата.
  • Проверка клиентских подключений с помощью завершающего TLS прокси-сервера
  • И, наконец, еще раз протестируйте реальное подключение клиента к реальному подключению к серверу.

При тестировании с узлом RabbitMQ и/или реальным клиентом RabbitMQ важно проверять журналы как для сервера, так и для клиента.

Проверить действующую конфигурацию узла

Настройка узла RabbitMQ с TLS требует изменения конфигурации. Перед выполнением любых других шагов по устранению неполадок TLS важно проверить расположение файла конфигурации и эффективную конфигурацию (успешно ли загрузил его узел). Подробнее см. в руководстве по настройке.

Проверить прослушиватели TLS (порты)

На этом шаге проверяется, что брокер прослушивает ожидаемые порты, например 5671 для AMQP 0-9-1 и 1.0, 8883 для MQTT и т. д.

Чтобы убедиться, что TLS включен на узле, используйте прослушиватели rabbitmq-diagnostics или раздел listeners в статусе rabbitmq-diagnostics.

Секция слушателей будет выглядеть примерно так:

В приведенном выше примере на узле имеется 6 прослушивателей TCP. Два из них принимают соединения с поддержкой TLS:

Если описанные выше шаги не подходят, проверка файла журнала узла может стать жизнеспособной альтернативой. Он должен содержать запись о включенном прослушивателе TLS, выглядящую следующим образом:

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

Такие инструменты, как lsof и netstat, можно использовать для проверки того, какие порты прослушивает узел, как описано в руководстве по устранению неполадок в сети.

Проверить права доступа к сертификату, закрытому ключу и пакету CA

RabbitMQ должен иметь возможность считывать настроенный пакет сертификатов ЦС, сертификат сервера и закрытый ключ. Файлы должны существовать и иметь соответствующие разрешения. Неправильные разрешения (например, файлы, принадлежащие пользователю root или другой учетной записи суперпользователя, которая их установила) — очень распространенная проблема при настройке TLS.

В Linux, BSD и MacOS права доступа к каталогам также могут влиять на способность узла читать файлы.

Если файлы сертификата или закрытого ключа недоступны для чтения или не существуют, узел не сможет принимать соединения с поддержкой TLS или соединения TLS просто зависнут (поведение отличается в разных версиях Erlang/OTP).

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

Проверьте поддержку TLS в Erlang

Еще одним ключевым требованием для установления соединений TLS с брокером является поддержка TLS в брокере. Убедитесь, что виртуальная машина Erlang поддерживает TLS, запустив

Вывод будет выглядеть следующим образом:

Для версий, которые не предоставляют tls_versions для диагностики rabbitmq, используйте

Вывод в этом случае будет выглядеть так:

Если вместо этого появляется сообщение об ошибке, убедитесь, что установка Erlang/OTP включает поддержку TLS.

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

Также можно проверить, какие версии TLS поддерживаются локальной средой выполнения Erlang. Для этого запустите erl (или werl.exe в Windows) в командной строке, чтобы открыть оболочку Erlang, и введите

Обратите внимание, что это сообщит о поддерживаемых версиях на локальном узле (для среды выполнения, найденной в PATH ), которые могут отличаться от используемых проверяемыми узлами RabbitMQ.

Использование инструментов OpenSSL для тестирования соединений TLS

OpenSSL s_client и s_server — это широко используемые инструменты командной строки, которые можно использовать для проверки соединений TLS и пар сертификат/ключ. Они помогают сузить круг проблем путем тестирования альтернативных реализаций клиента и сервера TLS. Например, если определенный клиент TLS успешно работает с s_server, но не с узлом RabbitMQ, основная причина, скорее всего, находится на стороне сервера. Аналогичным образом, если клиент s_client может успешно подключиться к узлу RabbitMQ, а другой клиент не может, в первую очередь следует тщательно проверить настройку клиента.

В приведенном ниже примере делается попытка подтвердить, что сертификаты и ключи можно использовать для установления соединения TLS путем подключения клиента s_client к серверу s_server в двух отдельных оболочках (окнах терминала).

В примере предполагается, что у вас есть следующие файлы сертификатов и ключей (эти имена файлов используются tls-gen):

< td>Закрытый ключ клиента
Элемент Расположение
Сертификат ЦС (открытый ключ) ca_certificate. pem
Сертификат сервера (открытый ключ) server_certificate.pem
Закрытый ключ сервера server_key.pem
Сертификат клиента (открытый ключ) client_certificate.pem
client_key.pem

В одном окне или вкладке терминала выполните следующую команду:

Он запустит OpenSSL s_server, который использует предоставленный пакет сертификатов ЦС, сертификат сервера и закрытый ключ. Он будет использоваться для проверки работоспособности сертификатов с тестовыми подключениями TLS к этому серверу-примеру.

В другом окне терминала выполните следующую команду, заменив CN_NAME на ожидаемое имя хоста или имя CN из сертификата:

Откроется новое подключение TLS к серверу TLS из примера, запущенному выше. Вы можете не указывать аргумент -verify_hostname, но OpenSSL больше не будет выполнять эту проверку.

Если сертификаты и ключи созданы правильно, выходные данные подключения TLS появятся на обеих вкладках. Теперь между клиентом из примера и сервером из примера установлено соединение, похожее на telnet .

Если цепочка доверия может быть установлена, второй терминал отобразит подтверждение проверки с кодом 0:

Как и в случае с инструментами командной строки, ненулевой код указывает на какую-то ошибку.

Если сообщается об ошибке, убедитесь, что сертификаты и ключи созданы правильно и что используется соответствующая пара сертификат/закрытый ключ. Кроме того, сценарии использования сертификатов могут быть ограничены во время генерации. Это означает, что сертификат, предназначенный для использования клиентами для аутентификации, будет отклонен сервером, например узлом RabbitMQ.

Для сред, где подходят самозаверяющие сертификаты, мы рекомендуем использовать tls-gen для генерации.

Проверить доступные наборы шифров

Узлы и клиенты RabbitMQ могут быть ограничены наборами шифров, которые им разрешено использовать во время рукопожатия TLS. Важно убедиться, что у обеих сторон есть общие наборы шифров, иначе рукопожатие не удастся.

Свойства использования ключа сертификата также могут ограничивать наборы шифров, которые можно использовать.

Дополнительные сведения см. в разделе Настройка комплектов шифров и расширений использования открытых ключей в основном руководстве по TLS.

отобразятся все наборы шифров, поддерживаемые локальной сборкой OpenSSL.

Попытка подключения TLS к узлу RabbitMQ

После того как узел RabbitMQ настроен на прослушивание порта TLS, s_client OpenSSL можно использовать для проверки установления соединения TLS, на этот раз с узлом. Эта проверка устанавливает, вероятно ли, что брокер настроен правильно, без необходимости настройки клиента RabbitMQ. Инструмент также может быть полезен для сравнения поведения разных клиентов. В примере предполагается, что узел работает на локальном хосте с портом TLS по умолчанию для AMQP 0-9-1 и AMQP 1.0, 5671:

Вывод должен выглядеть так же, как и в случае использования порта 8443. Файл журнала узла должен содержать новую запись при установлении соединения:

Узел будет ожидать, что клиенты выполнят подтверждение протокола (AMQP 0-9-1, AMQP 1.0 и т. д.). Если этого не произойдет в течение короткого промежутка времени (10 секунд по умолчанию для большинства протоколов), узел закроет соединение.

Проверка клиентских подключений с помощью Stunnel

stunnel – это инструмент, который можно использовать для проверки клиентов с поддержкой TLS. В этой конфигурации клиенты будут устанавливать безопасное соединение со stunnel, который будет передавать расшифрованные данные через «обычный» порт брокера (скажем, 5672 для AMQP 0-9-1 и AMQP 1.0). Это обеспечивает некоторую уверенность в правильности конфигурации TLS клиента независимо от конфигурации TLS брокера.

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

В этом примере stunnel подключится к незашифрованному порту брокера (5672) и примет подключения TLS от клиентов с поддержкой TLS через порт 5679.

Параметры передаются через файл конфигурации с именем stunnel.conf . Он имеет следующее содержание:

stunnel запускается следующим образом:

stunnel требует сертификат и соответствующий закрытый ключ. Файлы сертификата и закрытого ключа должны быть объединены, как показано выше, с помощью команды cat. stunnel требует, чтобы ключ не был защищен паролем. Клиенты с поддержкой TLS теперь должны иметь возможность подключаться к порту 5679, и любые ошибки TLS будут отображаться на консоли, где был запущен stunnel.

Подтвердить подключение клиента RabbitMQ к узлу RabbitMQ

Предполагая, что ни один из предыдущих шагов не привел к ошибкам, вы можете уверенно подключить проверенный клиент с поддержкой TLS к порту брокера с поддержкой TLS, предварительно остановив все работающие экземпляры OpenSSL s_server или stunnel.

Цепочки сертификатов и глубина проверки

При использовании сертификата клиента, подписанного промежуточным ЦС, может потребоваться настроить сервер RabbitMQ для использования более высокой глубины проверки.

Недостаточная глубина проверки приведет к сбоям проверки узла TLS.

Общие сведения об ошибках журнала подключений TLS

Новые записи в файле журнала брокера будут созданы во время многих предыдущих шагов. Эти записи вместе с диагностическими выводами команд на консоли должны помочь определить причину ошибок, связанных с TLS. Далее следует список наиболее распространенных ошибок:

Получение помощи и предоставление отзывов

Если у вас есть вопросы по содержанию этого руководства или любой другой теме, связанной с RabbitMQ, не стесняйтесь задавать их в списке рассылки RabbitMQ.

Помогите нам улучшить Документы

Если вы хотите внести свой вклад в улучшение сайта, его исходный код доступен на GitHub. Просто разветвите репозиторий и отправьте запрос на включение. Спасибо!

Я пытаюсь настроить SMTP-сервер с TLS/SSL, в обоих случаях тестовая электронная почта завершается ошибкой:

Конфигурация SMTP без SSL работает нормально, и тестовая электронная почта получена.

И при использовании SSL, и при использовании TLS соединение не устанавливается. Я импортировал подписанный сертификат Yellowfin в cacerts SMTP-сервера и аналогично сертификат SMTP-сервера в хранилище ключей yellowfin.

Сертификаты действительны, и мы используем последнюю сборку chrome(85)/firefox(81).

Команда безопасности подтвердила отсутствие проблем с антивирусом или другими проблемами со связью.

У меня есть снимок экрана и журнал электронной почты.

Подтвердите, поддерживает ли YF конфигурацию электронной почты TLSSTART, у нас версия 8.0.6.

Комментарии ( 17 )

Спасибо, что обратились к нам. Я буду тестировать на 8.0.6, но я мог использовать это в прошлом. К какому почтовому серверу вы подключаетесь? Существуют ли какие-либо ограничения на используемые версии TLS?

Мы используем SMTP-сервер для Outlook, и для версии TLS нет ограничений. Пожалуйста, проверьте и дайте нам знать, если это работает для вас.

В настоящее время у меня нет доступа к серверу Outlook, но я смог успешно использовать SMTP Google с STARTTLS (порт 587). Я прикрепил изображения различий между без шифрования и STARTTLS, чтобы вы могли убедиться, что он работает.

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

Если у вас есть какие-либо вопросы, дайте мне знать.

Спасибо за попытку. Хорошо, я понимаю, что это выходит за рамки вашей поддержки.

Можете ли вы помочь мне понять, нужно ли нам импортировать сертификаты как в хранилище доверенных сертификатов Java сервера Yellowfin, так и на SMTP-сервере?

Как вам показался TLS? Вы импортировали какие-либо сертификаты на сервер YF? Таким образом, мы также можем следовать тому же принципу.

Я не импортировал никаких сертификатов, но поскольку это сервер Google, их сертификат уже будет доверенным. TLS требует только, чтобы SMTP-сервер имел действующий сертификат и был доверенным, поэтому я ожидаю, что CA SMTP-сервера должен быть доверенным java на сервере Yellowfin.

Если это самозаверяющий сертификат на SMTP-сервере, вам необходимо добавить этот сертификат в доверенную базу данных java на сервере Yellowfin.

Один из способов проверить, работает ли TLS и что проблема связана только с доверительными отношениями, — включить параметр «Разрешить недействительный сертификат», который должен игнорировать действительность сертификата и разрешать отправку почты. Я бы не рекомендовал использовать это как постоянную настройку (хотя это возможно), но это, по крайней мере, подтвердило бы основную причину проблемы.

Я отмечу это как выполненное, но, пожалуйста, дайте мне знать, как вы продвигаетесь, и если у вас есть дополнительные вопросы.

Мы изо всех сил пытаемся заставить эту конфигурацию работать. Мы импортировали подписанный сертификат SMTP-серверов в хранилище доверенных сертификатов Yellowfin Java. Мы также включили TLS 1, 1.2 в файле tomcat server.xml. Мы по-прежнему получаем ту же ошибку.

Разрешить недопустимый сертификат также приводит к той же ошибке.

В вашем последнем обновлении, которое вы упомянули, TLS требует только, чтобы SMTP-сервер имел действующий сертификат и был доверенным — SMTP-сервер имеет действующий сертификат и является доверенным. Сегодня это подтвердили администраторы SMTP.

Мы также включили ведение журнала на стороне SMTP и обнаружили ошибку в нашей конфигурации электронной почты:

Не удалось согласовать TLS из-за несоответствия алгоритма

Нам нужно знать, можем ли мы позволить желтоперому использовать определенную версию TLS? Я знаю, что мы определяем TLS в файле tomcat server.xml, но есть ли в yellowfin место, где мы можем использовать TLS 1.x для настройки электронной почты?

Требуется ли сертификат Yellowfin для импорта на SMTP-сервер?

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

Сообщения об ошибках

Вы также можете увидеть это сообщение об ошибке при сбое рукопожатия TLS/SSL:

Возможные причины

TLS (Transport Layer Security, предшественником которого является SSL) – это стандартная технология безопасности для установления зашифрованного соединения между веб-сервером и веб-клиентом, например браузером или приложением. рукопожатие — это процесс, который позволяет клиенту и серверу TLS/SSL установить набор секретных ключей, с помощью которых они могут обмениваться данными. Во время этого процесса клиент и сервер:

  1. Согласитесь с используемой версией протокола.
  2. Выберите используемый криптографический алгоритм.
  3. Аутентифицируйте друг друга, обмениваясь и проверяя цифровые сертификаты.

Если рукопожатие TLS/SSL прошло успешно, клиент и сервер TLS/SSL безопасно передают данные друг другу. В противном случае, если происходит сбой рукопожатия TLS/SSL, соединение прерывается, и клиент получает ошибку 503 Service Unreachable.

Причина Описание Кто может выполнить действия по устранению неполадок
Несоответствие протокола Протокол, используемый клиентом, не поддерживается сервером. Пользователи частного и общедоступного облака
Шифрование Несоответствие наборов Набор шифров, используемый клиентом, не поддерживается сервером. Пользователи частного и общедоступного облака
Неверный сертификат Имя хоста в URL-адресе, используемом клиентом, не соответствует имени хоста в сертификате, хранящемся на стороне сервера. Пользователи частного и общедоступного облака
Неполная или недействительная цепочка сертификатов хранится на стороне клиента или сервера. Пользователи частного и общедоступного облака
Клиент отправляет неверный или просроченный сертификат на сервер или с сервера клиенту. Пользователи частного и общедоступного облака
Сервер с поддержкой SNI Внутренний сервер rver включена индикация имени сервера (SNI); однако клиент не может взаимодействовать с серверами SNI. Только для пользователей частного облака

Несоответствие протокола

Сбой рукопожатия TLS/SSL происходит, если протокол, используемый клиентом, не поддерживается сервером ни для входящего (северного), ни для исходящего (южного) подключения. См. также Общие сведения о соединениях в северном и южном направлениях.

Диагностика

Если вы выберете сообщение Client Hello, оно покажет, что обработчик сообщений использует протокол TLSv1.2, как показано ниже:

Разрешение

Процессор сообщений работает на Java 8 и по умолчанию использует протокол TLSv1.2. Если внутренний сервер не поддерживает протокол TLSv1.2, для решения этой проблемы можно выполнить одно из следующих действий:

  1. Обновите внутренний сервер для поддержки протокола TLSv1.2. Это рекомендуемое решение, поскольку протокол TLSv1.2 более безопасен.
  2. Если по какой-либо причине вы не можете немедленно обновить внутренний сервер, вы можете заставить обработчик сообщений использовать протокол TLSv1.0 для связи с внутренним сервером, выполнив следующие действия:
    1. Если вы не указали целевой сервер в определении TargetEndpoint прокси-сервера, задайте для элемента Protocol значение TLSv1.0, как показано ниже:
    2. Если вы настроили целевой сервер для своего прокси-сервера, используйте этот API управления, чтобы установить протокол TLSv1.0 в конкретной конфигурации целевого сервера.

    Несоответствие шифров

    Вы можете увидеть сбой рукопожатия TLS/SSL, если алгоритм набора шифров, используемый клиентом, не поддерживается сервером ни при входящем (северном), ни при исходящем (южном) соединении в Apigee Edge. См. также Общие сведения о соединениях в северном и южном направлениях.

    Диагностика

    1. Определите, возникла ли ошибка при подключении к северу или югу. Дополнительные рекомендации по определению источника проблемы см. в разделе Определение источника проблемы.
    2. Запустите утилиту tcpdump, чтобы собрать дополнительную информацию:
      • Если вы являетесь пользователем частного облака, вы можете собирать данные tcpdump на соответствующем клиенте или сервере. Клиентом может быть клиентское приложение (для входящих или северных подключений) или обработчик сообщений (для исходящих или южных подключений). Сервер может быть пограничным маршрутизатором (для входящих или северных подключений) или внутренним сервером (для исходящих или южных подключений) в зависимости от вашего решения на шаге 1.
      • Если вы являетесь пользователем общедоступного облака, вы можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на внутреннем сервере (для исходящих или южных подключений), поскольку у вас нет доступа к пограничному маршрутизатору или обработчику сообщений.
      См. данные tcpdump для получения дополнительной информации об использовании команды tcpdump.
    3. Проанализируйте данные tcpdump с помощью инструмента Wireshark или любого другого инструмента, с которым вы знакомы.
    4. Вот пример анализа вывода tcpdump с помощью Wireshark:
      • В этом примере произошел сбой рукопожатия TLS/SSL между клиентским приложением и пограничным маршрутизатором (северное подключение). Выходные данные tcpdump были собраны на маршрутизаторе Edge.

    Выбор сообщения Client Hello показывает, что клиентское приложение использует протокол TLSv1.2.

      Пограничный маршрутизатор поддерживает протокол TLSv1.2. Это означает, что протокол совпадает между клиентским приложением и пограничным маршрутизатором.

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

    • Клиентское приложение не использует алгоритмы набора шифров, поддерживаемые пограничным маршрутизатором.
    • Пограничный маршрутизатор поддерживает SNI, но клиентское приложение не отправляет имя сервера.

    Разрешение

    Вы должны убедиться, что клиент использует алгоритмы наборов шифров, поддерживаемые сервером. Чтобы решить проблему, описанную в предыдущем разделе «Диагностика», загрузите и установите пакет Java Cryptography Extension (JCE) и включите его в установку Java для поддержки алгоритмов набора шифров High Encryption.

    Неверный сертификат

    Сбой рукопожатия TLS/SSL возникает, если у вас есть неверные сертификаты в хранилище ключей/доверенном хранилище либо на входящем (северном), либо на исходящем (южном) соединении в Apigee Edge. См. также Общие сведения о соединениях в северном и южном направлениях.

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

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

    Сообщения об ошибках

    Вы можете увидеть разные сообщения об ошибках в зависимости от причины сбоя рукопожатия TLS/SSL. Вот пример сообщения об ошибке, которое вы можете увидеть при вызове прокси-сервера API:

    Возможные причины

    Несоответствие имени хоста

    Диагностика

    Если вы являетесь пользователем частного облака:
    Если вы являетесь пользователем общедоступного облака:

    Разрешение

    Эту проблему можно решить одним из следующих двух способов:

    • Получите сертификат (если у вас его еще нет), где CN субъекта имеет групповой сертификат, а затем загрузите новую полную цепочку сертификатов в хранилище ключей. Например:
    • Получите сертификат (если у вас его еще нет) с существующим CN субъекта, но используйте your-org . your-domain в качестве альтернативного имени субъекта, а затем загрузите полную цепочку сертификатов в хранилище ключей.

    Ссылки

    Неполная или неправильная цепочка сертификатов

    Диагностика

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

    Разрешение

    1. Получите сертификат (если у вас его еще нет), включающий полную и действительную цепочку сертификатов.
    2. Выполните следующую команду openssl, чтобы убедиться в правильности и полноте цепочки сертификатов:
    3. Загрузить проверенную цепочку сертификатов в хранилище ключей.

    Просроченный или неизвестный сертификат, отправленный сервером или клиентом

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

    Диагностика

    1. Определите, возникла ли ошибка при подключении к северу или югу. Дополнительные рекомендации по определению источника проблемы см. в разделе Определение источника проблемы.
    2. Запустите утилиту tcpdump, чтобы собрать дополнительную информацию:
      • Если вы являетесь пользователем частного облака, вы можете собирать данные tcpdump на соответствующем клиенте или сервере. Клиентом может быть клиентское приложение (для входящих или северных подключений) или обработчик сообщений (для исходящих или южных подключений). Сервер может быть пограничным маршрутизатором (для входящих или северных подключений) или внутренним сервером (для исходящих или южных подключений) в зависимости от вашего решения на шаге 1.
      • Если вы являетесь пользователем общедоступного облака, вы можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на внутреннем сервере (для исходящих или южных подключений), поскольку у вас нет доступа к пограничному маршрутизатору или обработчику сообщений.
      См. данные tcpdump для получения дополнительной информации об использовании команды tcpdump.
    3. Проанализируйте данные tcpdump с помощью Wireshark или аналогичного инструмента.
    4. Из выходных данных tcpdump определите узел (клиент или сервер), который отклоняет сертификат на этапе проверки.
    5. Вы можете получить сертификат, отправленный с другого конца, из вывода tcpdump, если данные не зашифрованы. Это будет полезно для сравнения, совпадает ли этот сертификат с сертификатом, доступным в хранилище доверенных сертификатов.
    6. Просмотрите образец tcpdump для связи SSL между обработчиком сообщений и внутренним сервером.

    Пример tcpdump, показывающий неизвестную ошибку сертификата

    Предупреждение (уровень: неустранимый, описание: срок действия сертификата истек)

    Разрешение

    Чтобы устранить проблему, указанную в приведенном выше примере, загрузите действительный сертификат внутреннего сервера в хранилище доверенных сертификатов обработчика сообщений.

    В следующей таблице приведены действия по устранению проблемы в зависимости от ее причины.

    • Срок действия сертификата, хранящегося в хранилище ключей маршрутизатора, истек.
    • Срок действия сертификата, хранящегося в хранилище ключей клиентского приложения, истек (двусторонний SSL).
    • Срок действия сертификата, хранящегося в хранилище ключей целевого сервера, истек.
    • Срок действия сертификата, хранящегося в хранилище ключей обработчика сообщений, истек (двусторонний SSL).
    • Сертификат, хранящийся в хранилище доверенных сертификатов клиентского приложения, не соответствует сертификату маршрутизатора.
    • Сертификат, хранящийся в хранилище доверенных сертификатов маршрутизатора, не соответствует сертификату клиентского приложения (двусторонний SSL).
    • Сертификат, хранящийся в хранилище доверенных сертификатов целевого сервера, не соответствует сертификату обработчика сообщений.
    • Сертификат, хранящийся в хранилище доверенных сертификатов обработчика сообщений, не соответствует сертификату целевого сервера (двусторонний SSL).

    Сервер с поддержкой SNI

    Сбой рукопожатия TLS/SSL может произойти, когда клиент обменивается данными с сервером с включенной индикацией имени сервера (SNI), но на клиенте не включен SNI. Это может произойти либо на северном, либо на южном соединении в Edge.

    Во-первых, необходимо определить имя хоста и номер порта используемого сервера, а также проверить, включен ли на нем SNI или нет.

    Идентификация сервера с поддержкой SNI

    После того, как вы определили, что на сервере включен SNI, вы можете выполнить следующие действия, чтобы проверить, не вызван ли сбой подтверждения TLS/SSL тем, что клиент не может связаться с сервером SNI.

    Диагностика

    • Внутренний сервер поддерживает протокол TLSv1.2. Это означает, что протокол обработчика сообщений и внутреннего сервера совпадает.
    • Однако внутренний сервер по-прежнему отправляет обработчику сообщений фатальное предупреждение: сбой рукопожатия, как показано на рисунке ниже:

    • Обработчик сообщений не использует алгоритмы набора шифров, поддерживаемые внутренним сервером.
    • На внутреннем сервере включен SNI, но клиентское приложение не отправляет имя сервера.

    Разрешение

    Включите обработчики сообщений для связи с серверами с поддержкой SNI, выполнив следующие действия:

    Если вы не можете определить причину сбоя рукопожатия TLS/SSL и устранить проблему или вам нужна дополнительная помощь, обратитесь в службу поддержки Apigee. Поделитесь полной информацией о проблеме вместе с выводом tcpdump.

    Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

    Читайте также: