Використання альтернативного CA (як і сервісні сертифікати Microsoft) з Puppet

Я розслідую, чи можу я якось змусити маріонеткову екосистему використовувати нашу існуючу Microsoft Enterprise CA, а не бути її власною ЦА.

Оскільки маріонетка рекламує, що вся система є "стандартним SSL", я гадаю, що це цілком можливо зробити без особливих змін лялечки, ЗАРАЗ, швидше за все, це величезний головний біль вручну, якщо лялька не буде відредагована, щоб зробити належні дзвінки на підприємство CA.

Хтось пробував це раніше? Це "ось дракони, відверніться!" ситуація?

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

Якщо мета полягає в тому, щоб випуск та затвердження сертифікатів було переведено на систему сертифікаційних послуг AD (і ніколи більше не puppet cert signвводиться), вам, мабуть, не пощастить без певної роботи з розробки програмного забезпечення.

Клієнт використовує власний API REST Puppet для обробки запитів на сертифікати, отримання підписаних сертифікатів, доступу AIA та CRL тощо; вам потрібно буде застосувати клей між цими дзвінками API та точками доступу RPC Services Certificate Services.

Але, якщо ви просто шукаєте, щоб ваші лялькові сертифікати знаходилися в ланцюзі довіри під вашим коренем AD CS, тоді рекомендація sysadmin1138 має чудово працювати (хоча я також не перевіряв її - я знайду час для цього та оновлення ви).

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