Наша сеть состоит в основном из серверов Windows в нашем внутреннем домене, который управляется Active Directory (natch). У нас также есть небольшая группа серверов Linux, которые по определенным причинам управляются IDM. Также по причинам IDM настроен с односторонним доверием к AD (IDM доверяет AD), чтобы облегчить управление пользователями в одном месте (это не может быть изменено).
На данный момент у нас есть три домена (имена изменены для защиты невиновных):
linux.internal.dom поддерживается на сервере IDM, а два других находятся в AD. Поскольку доверие между IDM и AD одностороннее, оно не отображается в пользовательском интерфейсе AD. Остальные, конечно, видны в AD, поскольку там они и поддерживаются.
Мы настраиваем службы сертификации AD, чтобы мы могли выпускать сертификаты для каждого домена. Однако, поскольку linux.internal.dom находится на IDM, который имеет только одностороннее доверие и поэтому не отображается в AD, нельзя создавать сертификаты для него в пользовательском интерфейсе. В конечном счете, мы все равно не будем использовать пользовательский интерфейс, поскольку автоматизированный / скриптовый метод будет более эффективным.
Итак, теперь мой вопрос: может ли ЦС AD выдать сертификат для (под) домена, которому не полностью доверяют? То есть сможем ли мы выдавать сертификаты для linux.internal.dom, даже если он не отображается в пользовательском интерфейсе AD?
Вы контролируете ЦС; таким образом, вы можете выдавать сертификаты на любое имя, какое захотите. При желании вы можете оформить сертификат для linux.bobsyouruncle.com. Любой клиент, который доверяет этому ЦС, должен соответственно доверять сертификатам, выданным им или его подчиненными ЦС.
В любом случае доверие Active Directory и его направленность обязательно отделены от цепочки доверия центра сертификации.
Отличным примером этого процесса может быть проверка SSL брандмауэром, выполняющая анализ трафика - возможно, законный вариант использования Man-in-the-Middle. Для каждого запроса к зашифрованному веб-сайту соответствующий брандмауэр (обычно через прозрачный прокси) генерирует доверенный (но технически фальшивый) сертификат для FQDN соответствующего внешнего ресурса.