У нас есть домен Microsoft Active Directory с большим пулом контроллеров домена (DC), которые настроены с помощью LDAP. Все они настроены с LDAPS и используют службы сертификации через шаблон для настройки сертификата с именем домена (то есть test.corp) в дополнительном имени субъекта (SAN) для сервера LDAPS для обслуживания.
Так как это контроллеры домена, DNS настроен в пул для каждой из этих систем, чтобы отвечать на запросы к test.corp в циклическом режиме.
Каждый из этих контроллеров домена имеет несколько шаблонов и несколько сертификатов в локальном компьютере \ хранилище личных сертификатов.
При тестировании с использованием модуля nodejs, ldapjs при выполнении запроса LDAPS с использованием доменного имени, test.corp, мы замечаем, что несколько серверов завершают работу со следующим сообщением:
Ошибка [ERR_TLS_CERT_ALTNAME_INVALID]: имя хоста / IP не совпадают
альтернативные имена сертификатов: Host: test.corp. не в сертификате
альтернативные имена: другое имя :, DNS: .test.corp
Как мы выяснили, мы обнаружили, что эти несколько серверов LDAPS обслуживают неправильный сертификат. Мы определили это с помощью следующей команды
openssl s_client -connect .test.corp: 636
Если вы берете раздел сертификата из выходных данных и помещаете его в файл и используете инструмент, такой как менеджер сертификатов или certutil, для чтения файла, вы можете увидеть, что сертификат не является правильным. (У него нет домена "test.corp" SAN). Мы также убедились в этом, сравнив серийные номера
Как мы выяснили, поскольку у нас есть DC, имеющие несколько сертификатов в хранилище Local Computer \ Personal Certificate, мы натолкнулись на следующую статью:
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
Предлагает поместить сертификат с локального компьютера \ личного хранилища сертификатов в доменную службу Active Directory \ личное хранилище. Мы следовали изложенным шагам, но нашли те же результаты.
После дальнейшего исследования было предложено использовать инструмент под названием ldp или adsiedit. Затем мы приступили к использованию этих инструментов и подделали файл хоста локального компьютера, с которого мы проводили тестирование, чтобы указать домен (test.corp) на ip одного из контроллеров домена, которые доставляют нам проблемы. После перезапуска для очистки любого кэша мы протестировали инструменты «ldp» и «adsiedit» для подключения к test.corp. Эти системы не сообщали об ошибках.
Мы нашли это странным, затем запустили команду openssl, чтобы посмотреть, какой сертификат он обслуживал в этой же системе, и обнаружили, что он все еще обслуживает неправильный сертификат.
После дальнейших исследований выясняется, что "ldp" при выборе флажка SSL и инструменты "adsiedit" не были совместимы с RFC6125, в частности B.3
https://tools.ietf.org/html/rfc6125#appendix-B.3
, в котором в основном указывается, что удостоверение сертификата должно совпадать с удостоверением запроса, в противном случае рукопожатие не будет выполнено. Эта проверка идентичности выполняется с использованием общего имени сертификата (CN) или SAN.
Исходя из этого, кажется, что инструменты "ldp" и "adsiedit" не соответствуют стандарту RFC6125.
Все это говорит о том, что нам нужно сначала исправить несколько контроллеров домена, которые обслуживают правильный сертификат. Мы открыты для предложений, так как мы работали над этой проблемой в течение последних нескольких месяцев. Во-вторых, есть ли способ заставить рассматриваемые инструменты MS работать в соответствии со стандартом RFC6125?
Это было перемещено в:
https://serverfault.com/questions/939515/ldaps-microsoft-active-directory-multiple-certificates-rfc6125