Отправка сообщений на служебную шину для Windows Server через AMQP в кластере NLB

Question

При подключении к нашему экземпляру Service Bus с балансировкой нагрузки через AMQP мы не можем отправлять сообщения в очередь или тему.

У нас есть Windows Server 2012 R2, работающий в виртуальной машине на Hyper-V. Сервер является частью кластера NLB (который в настоящее время содержит только этот единственный хост). На сервере мы установили служебную шину для Windows Server 1.1 и настроили ферму, хост и пространство имен, используя следующий сценарий PowerShell:

$machineName = 'server'
$domainName = 'sb.department.company.com' # this DNS name is linked to the virtual IP address of the NLB cluster
$namespace = 'namespace'

New-SBFarm -SBFarmDBConnectionString "Data Source=$machineName;Integrated Security=True" -FarmDns $domainName -EncryptionCertificateThumbprint $certThumbprint -FarmCertificateThumbprint $certThumbprint -RunAsAccount $accountName

Add-SBHost -SBFarmDBConnectionString "Data Source=$machineName;Integrated Security=True" -EnableFirewallRules $true -RunAsPassword $securePassword -ExternalBrokerUrl "sb://$domainName"

New-SBNamespace -Name $namespace -AddressingScheme 'Path' -ManageUsers $userGroupName

Сначала мы попытались сгенерировать сертификаты с помощью makecert, но у этих сертификатов не было свойства Subject Alternative Name. В качестве решения этой проблемы мы использовали OpenSSL для генерации наших сертификатов. Вот цепочка сертификатов, которые мы используем:

• Компания CA
  • Алгоритм подписи: sha256RSA
  • Открытый ключ: RSA (2048 бит)
  • Тема: O = Компания, CN = Компания CA
  • Основные ограничения: тип субъекта = CA, ограничение длины пути = нет
  • Использование ключа: подпись сертификата, автономная подписка CRL, подпись CRL
• Отдел компании CA
  • Алгоритм подписи: sha256RSA
  • Открытый ключ: RSA (2048 бит)
  • Эмитент: Компания CA
  • Тема: O = Компания, CN = Компания CA
  • Основные ограничения: тип субъекта = CA, ограничение длины пути = нет
  • Использование ключа: подпись сертификата, автономная подписка CRL, подпись CRL
• sb.department.company.com
  • Алгоритм подписи: sha256RSA
  • Открытый ключ: RSA (2048 бит)
  • Эмитент: Отдел компании CA
  • Тема: O = Компания, CN = sb.department.company.com
  • Основные ограничения: тип субъекта = конечный объект, ограничение длины пути = нет
  • Использование ключа: цифровая подпись, отказ от авторства, шифрование ключей, шифрование данных
  • Расширенное использование ключа: проверка подлинности сервера
  • Альтернативное имя субъекта: DNS Name = sb.department.company.com

Эти 3 сертификата установлены в хранилище сертификатов локального компьютера (не текущего пользователя):

• Корневой сертификат (компания CA) устанавливается в доверенных корневых центрах сертификации.
• Промежуточный сертификат (отдел компании CA) устанавливается в промежуточных центрах сертификации.
• Сертификат сервера (sb.department.company.com) установлен в доверенных лиц.

Когда мы используем веб-браузер для подключения к https:// sb.department.company.com:9355/namespace, мы видим, что сертификаты верны и надежны.

Когда мы используем библиотеку.NET для подключения к экземпляру служебной шины, мы можем делать все (получить список очередей / тем, создать очереди / тем, отправить сообщения в очередь, ...).

Когда мы подключаемся с помощью AMQP в нашем приложении C++ (в Linux), мы не можем отправлять сообщения в очередь. Это легко продемонстрировать с помощью Service Bus Explorer: если мы установим тип транспорта на AMQP, мы получим это ошибочное поведение. Мы можем получить список очередей и тем, но при попытке отправить сообщения мы получаем следующее сообщение об ошибке: Исключение: удаленный сертификат недействителен в соответствии с процедурой проверки. Метод b__be.

Как мы можем решить это?

Answer 1

После консультации со службой поддержки Microsoft мы смогли решить эту проблему. Вот краткое описание проблемы.

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

Решение состоит в том, чтобы включить доменные имена (или имена компьютеров, если не в домен) всех серверов фермы в свойство Subject Alternative Names сертификата.