Я собираюсь установить новую интегрированную в AD структуру центра сертификации предприятия, но обнаружил, что кто-то уже создал центр сертификации (в основном используется для SSL на внутренних веб-сайтах).
Я хочу построить новую структуру в соответствии с передовой практикой, создав автономный корень, авторизовав несколько подчиненных центров сертификации для обеспечения отказоустойчивости и т. Д., Но я не хочу испортить то, что уже есть. По-видимому, вы не можете превратить существующий корневой ЦС в подчиненный, поэтому это исключено.
Могу ли я просто установить новый рут в другом месте, не трогая существующий? (Или, может быть, подписать существующий ЦС с полномочиями нового корня?)
Разобравшись с тем же сценарием, вот обзор моего подхода:
Установите и запустите новую среду, но не давайте ей возможности выдавать сертификаты - используйте LoadDefaultTemplates=False в вашем capolicy.inf.
Хотя устройства по-прежнему настроены на то, чтобы не выдавать никаких шаблонов, уравняйте все с новой средой, местоположениями AIA, распределением CRL и т. Д. Проверьте работоспособность всех с помощью оснастки Enterprise PKI.
Затем, когда вы будете готовы, измените конфигурацию существующего центра сертификации, чтобы прекратить выдачу сертификатов для определенных шаблонов. Вы еще не убиваете сервер, а просто говорите ему, чтобы он прекратил выдавать новые сертификаты. Добавьте те же самые шаблоны в разрешенные политики выпуска вашей новой среды.
Затем используйте параметр «повторно зарегистрировать держателей сертификатов» в средстве управления шаблонами для шаблонов, которые имеют сертификаты и регистрируются автоматически (сертификаты пользователя, компьютера и контроллера домена). Это приведет к увеличению версии шаблона и заставит их получить новый сертификат из новой инфраструктуры, когда их автоматическая подача заявки будет импульсной.
Это покроет вас для этих сертификатов, но для сертификатов веб-сервера, к сожалению, это будет ручной процесс. Выпустите повторно для каждого и измените слушателей на новые сертификаты.
Как только вы будете достаточно уверены, что все сертификаты были выданы повторно, выведите из строя старый ЦС, но пока не удаляйте роль. Сделайте что-нибудь вроде удаления всех точек распространения AIA или CRL в конфигурации CA, а затем удаления файлов / объектов из этих мест (LDAP, вероятно, является основным, но http и smb также нуждаются в проверке). Подождите несколько недель; когда что-то сломается, вы можете повторно добавить точки AIA / CRL, которые вы удалили, и повторно опубликовать (certutil -dspublish) если нужно.
Как только вы убедитесь, что старый ЦС больше не использует, удалите роль, а затем очистите Active Directory. AIA, CRL и дельта CRL требуют удаления вручную, что можно сделать с помощью параметра «Управление контейнерами AD» в оснастке Enterprise PKI.
Согласно этой статье: http://thedailyreviewer.com/server/view/multiple-enterprise-certificate-authorities-10276898 Microsoft разрешает это, но не рекомендует. Мы столкнулись с этим выбором: мы отключили старый сервер и начали заново. Одним из первых, что мы сделали, было перевыпускать сертификаты тем, кто активно использует SSL.