Не используются в автономном ЦС Windows Server

Обновлено: 21.11.2024

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

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

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

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

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

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

Обычным развертыванием сертификатов является размещение подчиненных ЦС в демилитаризованной зоне или сети периметра. Этот Автономный ЦС выдает сертификаты непосредственно клиентам. Поскольку на нем нет корневого сертификата, он обеспечивает лучшую безопасность. Недостатком является то, что все выдаваемые сертификаты должны быть утверждены.

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

Можете ли вы совместить их?
Автономные и корпоративные центры сертификации могут быть объединены в иерархию. Наиболее распространенным примером этого является использование автономного корневого ЦС на вершине иерархии. Поскольку ЦС является автономным, после того, как он выдал сертификат подчиненным ЦС, его можно перевести в автономный режим. Корневой ЦС можно установить на съемный носитель. В этом случае некоторые компании поместят съемный носитель, на котором был установлен сервер, в безопасное место, например в сейф. Независимо от того, какой тип ЦС вы устанавливаете в качестве корневого ЦС, подчиненные ЦС могут быть автономными, корпоративными или комбинированными. Часто компании устанавливают автономный ЦС в демилитаризованной зоне и корпоративный ЦС во внутренней сети, чтобы получить максимум функций и максимальную безопасность.

Ссылки
«MCTS 70–640 Настройка Windows Server 2008 Active Directory, второе издание», стр. 780–782

в своей лаборатории я развернул автономный (не присоединенный к домену) сервер корневого центра сертификации. я хочу, чтобы мой vpn-сервер был SSTP-сервером, поэтому мне нужно, чтобы мой vpn-сервер мог получить «сертификат веб-сервера» с моего автономного корневого сервера CA. но в консоли диспетчера сервера, когда я нажимаю узел «Шаблоны сертификатов» на сервере ЦС, шаблона нет, и я получаю эту ошибку:

" информация о шаблонах сертификатов может быть прочитана только с контроллера домена. Контроллер домена не найден в вашей сети"

можно ли сделать шаблоны сертификатов доступными в автономном корневом ЦС?

является ли правилом, что нам всегда нужен ЦС предприятия, чтобы наш сервер SSTP vpn мог получить «сертификат веб-сервера»?

заранее спасибо

Ответы

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

Автономный центр сертификации имеет следующие характеристики:

    В отличие от ЦС предприятия, автономный ЦС не требует использования службы каталогов Active Directory. Автономные ЦС в первую очередь предназначены для использования в качестве доверенных автономных корневых ЦС в иерархии ЦС или когда задействованы экстрасети и Интернет. Кроме того, если вы хотите использовать настраиваемый модуль политики для ЦС, сначала необходимо установить автономный ЦС, а затем заменить автономный модуль политики своим настраиваемым модулем политики.

Когда автономный ЦС использует Active Directory, он имеет следующие дополнительные функции:

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

Выбор между корпоративным и автономным корневым центром сертификации в Windows Server 2012

Нравится этот блог 1

Это часть 4, посвященная использованию инфраструктуры открытых ключей (PKI) и криптографии с закрытыми ключами в среде Windows Server 2012.

В этом посте мы рассмотрим разницу между корпоративным и автономным корневым центром сертификации и рассмотрим, какой из них подходит именно вам.

Одно из самых важных решений, которое вы примете в отношении своей инфраструктуры, касается сведений о вашем корневом центре сертификации (ЦС). И один из первых вопросов, на который вам нужно будет ответить, — какой центр сертификации использовать: корпоративный или автономный.

Рис. 1. Конфигурация AD CS — укажите корпоративный или автономный ЦС.

Разница между корпоративным и автономным

ЦС предприятия интегрирован с Active Directory. Сервер будет использовать службы домена для управления сертификатами, интегрируется с каталогом для именования и аутентификации, а также предоставляет множество других точек интеграции, которые упрощают взаимодействие с пользователем.

Вы должны использовать ЦС предприятия для выдачи сертификатов конечных объектов или пользователей и компьютеров. В этой роли он великолепен. Корневой ЦС никогда не должен быть ЦС предприятия, потому что это подвергает корневой ЦС повышенному риску атаки или неправильной настройки. Во всех случаях это считается крайне плохой практикой. Никогда, никогда не создавайте корпоративный корневой ЦС. Я найду и лично унижу тебя.

