При подключении к нашему экземпляру служебной шины с балансировкой нагрузки через 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, но у этих сертификатов не было свойства Альтернативное имя субъекта. В качестве решения этой проблемы мы использовали OpenSSL для создания наших сертификатов. Вот цепочка сертификатов, которые мы используем:
- Company CA
- Signature algorithm: sha256RSA
- Открытый ключ: RSA (2048 бит)
- Тема: O = Компания, CN = Компания CA
- Основные ограничения: Тип субъекта = CA, Ограничение длины пути = Нет
- Использование ключа: Подписание сертификата, Автономная подпись CRL, Подписание CRL
- Company Department CA
- Signature algorithm: sha256RSA
- Открытый ключ: RSA (2048 бит)
- Эмитент: Компания ЦА
- Тема: O = Компания, CN = Компания CA
- Основные ограничения: Тип субъекта = CA, Ограничение длины пути = Нет
- Использование ключа: Подписание сертификата, Автономная подпись CRL, Подписание CRL
- sb.department.company.com
- Signature algorithm: sha256RSA
- Открытый ключ: RSA (2048 бит)
- Эмитент: Департамент компании CA
- Тема: O = Компания, CN = sb.department.company.com
- Основные ограничения: Тип субъекта = Конечная сущность, Ограничение длины пути = Нет
- Использование ключа: цифровая подпись, неотказуемость, шифрование ключа, шифрование данных
- Расширенное использование ключа: аутентификация сервера
- Альтернативное имя субъекта: DNS-имя = sb.department.company.com
Эти 3 сертификата устанавливаются в хранилище сертификатов локального компьютера (не текущего пользователя):
- Корневой сертификат (Company CA) установлен в Доверенные корневые центры сертификации.
- Промежуточный сертификат (ЦС отдела компании) устанавливается в Промежуточные центры сертификации.
- Сертификат сервера (sb.department.company.com) установлен в разделе Доверенные лица.
Когда мы используем веб-браузер для подключения к https:// sb.department.company.com:9355/namespace, мы видим, что сертификаты правильные и доверенные.
Когда мы используем библиотеку .NET для подключения к экземпляру служебной шины, мы можем делать все (получать список очередей/тем, создавать очереди/темы, отправлять сообщения в очередь и т. д.).
Когда мы подключаемся с помощью AMQP в нашем приложении C++ (в Linux), мы не можем отправлять сообщения в очередь. Это можно легко продемонстрировать с помощью Service Bus Explorer: если мы установим тип транспорта на AMQP, мы получим это ошибочное поведение. Мы можем получить список очередей и тем, но при попытке отправить сообщения мы получаем следующее сообщение об ошибке: Исключение: удаленный сертификат недействителен в соответствии с процедурой проверки. Метод b__be.
Как мы можем решить эту проблему?
