Что такое active directory certificate services. Обновление сертификатов ЦС. Планирование инфраструктуры открытых ключей

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

Опытные администраторы знают к чему приводит включение Audit Object Access - к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.

Прочие настройки

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
• Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish path\contoso-rca.crt RootCA
Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root path\contoso-rca.crt

Установка издающего ЦС

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки и конфигурации.

Предустановочная конфигурация

1. Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
2. Администраторы сами должны определять какие шаблоны будут использовать в организации.

; заголовок INI файла Signature= "$Windows NT$" ; указываем список политик, которые будут включены в сертификат ЦС. В нашем; случае будет одна политика под названием AllIssuancePolicies. Policies = AllIssuancePolicy ; конфигурируем детали самой политики. Ссылку на документ Certificate Practice ; Statement (CPS) и объектный идентификатор политики URL = http://cdp.contoso.com/pki/contoso-cps.html OID = 2.5.29.32.0 IsCA = True PathLegth = 0 IsCritical = True ; секция прочих настроек ЦС ; отключаем автоматическую загрузку шаблонов сертификатов для выдачи LoadDefaultTemplates = 0
Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools
После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" ` -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" ` -CAType EnterpriseSubordinateCa ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -KeyLength 4096 ` -HashAlgorithmName SHA256
После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

# отправляем запрос на ЦС. certreq -submit "C:\CA-01.contoso.com_Contoso Lab Issuing Certification authority.req" # предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде # в моём случае это номер 2 certutil -resubmit 2 # после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер # запроса, который был указан после выполнения первой команды certreq -retrieve 2 C:\subca.crt
Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:

Certutil -installcert c:\subca.crt net start certsvc
Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

Итоговая настройка

Аналогичная таблица составляется и для издающего ЦС.

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: Issuing CA post-installation script:: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: все комментарии помечены знаком двойного двоеточия (::) :: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва:: в отдельные переменные SET CrlLocal=\\IIS\PKI\contoso-pica%%8%%9.crl SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва. certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:%CrlLocal%\n6:%CDP%" certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%" :: Поскольку мы не можем указывать пути публикации для файла сертификата, мы:: вручную переименовываем его в необходимый формат и копируем в сетевую папку ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-pica.crt copy %windir%\system32\CertSrv\CertEnroll\contoso-pica.crt \\IIS\PKI:: Задаём срок действия издаваемых сертификатов certutil -setreg CA\ValidityPeriodUnits 5 certutil -setreg CA\ValidityPeriod "Years" :: Задаём время жизни списков отзыва согласно нашей конфигурации:: базовый CRL certutil -setreg CA\CRLPeriodUnits 1 certutil -setreg CA\CRLPeriod "weeks" :: Delta CRL certutil -setreg CA\CRLDeltaPeriodUnits 1 certutil -setreg CA\CRLDeltaPeriod "days" :: Включаем полный аудит событий на ЦС** certutil -setreg CA\AuditFilter 127:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32" :: Включаем поддержку расширения OcspRevNoCheck, если планируется установка:: сетевого ответчика (Online Responder или OCSP сервера) certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи. :: Windows Server 2016 по умолчанию использует SHA256. Certutil -setreg ca\csp\CNGHashAlgorithm SHA256:: Перезапускаем службу ЦС для применения изменений. net stop certsvc && net start certsvc:: Публикуем списки отзыва. certutil -CRL
Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

Прочие настройки

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
• Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.
 

Шаблоны сертификатов

Использование готовых шаблонов сертификатов

Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon . Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.

Версия шаблона

Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:

Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на.NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).

Успешно такие сертификаты смогут использовать приложения, которые используют не.NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.
Поля Subject и Subject Alternative Names

Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.

Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».

Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.

Права на шаблоны сертификатов

Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.
 

Обновление сертификатов ЦС

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

• Срок жизни сертификата ЦС истекает;
• Ключ ЦС скомпрометирован;
• Необходимо изменить длину ключа или алгоритм подписи;
• Слишком большой список отзыва (больше нескольких мегабайт).

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

Порядок обновления ЦС

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

Генерация ключей при обновлении сертификатов ЦС

При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

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

Служба сертификации Active Directory (AD CS) является очень удобным и полезным инструментом в доменной сети. Данный компонент входит в состав Windows Server 2012 R2, позволяет бесплатно выдавать ssl-сертификаты внутри вашего домена и управлять ими. Такие сертификаты могут понадобиться при работе с почтовым сервером Microsoft Exchange, сеансами удаленных рабочих столов и т. д.

Службу AD CS не рекомендуется устанавливать на контроллер домена. В данной статье в качестве примера будут использоваться 3 сервера под управлением операционной системы Windows Server 2012 R2: DC-01 (контроллер домена), FS-01 (сервер, на который будет установлена служба AD CS) и TS-00 (сервер, для которого мы будем получать ssl-сертификат).

1. Заходим в Диспетчер серверов на сервере FS-01:

Выбираем пункт «Управление» и далее «Добавить роли и компоненты».

2. Откроется Мастер добавления ролей и компонентов. На вкладке «Тип установки» выбираем пункт «Установка ролей и компонентов»:

Нажимаем «Далее».

3. На вкладке «Выбор сервера» отмечаем пункт «Выберите сервер из пула серверов» и в области «Пул серверов» выбираем конечный сервер для установки Active Directory Certificate Services:

В моем случае это локальный сервер FS-01 с ip-адресом 192.168.1.22. Нажимаем «Далее».

4. На вкладке «Роли сервера» выбираем роль «Службы сертификатов Active Directory»:

В новом окне предстоит добавить компоненты, необходимые для Службы сертификатов Active Directory:

Ставим галочку напротив пункта «Включить средства управления (если применимо)» и нажимаем кнопку «Добавить компоненты». После этого вновь откроется Мастер добавления ролей и компонентов на вкладке «Роли сервера», где необходимо нажать кнопку «Далее».

5. На вкладке «Компоненты» оставляем все настройки по умолчанию и нажимаем «Далее»:

6. Информационная вкладка Службы сертификации Active Directory:

На данной вкладке представлены краткие сведения о Службах сертификации Active Directory. В частности сообщается о том, что нельзя менять имя и параметры домена компьютера, на котором установлена AD CS. После прочтения информации нажимаем «Далее».

7. На вкладке «Службы ролей» выбираем службу «Центр сертификации»:

Нажимаем «Далее».

8. На вкладке «Подтверждение» можно ознакомиться со списком всех служб ролей и компонентов, которые будут установлены на данном сервере:

Для изменения настроек воспользуйтесь кнопкой «Назад». Если все правильно, нажимаем кнопку «Установить». Перед установкой рекомендую активировать пункт «Автоматический перезапуск конечного сервера, если потребуется», чтобы при необходимости сервер смог автоматически перезагрузиться в процессе установки службы сертификации AD CS.

9. Начнется установка службы сертификации AD CS и других служб ролей и компонентов:



Дождитесь завершения установки. Данное окно можно закрыть.

10. Когда установка AD CS завершится, перейдите в Диспетчер серверов, нажмите на «флажок» с восклицательным знаком в желтом треугольнике и выберите пункт «Настроить службы сертификатов Active Directory»:

11. Откроется окно «Конфигурация службы сертификатов Active Directory». На вкладке «Учетные данные» укажите учетные данные пользователя для настройки служб роли:

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

12. Выбор службы роли для настройки (Центр сертификации):

На вкладке «Службы ролей» выбираем «Центр сертификации» и нажимаем «Далее». Обратите внимание, что необходимо сначала настроить службу роли «Центр сертификации», а затем другие службы, т. е. одновременный выбор нескольких служб на данной вкладке не поддерживается.

13. Вариант установки Центра сертификации:

На вкладке «Вариант установки» выберите пункт «ЦС предприятия» и нажмите «Далее».

14. Тип Центра сертификации:

На вкладке «Тип ЦС» выбираем пункт «Корневой ЦС» и нажимаем «Далее».

15. Тип закрытого ключа:

На вкладке «Закрытый ключ» выбираем пункт «Создать новый закрытый ключ» и нажимаем «Далее».

16. Параметры шифрования:

На вкладке «Шифрование» предлагаю параметры «Поставщик служб шифрования» (RSA#Microsoft Software Key Storage Provider) и «Длина ключа» (2048) оставить по умолчанию, а значение «Хэш-алгоритма для подписывания сертификатов, выдаваемых этим ЦС» указать «SHA256». Нажимаем «Далее».

17. Имя Центра сертификации:

На вкладке «Имя ЦС» можно указать общее имя для этого центра сертификации, суффикс различающегося имени и предпросмотр различающегося имени. В моем случае все значения остаются по умолчанию. Нажимаем «Далее».

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

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

19. Расположение базы данных сертификатов:

На вкладке «База данных сертификатов» укажите расположение базы данных сертификатов и журнала базы данных сертификатов. В моем случае значения остаются по умолчанию. Нажимаем «Далее».

20 Подтверждение установки Центра сертификации:

На данной вкладке можно ознакомиться со всеми выбранными настройками и при необходимости их изменить, воспользовавшись кнопкой «Назад». Если все правильно, нажимаем «Настроить».

21. Настройка Центра сертификации выполнена успешно:

Если процесс завершился без ошибок, нажимаем кнопку «Закрыть».

22. Переходим в Диспетчер серверов:

Установка Службы сертификации Active Directory (AD CS) выполнена успешно.

• Перевод

Как вы уже должны знать, поддержка Windows Server 2003 и Windows Server 2003 R2 заканчивается 14 июля 2015 года. Зная это, ИТ профессионалы либо уже провели миграцию, либо этот процесс должен находиться в самом разгаре. В этой статье будут описаны шаги, необходимые для миграции Active Directory Certificate Service с Windows Server 2003 на Windows Server 2012 R2.

Для демонстрации будут использованы следующие установки:

Шаг 1. Резервная копия конфигурации и базы данных центра сертификации Windows Server 2003

Шаг 2. Резервирование параметров реестра центра сертификации

Шаг 3. Удаление службы центра сертификации с Windows Server 2003

Шаг 4. Установка служб сертификации на Windows Server 2012 R2

Шаг 5. Настройка AD CS

Шаг 6. Восстановление зарезервированного CA

Шаг 7. Восстановление информации в реестре

Шаг 8. Перевыпуск шаблона сертификата

Шаг 9. Тестируем CA

На этом процесс миграции успешно завершен.

Друзья, столкнулся с интересной задачей — перенести центра сертификации Microsoft на новый сервер. Ну для начала мы должны понимать, что сама по себе инфраструктура открытых ключей просто так не разворачивается, следовательно уже есть выданные сертификаты и пред настроенные шаблоны. Причина, по которой может возникнуть необходимость миграции может быть много, от аппаратных проблем с сервером до переноса сервера в виртуальную среду.

Диспозиция:

Сервер Windows Server 2008 R2 c установленной ролью Active Directory Certificate Service и наличием аппаратных проблем)

Новый сервер Windows Server 2012 R2.

Перенос сервиса сертификации Active Directory на Windows Server 2012 R2.

Для начала подготовим резервную копию текущего центра сертификации. Для этого в оснастке Certificate Authority через

все задачи выбираем Архивация ЦС

Указываем архивирование всех элементов ЦС и путь для резервной копии

Для защиты закрытого ключа и файла сертификата центра сертификации указываем пароль

Архивация центра сертификации выполнена

Кроме базы данных центра сертификации Microsoft необходимо выгрузить и настройки, которые хранятся в реестре.

Для этого нужно выгрузить ветку

Итог должен выглядеть так:

После проведения подобных манипуляция можно остановить службу сервера сертификатов и в последствии удалить центр сертификации со старого сервера. Данный процесс описывать большого смысла не имеет. Идем дальше.

В промежуточном результате мы имеем экспортированную конфигурацию служба сертификатов Active Directory и желание его «реанимировать» на новом сервере.

Продолжим, установим cлужбу сертификатов Active Directory c необходимыми компонентами. Та этом вопросе останавливаться долго не будем, полагаю тут все просто:

Выбор необходимых ролей

Непосредственно процесс установки

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

Нажимаем «Настроить службы сертификатов Active Directory..»

В открывшемся окне выбираем учетную запись от имени которой будет производится настройка сервера. Роль должна входить в группу «Администраторы предприятия»

На следующем шаге указываем какие роли мы будем настраивать

В следующем окне выбираем “Корневой ЦС” в качестве типа ЦС и нажмите “ Далее” для продолжения.

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

На этом этапе указываем путь к выгруженному сертификату со старого центра сертификации и пароль указанный при экспорте к нему.

После импорта то мы увидим наш сертификат

На следующем этапе определяем путь к базе данных сертификата. Тут я оставил все как есть, по умолчанию. Далее.

Итоговая проверка всех указанных выше параметров для настройки