Автономный ЦС не интегрируется с AD. Это отличный вариант реализации для многих сценариев, включая клиенты без AD, автономные серверы или просто потому, что вы не хотите использовать Active Directory для управления сертификатами.

Основной недостаток автономного центра сертификации заключается в том, что его резервную копию необходимо создавать самостоятельно, а не полагаться на репликацию Active Directory. Другой возможный недостаток заключается в том, что пользователям может потребоваться аутентификация с использованием отдельных учетных данных, если автономный ЦС не является частью домена. У этих недостатков есть хорошие решения, но их следует учитывать перед развертыванием.

Разверните свой корневой ЦС как автономный, который выдает сертификаты другим ЦС, а затем отключите его, чтобы свести к минимуму его подверженность атакам. Для всех остальных серверов рассмотрите преимущества и недостатки перед развертыванием. Просто помните, что PKI похожа на татуировку: вы должны считать свой выбор постоянным, а исправление неверных решений дорого и болезненно.

Если вам нужны другие статьи по Windows PKI, обязательно напишите мне в комментариях.

Будьте осторожны!
Майк Данселио — CISSP / CEH
Техническое обучение интерфейсу — технический директор и инструктор

Теперь доступна для покупки полная книжная версия этого руководства. Включает расширенную версию этого руководства, которая включает более 300 снимков экрана, команды настройки CLI, краткое руководство, дополнительные сведения и многое другое.

Оглавление

1.1 Настройка сервера корневого центра сертификации

Серверу, на котором будет размещен автономный корневой центр сертификации, для работы требуются минимальные ресурсы. Его можно использовать только для выдачи подчиненных сертификатов другим доменным серверам TFS Labs, а также для отзыва или добавления новых подчиненных сертификатов, если это необходимо. Он также используется для обновления CRL не реже одного раза в год.

Сервер настроен как автономный Windows Server и никогда не должен быть членом домена Active Directory или даже иметь какие-либо сетевые подключения к нему. Это означает, что потребуются некоторые локальные изменения безопасности, которые обычно обрабатываются с помощью групповой политики из Active Directory. Поскольку подключение к Active Directory отсутствует, эти изменения необходимо будет применить локально.

