Использование альтернативного центра сертификации (например, службы сертификации Microsoft) с Puppet

Я исследую, могу ли я каким-то образом заставить марионеточную экосистему использовать наш существующий Microsoft Enterprise CA, а не собственный CA.

Поскольку Puppet заявляет, что вся система является «стандартным SSL», я предполагаю, что это вполне возможно сделать без особого изменения марионетки, ОДНАКО это, вероятно, огромная головная боль, если только марионетка не отредактирована для правильных вызовов предприятия. CA.

Кто-нибудь пробовал это раньше? Является ли это "здесь быть драконами, отвернись!" ситуация?

Поведение проверки сертификата и иерархии в puppet действительно является стандартным SSL, но это своего рода частичная реализация стандартов - существует давний запрос функциональности для улучшения поддержки более сложных развертываний .

Если цель состоит в том, чтобы перевести выдачу и утверждение сертификата в систему служб сертификации AD (и никогда больше не печатать puppet cert sign), то вам, вероятно, не повезет без какой-либо работы по разработке программного обеспечения.

Клиент использует собственный REST API Puppet для обработки запросов на сертификаты, получения подписанных сертификатов, доступа AIA и CRL и т. Д .; вам нужно реализовать связь между этими вызовами API и точками доступа RPC служб сертификации AD.

Но если вы просто хотите, чтобы ваши сертификаты Puppet находились в цепочке доверия под корневым каталогом AD CS, то рекомендация sysadmin1138 должна работать отлично (хотя я и не тестировал ее - я найду время для этого и обновлю) вы).

Клиенты Puppet будут обрабатывать промежуточный CA Puppet так, как если бы он был корневым CA (что даст рабочую проверку без необходимости знания корневого), при этом оставаясь действительными потомками реального корневого CA.