Здравствуйте, tls не заполнил биту
Обновлено: 21.11.2024
В этом руководстве описываются методология и некоторые инструменты, помогающие диагностировать проблемы и ошибки подключения 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):
| Элемент | Расположение |
| Сертификат ЦС (открытый ключ) | 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. Просто разветвите репозиторий и отправьте запрос на включение. Спасибо!
Читайте также: