TLS моста Mosquitto: разделить доверие серверу и удостоверение самого моста
Фотография конкретного исполнения не приложена.
Bridge_cafile, bridge_capath либо предусмотренное доверие сертификатам ОС задают основу проверки удалённого брокера. Bridge_certfile и bridge_keyfile относятся к клиентскому сертификату моста, если его требует другая сторона. Успешная загрузка клиентского ключа не подтверждает, что удалённый сервер проверяется по нужному центру доверия.
Для каталога bridge_capath руководство требует соответствующие расширения файлов и обновление hash-структуры после добавления либо удаления сертификатов. Простое копирование нового CA в каталог поэтому не является достаточным подтверждением его использования. В процедуре обслуживания фиксируют способ формирования доверия и права службы на чтение нужных файлов.
Проверка имени сопоставляет адрес подключения с именем сертификата сервера. Её отключение через bridge_insecure меняет защиту от подмены; такой обход не должен становиться способом устранения производственной ошибки имени. В проекте согласуют фактическое DNS-имя, сертификат и маршрут подключения, сохраняя предусмотренную проверку.
В приёмке проверяют согласованную цепочку, неправильное имя и отсутствие требуемого клиентского удостоверения. Нужны различимые причины отказа. Сам по себе шифрованный канал или верный MQTT-пароль не доказывают правильность обеих сторон сертификатной аутентификации моста.
Основание — Eclipse Mosquitto official unversioned documentation snapshot; Download index observed 2.1.2, разделы bridge_cafile/capath; bridge_certfile/keyfile; bridge_insecure. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Реальный брокер, его сборка, плагины и сеть не испытывались. Изменения конфигурации, учётных записей и прав не выполнялись; поддержку параметров проверяют по установленной версии.
