Сертификаты с другой sql версии серверов

Question

У меня есть сервисный брокер, настроенный в двух разных базах данных на двух разных серверах. Проблема в том, что я не могу получить сообщение, потому что у меня проблема:
Connection handshake failed. The login 'public' does not have CONNECT permission on the endpoint. State 84. У меня есть конечные точки с сертификатами, я дал разрешение на подключение к указанному c пользователю, у которого есть сертификат (я делал это на двух серверов, потому что это всегда в группе доступности ), при поиске проблемы я заметил, что сертификат с сервера-инициатора отличается от сертификата с целевого сервера:
-initiator - алгоритм подписи: sha1RSA , длина ключа: 1024 (sql вер. 11.0.7 ...)
-target - алгоритм подписи: sha256RSA, длина ключа: 2048 (sql вер. 15.0.4 ...)

Когда я даю разрешение:
grant connect on endpoint :: BrokerEndPoint to PUBLIC
Серверы обмениваются данными, но это не решает проблему. Могут ли быть проблемой разные типы сертификатов?

Answer 1

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

Answer 2

grant connect on endpoint :: BrokerEndPoint to PUBLIC

Выполнение этого в основном обходит авторизацию, так как каждый имеет право подключаться. Я думаю, вам следует попытаться исправить разрешение пользователя / ролей.

Я заметил, что сертификат с сервера-инициатора отличается от сертификата с целевого сервера:

Это не должно иметь никакого значения.

Похоже, проблема в том, что вы неправильно сконфигурировали цепочку users / login / certs. Это настолько чертовски сложно, что его легко сломать ... Вот сокращенное изображение правильной настройки:

• Существует два уровня безопасности: безопасность разговора (между службами в базах данных) и безопасность транспорта (между конечные точки в экземплярах). Теперь вы говорите о безопасности транспорта (от конечной точки к конечной).
• Безопасность конечной точки всегда находится между задействованными экземплярами SQL. Если у вас есть группы доступности, каждый узел необходимо настроить отдельно, поскольку конечные точки являются концепциями уровня экземпляра и не поддерживают отработку отказа группы доступа.
• Конечная точка будет использовать настроенный сертификат (CREATE ENDPOINT ... FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE <certname>)). Сертификат должен иметь доступный закрытый ключ, чтобы его можно было использовать (ie зашифрован ключом, который может быть открыт из главного ключа службы, обычно с помощью главного ключа базы данных master).
• Во время рукопожатия аутентификация и авторизация взаимны. Скажите экземплярам, ​​что S1 и S2 должны подключиться, тогда:
• S1 будет использовать сертификат C1, S2 использует сертификат C2
• S1 должен иметь C2 (только publi c ключ) в своем master база данных, и S2 должен иметь C1 (только для publi c key) в своем master.
• Сертификат C2 в S1 master принадлежит пользователю базы данных (участнику базы данных) скажем, это US2. У этого пользователя есть логин (участник сервера, скажем, UL2). UL2 для входа в систему должен иметь разрешение CONNECT на конечной точке S1.
• И наоборот: сертификат C1 в S2 master принадлежит пользователю (US1), имеющему имя входа (UL1). Этому логину UL1 необходимо предоставить разрешение CONNECT на конечной точке S2.

Для устранения неполадок включите событие «Audit Broker Login» в профилях (в группе аудита безопасности). Это событие будет запускаться с подробностями о том, почему не удается установить связь, когда оно не удается.