Поскольку нет сетевых подключений к этой виртуальной машине и от нее, создайте виртуальную дискету, которая будет использоваться для передачи файлов на сервер TFS-ROOT-CA и с него. Назовите файл RootCAFiles (расширение файла зависит от того, используете ли вы Hyper-V, VirtualBox или VMware) и сохраните его в месте, которое будет доступно для всех используемых виртуальных машин. При первом подключении к одной из виртуальных машин его необходимо отформатировать с настройками по умолчанию.

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

  1. Создайте новую виртуальную машину со следующими настройками:
    • Виртуальный ЦП — 1
    • Виртуальная память — 4096 МБ
    • Виртуальный жесткий диск — 60 ГБ
    • Виртуальный дисковод для гибких дисков — 1
    • Виртуальные сетевые адаптеры – 0
  2. Установите Windows Server 2019 Standard (Desktop Experience) с параметрами по умолчанию.
  3. Задайте для имени хоста сервера значение TFS-ROOT-CA. Сделайте его членом рабочей группы TFS-CA, а не домена.
  4. Защитите локальную учетную запись администратора и дополнительные учетные записи пользователей на сервере TFS-ROOT-CA:
    • Используйте сложный пароль для учетной записи администратора и храните его в надежном месте.
    • Убедитесь, что на сервере нет дополнительных учетных записей пользователей. Учетная запись гостя уже должна быть отключена по умолчанию и будет переименована на следующем этапе этого руководства.
    • Учетная запись администратора будет переименована в CA-Admin на следующем этапе этого руководства.
  5. Нет необходимости активировать лицензию Windows Server или даже вводить лицензионный ключ (однако убедитесь, что у вас есть лицензия). Если когда-либо потребуется активация на этом сервере, то для этого потребуется опция телефона, поскольку на этом сервере нет сетевого подключения.
  6. В корне диска C:\ создайте папку с именем RootCA (C:\RootCA). В этой папке будут храниться корневой сертификат, подчиненный сертификат и другие необходимые файлы сертификатов, которые необходимы в течение всего процесса внедрения.
  7. Вставьте виртуальную дискету RootCAFiles в виртуальный дисковод. Отформатируйте дискету с настройками по умолчанию. Извлеките диск после завершения.
  8. Откройте консоль редактора локальной групповой политики (gpedit.msc), подтвердите следующие настройки и внесите необходимые изменения:
    • Измените политику локального компьютера > Конфигурация компьютера > Параметры Windows > Параметры безопасности > Локальные политики > Параметры безопасности, чтобы они соответствовали следующим параметрам:
      • Учетные записи: статус учетной записи администратора – включен.
      • Учетные записи: блокировка учетных записей Microsoft — пользователи не могут добавлять учетные записи Microsoft или входить в них
      • Аккаунты: статус гостевого аккаунта — отключен
      • Учетные записи: ограничение использования пустых паролей локальной учетной записью только для входа в консоль — включено
      • Учетные записи: переименуйте учетную запись администратора в CA-Admin.
      • Учетные записи: переименуйте гостевую учетную запись в Администратор
      • Интерактивный вход: не отображать последний вход в систему — включено
      • Интерактивный вход: не отображать имя пользователя при входе — включено
      • Безопасность сети: не сохранять хеш-значение LAN Manager при следующей смене пароля — включено
      • Сетевая безопасность: уровень проверки подлинности LAN Manager — отправлять только ответ NTLMv2. Отказаться от LM и NTLM
  9. Откройте консоль локальной политики безопасности (secpol.msc), подтвердите следующие параметры и внесите необходимые изменения:
    1. Измените параметры безопасности > Политики учетных записей > Параметры политики паролей:
      • Использовать историю паролей — запоминание 24 паролей
      • Максимальный срок действия пароля – 90 дней.
      • Минимальный срок действия пароля – 1 день.
      • Минимальная длина пароля – 14 символов.
      • Пароль должен соответствовать требованиям сложности — включено
      • Хранить пароли с помощью обратимого шифрования — отключено
    2. Измените параметры безопасности > Политики учетных записей > Параметры политики блокировки учетных записей:
      • Порог блокировки аккаунта – 5 неверных попыток входа.
      • Продолжительность блокировки аккаунта – 30 минут.
      • Сброс счетчика блокировки аккаунта через 30 минут.
      1. Откройте консоль диспетчера серверов (servermanager.exe), откройте меню «Управление» и нажмите «Добавить роли и компоненты», чтобы запустить мастер установки.
      2. На экране «Перед началом работы» нажмите кнопку «Далее», чтобы продолжить.
      3. На экране «Тип установки» выберите вариант установки на основе ролей или компонентов и нажмите кнопку «Далее», чтобы продолжить.
      4. На экране «Выбор сервера» убедитесь, что выбран сервер TFS-ROOT-CA, и нажмите кнопку «Далее», чтобы продолжить.
      5. На экране "Роли сервера" нажмите кнопку "Далее", чтобы продолжить.
      6. На экране «Функции» выберите функцию шифрования диска BitLocker. Мастер установки попросит установить необходимые инструменты управления ролью. Нажмите кнопку "Добавить функции", чтобы продолжить.
      7. На экране "Функции" нажмите кнопку "Далее", чтобы продолжить.
      8. На экране подтверждения выберите параметр Автоматический перезапуск целевого сервера, если это необходимо. При появлении предупреждения с предупреждением о перезапуске Сервера нажмите кнопку Да (для продолжения Сервер должен перезагрузиться). Нажмите кнопку "Установить", чтобы продолжить.
      9. После перезапуска сервера TFS-ROOT-CA нажмите кнопку "Закрыть" на экране "Ход установки".
      10. Откройте консоль редактора локальной групповой политики (gpedit.msc) и измените параметры «Конфигурация компьютера» > «Административные шаблоны» > «Компоненты Windows» > «Шифрование диска BitLocker» > «Диски операционной системы» в соответствии со следующими параметрами:
        • Требовать дополнительную аутентификацию при запуске — включено
        • Разрешить BitLocker без совместимого TPM (требуется пароль или ключ запуска на USB-накопителе) — включено
        • Настройка запуска TPM: Разрешить TPM
        • Настройка ПИН-кода запуска TPM: разрешить ПИН-код запуска с TPM
        • Настроить ключ запуска TPM: разрешить ключ запуска с TPM
        • Настройка ключа запуска и PIN-кода TPM: разрешить ключ запуска и PIN-код с помощью TP
      11. Вставьте виртуальную дискету RootCAFiles.
      12. Откройте Проводник и перейдите в раздел Этот компьютер. Щелкните правой кнопкой мыши диск C:\ и выберите Включить BitLocker.
      13. На экране настройки BitLocker Drive Encryption нажмите кнопку "Далее", чтобы продолжить.
      14. На экране "Подготовка диска для BitLocker" нажмите кнопку "Далее", чтобы продолжить.
      15. На экране настройки BitLocker Drive Encryption нажмите кнопку "Далее", чтобы продолжить.
      16. На экране «Выбор способа разблокировки диска при запуске» выберите вариант «Ввести пароль».
      17. На экране Создать пароль для разблокировки этого диска введите пароль, который вы хотите использовать для разблокировки диска при загрузке. Убедитесь, что вы не забыли этот пароль, так как для возврата в виртуальную машину TFS-ROOT-CA потребуются ключи восстановления. Убедитесь, что вы используете для этого сложный пароль и сделайте его длиной не менее 14 символов. Нажмите кнопку "Далее", чтобы продолжить.
      18. В разделе Как вы хотите создать резервную копию ключа восстановления? экране выберите параметр Сохранить в файл. Сохраните файл на диск A:\ (дискета). Нажмите кнопку "Далее", чтобы продолжить.
      19. Извлеките виртуальную дискету RootCAFiles, а затем сделайте резервную копию ключа восстановления на другом устройстве, прежде чем продолжить. Это важно в случае возникновения проблемы с паролем BitLocker.
      20. На экране "Выберите объем диска для шифрования" выберите вариант "Зашифровать весь диск" (медленнее, но лучше для ПК и уже используемых дисков) и нажмите кнопку "Далее".
      21. На экране "Выберите режим шифрования" выберите вариант "Новый режим шифрования" (наилучший для фиксированных дисков на этих устройствах) и нажмите кнопку "Далее", чтобы продолжить.
      22. На странице Готовы ли вы зашифровать этот диск? убедитесь, что установлен флажок «Запустить систему BitLocker», а затем нажмите кнопку «Продолжить».
      23. При появлении запроса перезапустите сервер TFS-ROOT-CA.
      24. Введите пароль, который вы установили для диска, чтобы убедиться, что он работает правильно.
      25. Войдите на сервер TFS-ROOT-CA, вы должны получить уведомление о том, что диск шифруется. Вы также можете в любое время проверить состояние BitLocker, перейдя в Проводник, затем в Этот компьютер, щелкнув правой кнопкой мыши диск C:\ и выбрав параметр «Управление BitLocker».

      1.2 Установка корневого CA CAPolicy.inf

      Файл CAPolicy.inf используется для добавления сведений о конфигурации к сертификату во время его создания. Создайте в папке C:\Windows файл с именем CAPolicy.inf (убедитесь, что он сохранен с расширением inf, а не с расширением txt, иначе эти настройки будут проигнорированы). Скопируйте в этот файл следующее содержимое:

      Примечание. При необходимости вы можете обновить номер OID в разделе InternalPolicy для вашего развертывания. Номер OID в этом примере используется в примерах Microsoft, но он должен работать в вашей организации, если он будет использоваться только внутри компании. Вы можете зарегистрироваться на него, если хотите, через IANA.

      Проблемы поддержки алгоритма подписи

      Флаг AlternateSignatureAlgorithm=0 в файле CAPolicy.inf явно использует алгоритм SHA256 вместо RSASSA-PSS. Это может вызвать проблемы с некоторыми устройствами (особенно с iOS), и если отключить эту функцию, у вас не должно возникнуть проблем с этими сертификатами.

      1.3 Установка роли служб сертификации Active Directory

      После правильной установки и настройки сервера TFS-ROOT-CA необходимо установить роль служб сертификации Active Directory.

      1. Откройте консоль диспетчера серверов (servermanager.exe), откройте меню «Управление» и нажмите «Добавить роли и компоненты», чтобы запустить мастер установки.
      2. На экране «Перед началом работы» нажмите кнопку «Далее», чтобы продолжить.
      3. На экране «Тип установки» выберите вариант установки на основе ролей или компонентов и нажмите «Далее», чтобы продолжить.
      4. На экране «Выбор сервера» убедитесь, что выбран сервер TFS-ROOT-CA, и нажмите «Далее».
      5. На экране "Роли сервера" выберите параметр "Службы сертификатов Active Directory". Мастер установки попросит установить необходимые инструменты управления ролью. Нажмите кнопку "Добавить функции", чтобы продолжить.
      6. На экране "Роли сервера" нажмите кнопку "Далее", чтобы продолжить.
      7. На экране "Функции" нажмите кнопку "Далее", чтобы продолжить.
      8. На экране служб сертификации Active Directory нажмите кнопку "Далее", чтобы продолжить.
      9. На экране «Службы ролей» выберите параметр «Центр сертификации» и нажмите кнопку «Далее», чтобы продолжить.
      10. На экране подтверждения выберите параметр Автоматический перезапуск целевого сервера, если это необходимо. При появлении предупреждения с предупреждением о перезапуске Сервера нажмите кнопку Да (для продолжения Сервер должен перезагрузиться). Нажмите кнопку "Установить", чтобы продолжить.
      11. После завершения установки нажмите кнопку "Закрыть".

      1.4 Конфигурация ролей служб сертификации Active Directory

      После добавления роли служб сертификации Active Directory ее необходимо настроить. В процессе настройки роли для домена TFS Labs будет создан следующий корневой сертификат:

      Срок действия сертификата

      Не рекомендуется устанавливать для корневого сертификата и подчиненного сертификата одинаковый срок действия. Например, если оба сертификата имеют срок действия 5 лет, возможно, срок действия корневого сертификата истечет раньше, чем у подчиненного сертификата, поскольку он был подписан первым. Если это произойдет, будет крайне сложно переподписать оба сертификата, потому что они оба станут недействительными одновременно.

      1.5 Конфигурация CRL корневого центра сертификации

      Конфигурация CRL для корневого ЦС настраивается на этом шаге, чтобы обеспечить больший контроль над тем, когда это происходит, и время увеличивается до 52 недель, поскольку CRL не нужно часто обновлять в корневом ЦС. Это также обеспечивает увеличение срока службы подчиненного ЦС с 1 года до 5 лет.

      Отличительное имя раздела конфигурации Active Directory

      Чтобы определить правильный формат этого имени для вашего домена, вы можете проверить его, выполнив всего несколько шагов.

      1. На одном из контроллеров домена откройте консоль пользователей и компьютеров Active Directory (dsa.msc).
      2. Перейдите в меню "Вид" и выберите "Дополнительные функции".
      3. Щелкните правой кнопкой мыши корень домена и выберите "Свойства".
      4. Перейдите на вкладку Редактор атрибутов.
      5. Пролистайте вниз, пока не найдете поле атрибута disabledName, и нажмите кнопку "Просмотр".
      6. Скопируйте значение в поле атрибута, это информация, необходимая для шага 2 ниже.

      После того, как отличительное имя раздела конфигурации Active Directory будет определено, остальную часть настройки можно продолжить.

      1. Откройте административную командную строку.
      2. Чтобы определить отличительное имя раздела конфигурации Active Directory, выполните следующую команду:
        1. Чтобы определить единицы срока действия для всех сертификатов, выданных этим ЦС, выполните следующие команды:
          1. Чтобы определить единицы периода CRL и период CRL, выполните следующие команды:
            1. Чтобы определить единицы периода перекрытия CRL и период перекрытия CRL, выполните следующие команды:
              1. Перезапустите службу служб сертификации Active Directory:

              Период обновления CRL

              Как определено в шаге 4 раздела 1.5, период CRL в корневом ЦС установлен на 52 недели. Это означает, что каждые 52 недели вам нужно будет включать сервер TFS-ROOT-CA и обновлять CRL. Вы должны установить в своем календаре напоминание о выполнении этой задачи каждые 50 недель, чтобы обеспечить своевременное обновление.

              1.6 Включить аудит в корневом центре сертификации

              Аудит необходим на любом сервере, на котором запущены службы сертификатов Active Directory. Это будет записывать журналы в журнал событий Windows всякий раз, когда выдается или отзывается сертификат.

              1. Откройте консоль локальной политики безопасности (secpol.msc) и измените параметр «Параметры безопасности» > «Локальные политики» > «Политика аудита» > «Аудит доступа к объекту», чтобы отслеживать успехи и неудачи.
              2. Включите аудит центра сертификации, выполнив следующую команду в административной командной строке:
                1. Перезапустите службу служб сертификации Active Directory.

                1.7 Конфигурация CDP и AIA корневого центра сертификации

                Прежде чем можно будет правильно настроить подчиненный центр сертификации, необходимо настроить список отзыва сертификатов в корневом сертификате ЦС. Эта конфигурация будет присутствовать в подчиненном сертификате, который будет выдан ЦС предприятия, который будет установлен на сервере TFS-CA01.

                1. Откройте консоль центра сертификации (certsrv.msc) для сервера TFS-ROOT-CA.
                2. Щелкните правой кнопкой мыши сервер центра сертификации TFS Labs и выберите "Свойства".
                3. На вкладке "Расширения" убедитесь, что выбрано расширение CRL Distribution Point (CDP), и нажмите кнопку "Добавить".
                4. В поле "Местоположение" введите следующий адрес и нажмите кнопку "ОК":
                  1. Вернувшись на вкладку "Расширения", убедитесь, что параметр Включить в CRL. Клиенты используют это для поиска местоположений Delta CRL. и Включить в расширение выданных сертификатов CDP выбраны для только что введенного местоположения.
                  2. Выберите элемент списка file:// /CertEnroll/TFS%20Labs%20Certificate%20Authority.crl и нажмите кнопку «Удалить». Нажмите кнопку "Да", чтобы подтвердить удаление местоположения.
                  3. На вкладке "Расширения" убедитесь, что выбрано расширение доступа к авторитетной информации (AIA), и нажмите кнопку "Добавить".
                  4. В поле "Местоположение" введите следующий адрес и нажмите кнопку "ОК":
                    1. Вернувшись на вкладку "Расширения", убедитесь, что для только что введенного расположения выбран параметр "Включить в расширение AIA выданных сертификатов".
                    2. Выберите элемент списка file:// /CertEnroll/ _ .crt и нажмите кнопку «Удалить». Нажмите кнопку "Да", чтобы подтвердить удаление местоположения.
                    3. Нажмите кнопку "ОК", чтобы применить изменения. При появлении запроса на перезапуск служб сертификации Active Directory нажмите кнопку "Да".
                    4. Проверьте правильность настроек, выполнив следующие команды в административной командной строке:
                      1. В консоли центра сертификации (certsrv.msc) щелкните правой кнопкой мыши отозванные сертификаты в разделе Центр сертификации TFS Labs и выберите Все задачи > Опубликовать.
                      2. Убедитесь, что в окне "Опубликовать список отзыва сертификатов" выбран вариант "Новый список отзыва сертификатов", и нажмите кнопку "ОК".
                      3. Закройте консоль центра сертификации.

                      1.8 Экспорт корневого сертификата и списка CRL

                      Экспорт списка CRL корневых сертификатов необходим, чтобы сделать его доступным на сервере TFS-CA01. Ссылки на эти файлы указаны в конфигурации сертификата, поэтому их необходимо скопировать на подчиненный сервер ЦС, чтобы пользователи могли получить доступ к этим файлам.

                      Читайте также: