Сбой службы сертификатов AD Windows 2003 на основном контроллере домена?

Ну, ты в каком-то беспорядке, это точно. Во-первых, вы НЕ устанавливаете CA на сервере Exchange, DC или, фактически, на любой машине с другими ролями. Это квитанция за катастрофу. Правильная настройка ЦС заключается в том, что вы выбираете сервер в качестве корневого (предпочтительно автономного корневого ЦС) и второй сервер в качестве промежуточного ЦС для других нужд.

Вы делаете это таким образом, чтобы в случае, если что-то случилось с промежуточным ЦС (как это случилось с вашим), вы можете отозвать его из корневого ЦС и создать новый без особых проблем.

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

Предполагая, что вышеприведенное верно, вот ваша ситуация: у вас есть центр сертификации, который использовался для выдачи сертификатов, который теперь отключен. Этот ЦС используется всей вашей машиной для автоматической регистрации сертификата, и вы в дальнейшем использовали этот сертификат для аутентификации.

Теперь, если вы правильно настроили систему, вам нужно было отозвать старый промежуточный ЦС в корневом каталоге, опубликовать новый CRL, установить другой промежуточный ЦС и повторно выдать сертификаты. Возможно, вам также придется использовать редактирование ADSI, чтобы переназначить запись LDAP службы регистрации.

В вашем случае вы не можете сделать это таким образом. Вам придется либо попытаться выполнить миграцию своих прав доступа (при условии, что у вас все еще есть доступ к закрытому ключу, связанному с вашим корневым ЦС, либо вы можете восстановить его), либо начать с нуля с новыми полномочиями.

Если вы решили создать новый авторитет, вот что вы должны сделать:

• Если вы не можете использовать разные серверы для корневого ЦС и промежуточного ЦС, выделите хотя бы компьютер в качестве корневого ЦС. Вы также можете выбрать создание корневого ЦС с помощью OpenSSL и использовать этот ЦС для подписания промежуточного ЦС, интегрированного в AD, но помните, что вам придется время от времени вручную создавать новые CRL для этого корня (однако вы можете установить этот корень на той же машине, если вы защищаете ее должным образом). Я бы использовал новое имя сервера, чтобы убедиться, что вы не смешиваете новые и старые корни (что может вызвать проблемы и путаницу), но вы можете использовать одно и то же имя, если хотите.
• Получив новую иерархию ЦС, распределите новый корень с помощью групповых политик на все машины в вашем домене. Добавьте корень в хранилище "доверенных корневых центров сертификации" и промежуточный ЦС в хранилище "Промежуточных центров сертификации" (второй шаг в основном является мерой предосторожности).
• Локально заставить старый CA быть ненадежным. Для этого используйте групповые политики, чтобы добавить открытый сертификат в хранилище "Ненадежные сертификаты".
• Перенаправьте службы регистрации на новый сервер. Для этого используйте adsiedit, чтобы перейти к Configuration / services / Public Key Services / Enrollment Services и удалить ссылку на старый сервер CA (новый уже должен был быть там зарегистрирован).
• Повторно выдать все сертификаты, которые вам нужны. Если вы правильно настроили ЦС, любой сертификат, использующий автоматическую регистрацию, будет автоматически сгенерирован заново из нового ЦС, а старый будет сброшен. Если вы не уверены, что эти сертификаты НЕ использовались для шифрования, НЕ удаляйте их с клиентских машин / учетных записей.

(PS Во-первых, не расстраивайтесь из-за того, что не настроили это должным образом: управление ЦС сложно, а неправильно делать это очень легко. MS упростила задачу, сделав службы сертификатов такими простыми и быстрыми. установить: вы практически обречены ошибиться с первого раза, если не знаете точно, что делаете).