У нас есть домен 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). Мы также проверили это, сравнив серийные номера
В ходе исследования, поскольку у нас есть контроллеры домена, которые имеют несколько сертификатов в хранилище локального компьютера \ личного сертификата, мы наткнулись на следующую статью:
Он предлагает поместить сертификат с локального компьютера \ хранилища личных сертификатов в хранилище доменных служб Active Directory \ Personal. Мы выполнили описанные шаги, но получили те же результаты.
После дальнейшего исследования было предложено использовать инструмент под названием ldp или adsiedit. Затем мы приступили к использованию этих инструментов и подделали файл хоста локального компьютера, с которого мы выполняли тест, чтобы указать домен (test.corp) на IP-адрес одного из DC, который вызывает у нас проблемы. После перезапуска, чтобы очистить кеш, мы протестировали инструменты «ldp» и «adsiedit» для подключения к test.corp. Эти системы не сообщали об ошибках.
Мы обнаружили это странным, затем мы запустили команду openssl, чтобы увидеть, какой сертификат она обслуживает из той же системы, и мы обнаружили, что она все еще обслуживает неправильный сертификат.
При дальнейшем исследовании выяснилось, что «ldp» при установке флажка SSL и инструменты «adsiedit» не соответствовали RFC6125, в частности B.3.
, который в основном гласит, что идентификатор сертификата должен совпадать с идентификатором запроса, иначе рукопожатие не удастся. Эта проверка личности выполняется с использованием общего имени сертификата (CN) или SAN.
Исходя из этого, инструменты «ldp» и «adsiedit» не соответствуют стандарту RFC6125.
Чтобы сказать все это, нам нужно сначала исправить несколько контроллеров домена, которые обслуживают правильный сертификат. Мы открыты для предложений, поскольку работаем над этой проблемой последние несколько месяцев. Во-вторых, есть ли способ заставить соответствующие инструменты MS работать в соответствии со стандартом RFC6125?
Примечание. Если я разместил это на неправильной доске (например, переполнение стека), сообщите мне, и я удалю и повторно разместлю сообщение в правильном месте.
RFC6125 специально заявляет, что он не заменяет существующие RFC. Обработка сертификатов LDAP определена в RFC4513. Помимо этого, RFC6125 имеет существенные недостатки. Смотрите также https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26