Настройка центра сертификации windows 2016
Обновлено: 08.07.2024
Понимание сертификатов это нечто, чего избегал долгие годы в своей технологической карьере. Для множества граней ИТ вы никогда не будете иметь с ними. Это было для сетевых парней, а не для кого- то, имеющего дело с разработкой или поддержкой рабочих мест. Времена изменились, и основательное понимание общих типов сертификатов быстро становится возможностью, которую любой в поддержке должен выполнять. Всё больше и больше безопасности начинает сосредоточиваться в сертификатах, а при экспоненциальном росте приложений, которые обслуживаются посредством Веб, понимание сертификатов, которые защищают такие службы является более важным, чем когда- либо.
Почти всякий, кто устанавливал некий веб- сайт имел дело с сертификатами SSL из общедоступного CA ( Certification Authority , Органа сертификации), но знаете ли вы, что вы можете быть собственным CA? Что вы можете выпускать сертификаты для машин в вашей сетевой среде прямо со своего собственного сервера CA? Следуя далее мы исследуем некоторые из возможностей Windows Server 2016, работающего в качестве сервера CAв вашей сети. Наша работа в данной главе охватит следующие темы:
Настройка самого первого сервера Certification Authority в сетевой среде
Построение Подчинённого сервера CA
Создание шаблона сертификата для подготовки выпуска сертификатов машин вашим клиентам
Публикация шаблона сертификата для возможности регистрации
Применение MMC для запроса нового сертификата
Применение веб- интерфейса для запроса нового сертификата
Настройка автоматической регистрации для выпуска сертификатов всем подключённым к домену системам
Обновление вашего корневого сертификата
Введение
Когда я получаю известие, что частью моего задания дня является новый пользователь или сеть, я обычно нахожу, что истиной будет одна из двух вещей. Либо у них нет никакого сервера CA, либо они имеют его, но совсем ни для чего не применяют. Большинство людей знают, что сертификаты понадобятся и востребованы, а также что постоянно выпускаются новые технологии, которые требуют довольно большого количества сертификатов. Такие технологии как Lync, SharePoint, System Center, DirectAccess или даже простое построение веб- сайта почти всегда требуют применения сертификата в сегодняшнем мире. Прыгнув в проект по размещению практически любой новой системы в эти дни быстро приводит вас к пониманию, что знание сертификатов становится обязательным. Даже места, в которых они не требуются, они обычно всё- таки рекомендуются чтобы иметь решение более безопасным или придерживающимся распространённой практики.
Совместными усилиями мы собираемся построить среду PKI ( Public Key Infrastructure , инфраструктуры общедоступных ключей) внутри нашей сетевой среды и применить её для некоторых распространённых задач выпуска сертификата. К концу данной главы вы должны лишиться напряжённости при создании PKI в вашей собственной среде, что подготовит вас к любым запросам с которыми вы можете встретиться при работе с технологиями, основанными на сертификатах.
Настройка первого сервера Сертификационной авторизации в сети
Самый первый барьер, который необходимо преодолеть когда вы хотите начать работу с сертификатами, состоит в помещении такого сервера на место. Существует множество справедливых вопросов на которые необходимо ответить. Нужен ли вам выделенный сервер для этой задачи? Мог ли я совмещать эту роль на существующем сервере? Нужно ли мне устанавливать Корпоративный (Enterprise) или автономного (stand-alone) CA (Органа сертификации)? Я слышал термин отключённого (offline) корня, но что он означает? Давайте начнём с основ и предположим, что вам нужно построить самый первый сервер CA в вашем окружении.
В сетевой среде домена AD наиболее полезными серверами CA является разновидность Корпоративных (Enterprise). Серверы корпоративного CA интегрированы с AD, что делает их видимыми для машин в такой сетевой среде и автоматически заслуживают доверие (trusted) у компьютеров, которые присоединены к данному домену. Существуют различные мнения по природе наилучшего использования при установке последовательностей серверов CA. Например, существует хорошее руководство тестовой лаборатории (ссылка на который приводится в конце данного рецепта), опубликованное Microsoft, которое проводит вас через настройку автономного (stand-alone) Корневого (Root) CA, Подчинённого Корпоративного (Subordinate Enterprise) CA, с последующим изъятием в выключенное состояние автономного корня (stand-alone root offline). Преимущество этого состоит в том, что сертификаты выпускаются из подчинённого CA, а не напрямую из корня и, тем самым, если ключи сертификата каким- то образом скомпрометированы в данном окружении, Корневой CA полностью отключён и недоступен с тем, чтобы быть скомпрометированным. В подобной ситуации вы можете вычистить Подчинённого и опубликованные им сертификаты, поднять отключённый Корень, построить нового Подчинённого и вернуться к делу публикации сертификатов без какой- бы то ни было повторной генерации нового сервера Корня CA.
С учётом предыдущего практического опыта, или как это определено тем или иным образом, удивительно, что я крайне редко вижу Корневой CA отключённым на практике. На самом деле, практически никогда. А в некоторых имевшихся у меня случаях наличие отключённого Корня CA вызывало проблемы. Просто для примера, при размещении инфраструктуры DirectAccess с возможностями одноразового пароля (OTP, one-time-password) в среде заказчика, было обнаружено, что чтобы заставить такие OTP работать правильно, отключённый Корень CA должен быть приведён назад в рабочее состояние. Это не было самым насущным интересом нашего варианта для создания PKI, и поэтому взамен мы реализовали вторую среду сертификата с автономным корнем и и двумя промежуточными чтобы поддерживать отключённым Корень CA для данной цели сертификатов OTP. Это вызвало большие задержки в нашем проекте, так как мы должны были построить три новых сервера, необходимых просто для получения публикации сертификатов правильным образом, что впоследствии привело к намного более сложной инфраструктуре сертификации.
Если предыдущее описание смутило вас, хорошо - так как это разновидность неаккуратной настройки. Если бы компания вместо этого работала с функционирующим сервером Корня CA в самом первом месте, никакая такая дополнительная работа не была бы нужна. Я не защищаю то, что Корпоративный Корень CA, который постоянно остаётся во включённом состоянии является наилучшим способом выдачи сертификатов, однако он вызывает наименьшее число проблем и существует множество компаний, которые работают в своих промышленных средах CA в точности таким образом.
Другое практическое наблюдение состоит в том, что большая часть компаний малого и среднего размера не выбирают подход с отключённым Корнем CA. На самом деле я обнаруживаю, что многие малые компании вынуждены совмещать серверы чтобы сберегать ресурсы и имеют свои CA роли установленными на серверы, которые также выполняют некоторые прочие задачи. Зачастую роль CA устанавливается в Контроллере домена. Хотя на поверхностном уровне рассмотрения это кажется не лишённым смысла, так как службы Корпоративного CA настолько тесно интегрируются с AD, в действительности это плохая мысль. Microsoft рекомендует чтобы вы никогда не совмещали роль CA в Контроллере домена, поэтому удерживайтесь в стороне от такого сценария по мере возможности. Как уже было сказано, я наблюдал десятки компаний, которые в точности делали это и никогда не имели с этим проблем, поэтому я предполагаю, что это просто ваш выбор насколько близко вы хотите придерживаться Пути Microsoft . Не забудьте ознакомиться со ссылками, приводимыми в конце данного рецепта, так как они снабдят вас информацией, которая будет полезна чтобы принять верное решение по поводу того какая настройка сервера сертификата наилучшим образом удовлетворяет вашей сетевой среде.
Подготовка
Я создал новый Windows Server 2016 с именем CA1 , причём он является участником домена, на котором мы будем включать нашу новую инфраструктуру сертификации.
В окне для указания имени ЦС введите значения всех полей и нажмите Далее.
Введите период действия сертификата для создаваемого ЦС.
Для добавления шаблонов сертификатов:
Выберите следующие настройки:
Для выписки сертификатов пользователю Administrator и обычным пользователям с помощью mmc-консоли:
Закройте окно Консоль1. Для сохранения консоли нажмите Да.
На этом настройка Центра Сертификации и выдача сертификатов пользователям завершена.
Пошаговая инструкция по установке и настройке центра сертификации
Одним из преимуществ ЛОЦМАН:ПГС является применение цифровых подписей достоверно подтверждающих личность и роль подписавшего документ. Для создания цифровых подписей необходимы сертификаты выданные удостоверяющим центром сертификации.
На этапе внедрения не всегда хватает опыта для установки и настройки центра сертификации, чтобы Вам не пришлось собирать крупицы информации по просторам интернета, мы предлагаем подробно рассмотреть установку и настройку центра сертификации.
В наших примерах мы будем использовать контроллер домена на Microsoft Windows Server 2008 и клиент Microsoft Windows 7.
9 комментариев
Сергей, спасибо большое. Очень нужная статья.
Но у всех есть (или будет в ближайшем будущем) квалифицированная электронная подпись на госуслугах или УЭК.
>>>>
Это хорошо! Проблем использования квалифицированных электронных подписей не возникало, если криптопровайдер совместим с Crypto API Windows.
Спасибо за статью ! Очень подробно расписано. Единственное , что я не понял это как добавить корневой сертификат созданный на ubuntu в Windows server 2008, что бы он считал его своим основным.
Денис, распространение сертификатов групповой политикой частично описано тут (начиная с цифры 6).
Спасибо конечно, но я о другом спросил. Я создал CA в Ubuntu такой какой мне надо, на server 2008 создаю роль центра сертификации и надо , указать ключ *.pfx уже созданный. но винда говорит , что не подходит.
Добрый день. Была попытка установки СА, удалил. Сейчас установил повторно, но сайт СА по адресу dc01/certsrv не работает. Мало того, в настройках ИСА только дефаулт сайт. Подскажите пожалуйста, что делать? Спасибо
Спасибо за статью- очень помогла. Всё понятно расписано. Выполнял описанные действия. В итоге всё работает.
Установка и настройка корневого центра сертификации (RootCA)
Следующий этап внедрения инфраструктуры открытых ключей – установка корневого удостоверяющего центра. Как правило это виртуальная машина, при этом ее не следует подключать к сети, поскольку это может создать потенциальный риск компрометации. Весь информационный обмен: перенос сертификатов и списков отзыва, передача запросов к центру сертификации и выданных сертификатов с него осуществляется с помощью внешнего защищенного носителя, доступ к которому ограничен доверенным кругом лиц.
Процедура самой установки службы сертификатов не отличается от установки любой другой роли Windows Server 2016, и знакома системному администратору. Добавляется новая роль – Active Directory Certificate Service. Перед установкой следует разместить файл capolicy.inf [1], содержимое которого мы обсуждали в предыдущей статье [3] в папке systemroot. См. рис. 1.
Это позволит нам выполнить начальную конфигурацию сервера сертификатов. В процессе установки сервиса, вернее будет сказать послеустановочной настройки см. рис. 2., потребуется задать учетную запись, от имени которой будет работать служба, тип развертывания – «Stand Alone CA», роль удостоверяющего центра – «RootCA».
Также будет необходимо создать новый частный ключ, указать требуемый криптоалгоритм и длину ключа, алгоритм хеширования, срок жизни сертификата. После этого может сложится впечатление, что настройка завершена, однако это не так. Дело в том, что многие параметры работы сервера сертификатов останутся в состоянии «по-умолчанию», что приведет к неверной работе. Так, например, точки публикации сертификатов (AIA) см. рис. 3 и списков отзыва (CDP) см. рис. 4, порядок их опроса не будут соответствовать нашим потребностям, параметры логирования не будут заданы вовсе.
AIA расшифровывается как Authority Information Access и определяет место хранение актуальных сертификатов нашего сервера. CDP – дает нам возможность определить место хранения списков отзывов, подписанных нашим сервером сертификатов. Оба эти расширения содержаться во всех выданных удостоверяющим центром сертификатах и, соответственно, должно быть доступны всем потребителям.
Получается, клиенты должны обладать возможностью проверять цепочку сертификатов и список отзыва, обращаясь по тем, которые указаны в сертификате, то есть определены в AIA и CDP расширениях при настройке. Если это сделать не получится, то сервисы, ради которых внедрялась инфраструктура открытых ключей будет неработоспособна. Например, вы хотели использовать сертификаты для аутентификации с помощью смарт карт, но пользователь не смог проверить список отзыва по заданному вами пути, в этом случае войти по смарт карте не выйдет.
Изменение этих настроек может быть выполнено разными способами. Может быть использован графический интерфейс (GUI), утилита certutil [4], с помощью которой можно полностью выполнять любые задачи из командной строки, наконец воспользоваться командлетами powershell.
Certutil.exe – программа командной строки, которая устанавливается как часть служб сертификации. Используется для сбора информации о конфигурации удостоверяющего центра, настройки служб сервиса, резервного копирования и восстановления компонентов ЦС и проверки сертификатов, пар ключей и цепочек сертификатов.
Стоит отметить, что у нас нет возможности частичной корректировки уже внесенной строки. Также невозможно изменить порядок следования строк. И, поскольку указанный по-умолчанию вариант в большинстве случаем не подходит, то ничего не остается, как только удалить эти строки полностью и внести новые значения, соответствующие требованиям. На этом этапе должны быть уже определены места хранения сертификатов и списков отзыва и подготовлен веб сервер, что уже обсуждалось в предыдущей статье [3].
Еще один важный момент – как выполнить эти настройки? Конечно, это может быть сделано «вручную» с помощью графического интерфейса, однако при таком способе вероятность ошибок из-за невнимательности возрастает, поэтому лучше будет воспользоваться заранее подготовленным и отлаженным скриптом, который и выполнит все необходимые модификации реестра и настроит CA.
Для настройки параметров CDP будем применять утилиту certutil и воспользуемся следующей командой:
с помощью, которой и назначим точки публикации CRL.
Определимся с тем, каких результатов нам требуется добиться.
Список отзыва сертификатов публикуется на самом сервере сертификатов в виде обычного файла с расширением CRL. Стало быть, надо указать папку, где будет этот файл храниться. Например, тот вариант, который предлагается по-умолчанию:
C:\Windows\system32\CertSrv\CertEnroll.
Он нам вполне подойдет. Следует понимать, что клиенты его получить не смогут, поскольку наш корневой сервер сертификатов для них недоступен. RootCA отключен от сети, да и вообще выключен. Значит файл его списка отзыва должен храниться где-то еще. То есть на сервере распространения – это наш веб сервер, который мы раньше установили. Нам придется его туда скопировать. Мы вернемся к вопросу переноса данных чуть позже в следующих статьях этого цикла.
Пусть все настроено и наши клиенты уже работают с сертификатами, например, пытаются подключиться по SSL.
Получив сертификат веб сервера при попытке установить соединение с ним, проверяется не отозван ли сам сертификат и сертификаты выдавшего центра сертификации, и всех удостоверяющих центров до корневого включительно и действительна ли цепочка сертификатов не устарели ли они.
Значит список отзыва RootCA должен быть включен в выданные им сертификаты.
Включим публикацию этих путей в сертификате. То есть получив сертификат, клиент точно будет знать куда идти для проверки. С дополнительными параметрами в этой команде можно познакомиться в статье [5].
Сам сертификат УЦ тоже должен где-то храниться, мы используем путь по-умолчанию: C:\Windows\system32\CertSrv\CertEnroll.
Настройку AIA выполним таким образом:
Для настройки срока действия сертификата и периодичности публикации CRL, если нам требуется изменить уже внесенные с помощью capolicy.inf значения, с помощью все той же утилиты certutil делается нижеследующее:
certutil -setreg CA\ValidityPeriodUnits 20
certutil -setreg CA\ValidityPeriod “Years”
certutil -setreg CA\CRLPeriodUnits 26
certutil -setreg CA\CRLPeriod “Weeks”
certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod “Weeks”
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod “Hours”
Последовательно здесь настраиваются:
- Период действия сертификата центра сертификации
- Единицы измерения для ValidityPeriodUnits
- Периодичность выпуска списков CRL и Delta CRL, а также срок продленного действия списков CRL
Последнее, что осталось сделать – настроить аудит.
certutil -setreg CA\AuditFilter 127
Наконец, для определения значения переменной %6 -<ConfigurationContainer> выполните следующую команду:
certutil -setreg ca\DSConfigDN “CN=Configuration,DC=nwtraders,DC= msft”
Читайте также: