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

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

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

Вы не указали, какой тип ЦС вы развернули (автономный или интегрированный в AD), но, исходя из проблем, которые вы описываете, я предполагаю, что он интегрирован в AD.

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

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

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

Если вы решили создать новый орган, вам следует сделать следующее:

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

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