Подтвердить что ты не робот

"Сертификат X.509 CN = servicebus.windows.net" Очередь шины обслуживания Azure

Мы используем Azure Service Bus и Azure Web App, которые заполняют очередь. Они находятся в одной группе ресурсов. Мы используем WindowsAzure.ServiceBus v2.6.5.

Мы получаем эту ошибку очень редко:

Сертификат X.509 CN = servicebus.windows.net не находится в хранилище доверенных лиц. Не удалось получить сертификат X.509 CN = servicebus.windows.net. В используемом сертификате есть цепочка доверия, которая не может быть проверена. Замените сертификат или измените certificateValidationMode. Цепочка сертификатов не может быть создана для доверенного корневого центра.

Вопрос: Является ли эта внутренняя ошибка Azure? Если это не так, что мы можем сделать, чтобы не получить эту ошибку?

4b9b3361

ОТВЕТЫ

Ответ 1

Мне удалось найти дополнительную информацию об этой проблеме. Прежде всего, необходимо установить, что это чистая проблема с клиентом, это поэтому нет идентификаторов отслеживания. Клиент отказывается завершить TLS с Service Bus.

Это известная проблема. Это известная проблема с тем, как Microsoft управляет сертификатами и как они используются на транспорте, отличном от HTTP (S). Ошибки возникают, когда конечная точка, на которой размещается промежуточная сертификаты для Microsoft недоступны или медленны или не могут быть достигнуты по какой-либо причине. Мы изучаем временное решение для ввод необходимого дополнительного сертификата в рукопожатие TLS для SBMP и AMQP переносят аналогично тому, как это делается HTTP.SYS, так что этот дополнительный запрос не нужен.

Возможным обходным путем является включение ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.HttpsЭто заставит весь трафик использовать туннель WebSockets, который защищенный предыдущим рукопожатием TLS/HTTPS, и это рукопожатие требуемый промежуточный сертификат. Рукопожатие WebSockets наложить немного дополнительной задержки, поскольку соединение установлено, но в противном случае будет сопоставима с обычным режимом связи. протокол обмена сообщениями, используемый через этот туннель, по-прежнему будет AMQP или NetMessaging, поэтому вы не должны беспокоиться о том, чтобы получить характеристики HTTP при выборе этой опции.

Это ответ Microsoft. Я применил бы это, и если я не буду сталкиваться с какой-либо проблемой в некоторый период времени, я буду принимать это как ответ. Кто сталкивается с этой проблемой, они могут попробовать это также.

Edit:

ConnectivityMode.Https находится только в доступной сервисной шине 3. Мне нужно использовать servicebus 2 из-за issue в Signalr. Поэтому я не мог применить это решение.