LDAPS Несколько сертификатов Microsoft Active Directory RFC6125

У нас есть домен Microsoft Active Directory с большим пулом контроллеров домена (DC), настроенных с помощью LDAP. Все они настраиваются с помощью LDAPS и используют службы сертификации через шаблон для настройки сертификата с доменным именем (например, test.corp) в альтернативном имени субъекта (SAN) для обслуживания сервера LDAPS.

Так как это контроллеры домена, DNS настраивается в пуле для каждой из этих систем, чтобы отвечать на запросы к test.corp циклически.

Каждый из этих контроллеров домена имеет несколько шаблонов и несколько сертификатов в локальном компьютере \ хранилище личных сертификатов.

После тестирования с использованием модуля nodejs, ldapjs при выполнении запроса LDAPS с использованием доменного имени, test.corp мы замечаем, что несколько серверов выходят из строя со следующим сообщением:

Ошибка [ERR_TLS_CERT_ALTNAME_INVALID]: Имя хоста / IP не совпадает альтернативные имена сертификатов: Хост: test.corp. не в сертификате altnames: othername :, DNS: .test.corp

В ходе исследования мы обнаружили, что эти несколько серверов LDAPS обслуживают неправильный сертификат. Мы определили это с помощью следующей команды

openssl s_client -connect .test.corp: 636

Если вы возьмете раздел сертификата вывода, поместите его в файл и воспользуетесь таким инструментом, как диспетчер сертификатов или certutil чтобы прочитать файл, вы увидите, что сертификат не тот. (У него нет домена "test.corp" SAN). Мы также проверили это, сравнив серийные номера

. В ходе исследования, поскольку у нас есть контроллеры домена с несколькими сертификатами в хранилище локального компьютера \ Personal Certificate, мы наткнулись на следующую статью:

https: //social.technet .microsoft.com / wiki / contents / article / 2980.ldap-over-ssl-ldaps-certificate.aspx

Предлагается поместить сертификат с локального компьютера \ хранилища личных сертификатов в хранилище доменных служб Active Directory \ Personal. Мы выполнили описанные шаги, но получили те же результаты.

После дальнейшего расследования было предложено использовать инструмент под названием ldp или adsiedit. Затем мы приступили к использованию этих инструментов и подделали файл хоста локального компьютера, с которого мы выполняли тест, чтобы указать домен (test.corp) на IP-адрес одного из DC, который доставляет нам проблемы. После перезапуска, чтобы очистить кеш, мы протестировали инструменты «ldp» и «adsiedit» для подключения к test.корп. Эти системы не сообщали об ошибках.

Мы нашли это странным, затем запустили команду openssl, чтобы посмотреть, какой сертификат она обслуживает из той же системы, и обнаружили, что она все еще обслуживает неправильный сертификат.

При дальнейшем исследовании выяснилось, что «ldp» при установке флажка SSL и инструменты «adsiedit» не соответствовали RFC6125, в частности B.3

https://tools.ietf.org/html/rfc6125 # appendix-B.3

, в котором в основном говорится, что идентификатор сертификата должен совпадать с идентификатором запроса, в противном случае рукопожатие не удастся. Эта проверка личности выполняется с использованием общего имени сертификата (CN) или SAN.

Судя по этому, инструменты «ldp» и «adsiedit» не соответствуют стандарту RFC6125.

Чтобы сказать все это, нам нужно сначала исправить несколько контроллеров домена, которые обслуживают правильный сертификат. Мы открыты для предложений, так как работаем над этой проблемой последние несколько месяцев. Во-вторых, есть ли способ заставить соответствующие инструменты MS работать в соответствии со стандартом RFC6125?

Примечание: если я разместил это на неправильной плате (например, переполнение стека), сообщите мне, и я удалю и перепубликую в правильное место.