Процесс настройки завершен.

После настройки параметров ЦС, преступим у его восстановлению. На созданном сервере сертификатов выбираем «Восстановление ЦС»

Выбираем элементы, и указываем путь к папке в которую произведен экспорт

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

Восстановление завершено. Осталось только восстановить параметры, которые хранятся в реестре. Для этого как раз мы и экспортировали ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

Для импорта открываем фай и добавляем его в реестр. Появится предупреждающее окно. Нажмите “ Да ” для восстановления ключа реестра.

Осталось проверить работу нового центра сертификации. Как видим, все выданные сертификаты перенесены.

Новый Web сервер работает выдачи сертификатов работает.

Итог: Сервис сертификации Active Directory успешно перенесен на новый сервер, при этом как мы видели, произошла и миграции в рамках операционной системы 2008R2 -> 2012R2.

Работают в Windows еще с версии 2000. ADCS позволяют выдавать и обслуживать цифровые сертификаты на основе ключей.

Любой сертификат представляет собой пару закрытого и открытого ключа. Закрытый ключ – приватная информация, идентифицирующая владельца, требующая защиты и не подлежащая распространению. Открытый ключ – доступная любому часть, использующаяся для проверки

На практике сертификаты применяются для:

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

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

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

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

За 17 лет службы сертификации конечно же модернизировались. Последние серьезные изменения в ADCS были внесены в версиях Windows 2012 и 2012 R2 . Наиболее важные из них:

• Поддержка модуля политики для службы регистрации сертификатов для сетевых устройств
• Аттестация ключей доверенного платформенного модуля (TPM)
• Windows PowerShell для служб сертификатов
• Поддержка обновления сертификата с прежним ключом
• Поддержка международных имен доменов

Простейшая архитектура Certificate services состоит из 2х серверов: корневого и выдающего. Помимо этого в инфраструктуре наверняка присутствует домен-контроллер, который может быть использован, как точка распространения сертификатов. Также для этих целей желательно иметь сервер с ролью Web. В прочем этот функционал может быть настроен на сервере с ролью выдающего центра сертификации.

Для того, чтобы службы сертификации заработали в вашей инфраструктуре необходимо настроить:

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

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

Сертификаты, которыми подписаны центры сертификации, а также списки отозванных сертификатов имеют срок жизни, по истечении которого должны быть обновлены. Обновление CRL выдающего сервера происходит автоматически, в то время как обновление CRL корневого центра сертификации нужно проводить вручную (по умолчанию – раз в пол года). Для этого необходимо:

1. включить корневой центр сертификации
2. обновить CRL
3. опубликовать полученный CRL на всех точках проверки отозванных сертификатов.

После этого обычно выполняются другие процедуры обслуживания сервера. Такие как, установка обновлений и резервное копирование. После чего сервер выключается до следующего обновления CRL или другой потребности его запуска.

Все операции по управлению сервисом выполняются из нескольких консолей:

А также с помощью PowerShell и утилиты certutil, с возможностями которой можно ознакомится, набрав certutil /help в командной строке Windows.

В частности с помощью командной строки можно публиковать сертификаты и списки отозванных сертификатов в базе Active Directory. Также через службы Active Directory Domain Services (а именно через групповые политики) можно настроить распространение сертификатов: например, добавление сертификата корневого центра сертификации в Trusted certificates рабочих станций организации.

Помимо того, что сертификат содержит пару закрытого и открытого ключа, в нем также хранится служебная информация, в том числе о том, кому и когда выдан сертификат, алгоритмах генерации длине ключа и пр. Сертификат генерируется по шаблону, который должен быть опубликован уполномоченным администратором. По умолчанию Active Directory Certificate Services имеют набор заготовок шаблонов для различных сервисов (Web-server, Exchange server, RDP Gateway server и пр), на базе которых можно также создавать шаблоны под собственные нужды.

Как видно из скриншота сертификаты широко применяются для защиты информации и информационных каналов. Наиболее часто используются:

• Сертификаты для веб ресурса.
• Сертификаты для защиты соединения.
• Сертификаты для цифровой подписи.

Наша компания готова помочь в настройке и администрировании служб сертификации на базе Microsoft Windows 2016 и более ранних версий, а также в выполнении любых работ по защите веб ресурсов, соединений и данных с использованием сертификатов. Обращайтесь,

Нет похожих статей.