Глава 4. работа с сертификатами – windows server 2021 книга рецептов.
Когда я получаю известие, что частью моего задания дня является новый пользователь или сеть, я обычно нахожу,
что истиной будет одна из двух вещей. Либо у них нет никакого сервера 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 2021 с именем CA1,
причём он является участником домена, на котором мы будем включать нашу новую инфраструктуру сертификации.
Чтобы установить Службы сертификации AD (Active Directory Certificate Services) на вашем Server 2021,
воспользуйтесь следующим набором инструкций:
Откройте Диспетчер сервера и кликните ссылку
Add roles and features.Пройдите шаги, выбрав настройки по умолчанию. Когда вы дойдёте до экрана
Server Roles, выберите
Active Directory Certificate Services.В процессе выбора этой роли вы будете запрошены подтвердить установку дополнительных функций.
Пройдите далее и кликните Add Features.Пару раз кликните Next пока не достигните
экрана Role Services. В нём вы увидите несколько
различных вариантов которые могут быть применены для вашего сервера CA. Так как мы хотели бы иметь
возможность запрашивать сертификаты через веб- интерфейс в этом CA, я собираюсь отметить дополнительный
блок для Certification Authority Web Enrollment.
После выбора этого блока, вы получите дополнительный всплывающий блок, запрашивающий вас добавить свойства.
Проверьте что разрешили эти свойства для установки.Кликните Next по оставшимся экранам пока не
достигните смой последней страницы, в которой кликните кнопку
Install для начала установки этой роли.Когда она завершится, вы увидите ссылку внутри итогового окна установки, которое сообщит
Configure Active Directory Certificate Services on the
destination server (Настройте Службы сертификации AD на сервере назначения). Вы можете
кликнуть либо на эту ссылку, либо на уведомление маркера жёлтого восклицания Диспетчера сервера рядом
с верхней частью экрана самого Диспетчера сервера чтобы продолжить настройку роли CA. На первом экране
настроек, мастер вероятно вставит автоматически имя пользователя зарегистрированного в настоящее время
пользователя. Как следует из текста на этом экране, убедитесь что пользователь, с которым вы
зарегистрировались, имеет права администратора Корпорации (Enterprise Admin) для данного домена, так как
мы планируем установить этот сервер CA в качестве Корпоративного Корня CA.Для раскрутки служб сертификации на нашем сервере пройдите далее и пометьте два верхних параметра для настройки
Certification Authority and Certification Authority Web
Enrollment.Выберите Enterprise CA.
Выберите Root CA; так как это наш первый сервер
CA, нам нужно реализовать корень до того, как мы сможем думать об субординации.Выберите Create a new private key (Создать
новый частный ключ).В экране Cryptography вы имеете возможность
выбрать вариант криптографии, который вы можете предоставить вашему серверу CA. Обычно, если вы не уверены в
этих параметрах, опции по умолчанию являются наилучшим выбором. Только убедитесь, что ваше поле
Key length установлено, как минимум, в значение
2048. Это новый стандарт отрасли для минимальной
длины ключа. Аналогично, стандарт хэширования должен соответственно измениться на SHA256, на самом деле, вы не
должны более применять SHA1 ни для каких своих сертификатов, поскольку в настоящее время существует оценка, что
SHA1 может быть скомпрометирован в следующие пару лет.Если пожелаете, вы можете изменить свои Common name for this
CA. Имейте в виду, что оно не должно соответствовать каким либо образом имени хоста. Это имя
вашего CA, кторое будет показываться внутри Active Directory, а также внутри сертификатов, которые вы
выпускаете из этого CA. Обычно я вижу, что администраторы оставляют только
Distinguished name suffix (Суффикс отличительного
имени).Измените Validity Period
(период действия) вашего сертификата корня, если пожелаете. Часто администраторы проскакивают через это окно и
оставляют значение по умолчанию пять лет, однако это означает, что всего через пять коротких лет у вас внезапно
станут несостоятельными все отдельные сертификаты которые только были выпущены из этого сервера CA. Я рекомендую
это значение до 10, или даже до 20 лет, с тем, чтобы вы не беспокоились об этом истечении этого уровня сертификации
длительное время. Период действия определяет как часто должен обновляться сертификат корня.Продолжите идти по оставшимся окнам, оставляя на месте установленные значения по умолчанию. Когда этот
мастер завершится, ваш сервер CA теперь оживёт.обычно хорошей мыслью является перезагрузка данного сервера после установки столь значительной роли.
Пройдите далее и перезагрузитесь как только позволит время.
В данном рецепте мы установили самый первы сервер CA в нашу сетевую среду. Как мы уже обсуждали,
вам следует прочесть некоторые приводимые ниже ссылки для того, чтобы помочь с определением сколько CA
вам требуется, и где они должны быть установлены. Это тот ответ, который может быть различным для каждой
организации и поэтому я не делаю неких всеобъемлющих утверждений здесь, которые будут применимы для любого.
Вы можете решить, что ваш первичный Корень CA должен быть Автономным, а не Корпоративным, и это будет
прекрасно пока оно соответствует вашим потребностям. Мы также установили фрагмент веб служб этой роли
на нашем первичном CA, так как мы планируем применять это в последующих рецептах по выпуску сертификатов.
Если вы построите некую среду со множеством серверов CA, вы можете определить что ваша авторизация корня
не нуждается в веб интерфейсе… возможно только определённый подчинённый CA будет выполнять это задание
для вас. Существует множество вариантов которым может выступать наш проект, однако на протяжении этого
рецепта, я надеюсь что предоставлено достаточно информации с тем, чтобы вы не испытывали проблем с реальным
процессом когда это решение было принято.
Существует пара моментов, которые не были охвачены в данном рецепте и которые следует отметить.
Следование приведённым шагам приведёт ваш сервер CA в запущенное и рабочее состояние, которое будет готово
к выпуску сертификатов, это несомненно так. Остальные рецепты в данной главе отражают построение CA
в точности как показано здесь. Однако, существуют дополнительные шаги, которые могут быть предприняты
чтобы и далее персонализировать ваши настройки CA если вам это нужно. Если вы планируете выпускать
сертификат SSL для вебсайтов, в особенности, если вы планируете устанавливать эти сертификаты на веб серверы,
повёрнутые в сторону всемирного Интернета, тогда вам необходимо ознакомиться с настройками
CRL
(Certificate Revocation List, Списка отозванных сертификатов). При каждом доступе к сертификату компьютер клиента
проверяется в CRL чтобы гарантировать, что данный сертификат всё ещё действует. Если сертификат не действительный,
или мошеннический в каком- либо виде, проверка CRL определит эту скомпрометированность и запретит
такое соединение. В частности, при публикации вебсайтов в Интернет, которые применяют сертификаты,
выпускаемые вашим внутренним PKI, вам придётся планировать публикацию вашего CRL с тем, чтобы компьютеры
внешних клиентов могли осуществлять к нему доступ свободным, безопасным образом. Вот прекрасная ссылка,
с которой вы можете начать изучать информацию CRL: http://technet.microsoft.com/en-us/library/cc771079.aspx.
Второй фрагмент информации, которую я бы хотел отметить это файл CAPolicy.inf.
Именно этот файл можно заполнять различными персональными настройками для вашего сервера CA, такими как
период действия вашего корневого сертификата, информация об CRL, а также хотите вы или нет чтобы
шаблоны сертификатов по умолчанию загружались в процессе установки роли CA. Если какие- либо из этих настроек
представляют для вас интерес, вы просто создаёте файл CAPolicy.inf
с соответствующими настройками и помещаете вовнутрь C:Windows
в вашем сервере CA перед установкой роли. Мастер установки роли затем применит эти настройки внутри данного
файла в процессе установки роли и присоединит ваши персональные установки. Если вы не применяете один из этих файлов,
это неплохо, и ваша роль будет установлена с некоторыми настройками по умолчанию на своих местах, в точности как
это имело место в данном рецепте. Однако, если вы заинтересованы в изменении некоторых из них,
ознакомьтесь с данной ссылкой для получения дополнительной информации по файлу
CAPolicy.inf:
http://technet.microsoft.com/en-us/library/jj125373.aspx.
Никакие из этих элементов, ни настройка CRL, ни использование файла CAPolicy.inf
не являются обязательными для того чтобы среда сертификации поднялась и заработала. Таким образом, они не не
включены в пошаговую настройку самого данного рецепта. Однако я всегда счастлив иметь все доступные мне знания
по определённому предмету и поэтому я настоятельно рекомендую вам прочитать эти дополнительные ссылки,
предоставляющие совершенство вашему пониманию возможной функциональности.
Вот ещё некоторые ссылки, которые послужат хорошим дополнением для чтения по данному предмету. Чтобы
сделать осмысленное решение о правильной последовательности серверов CA для вашей среды, я советую вам
по возможности ознакомиться с данным предметом перед промышленным выполнением вашей сетевой среды:
В действительности мы строим Подчинённый (Subordinate) CA не с целью избыточности, как это имеет
место для многих прочих видов серверов, а потому что существует множество особенных задач, которые вы
можете пожелать выполнить в Подчинённом CA, в отличие от Корня (Root) CA. Если вы выпускаете большое число
сертификатов или различные виды сертификатов, вы можете захотеть установить различие между серверами CA при выпуске.
Возможно, вы пожелаете, чтобы машины, которые применяются для сертификатов IPsec выпускались из
IPSEC-CA, в то время как выпускаемые вами
SSL сертификаты вебсайта должны быть представляться с WEB-CA.
Вместо того, чтобы строить два независимых Корня CA, которые оба имели бы права верхнего уровня, вы должны рассмотреть
создание отдельного Корня CA, возможно, с именем ROOT-CA
и поместить эти два сервера CA в подчинённую роль под такой Корень CA в цепочку. Это может быть также полезно для географически
распределённых сетевых сред, имеющих Подчинённые серверы CA, выделенные для назначения сертификатов различным
офисам или регионам.
Как мы уже обсуждали в предыдущем рецепте, несомненно существуют наилучшие практические стандарты, которые
могли бы предложить вам применять только Подчинённые CA для выполнения ваших выпусков сертификатов.
Я не всегда нахожу это приемлемым для компаний, в особенности малых размеров, однако будет хорошей
мыслью если вы можете разворачивать их. При находящихся в работе Подчинённых сервера CA вы имеете возможность
выведения своего Корня CA в выключенное состояние и использовать только Подчинённые для выпуска всех ваших
сертификатов.
Мы находимся внутри сетевого домена и имеем поднятым и работающим отдельный Корпоративный Корень
(Enterprise Root) CA. Теперь нам требуется некий дополнительный сервер, который будет присоединён к
нашей среде CA в качестве нового Подчинённого (Subordinate) CA.
Для реализации нашего нового Подчинённого сервера CA, процесс будет очень похож на изложенный в рецепте
Настройка первого сервера Сертификационной авторизации в
сети. Однако, существует ряд ключевых различий, и именно на них мы сосредоточим своё внимание.
Некоторые из этих специфичных шагов могут быть сокращены здесь; воспользуйтесь, пожалуйста предыдущим рецептом для более подробной информации по этим особым
шагам и настройкам относительно их устанавливаемой роли:
Зарегистрируйтесь на вашем новом сервере, который уже подключён к домену.
Следуйте шагам для добавления роли Служб Сертификации AD (AD CS) к этому серверу.
Когда мы реализовали свой сервер Корня CA, мы также выбрали установку веб служб. Это позволит нам
запрашивать и выпускать сертификаты через какой- либо браузер внутри нашей сетевой среды
{Прим. пер.: или применяя RESTfull службы}. У вас имеются опции установки этих веб служб в вашем новом
Подчинённом CA, которые вы определённо должны бы выполнить, если планируете применение отключения Корня CA,
однако для нашего случая мы не собираемся делать этого. Мы оставим только
Certification Authority в нашем перечне доступных
роли служб.После завершения установки выбранной роли, пройдите далее и кликните
Configure Active Directory Certificate Services on the
destination server (Настройка Служб сертификации AD на сервере назначения).В случае необходимости введите полномочия и выберите только единственную опцию, которую мы должны
перечислить для настройки, Certificate Authority.Это именно то место, с которого мы должны начать сворачивать с пути, который мы выбирали при создания
Корня CA. Мы всё ещё выбираем настройку Enterprise CA,
так как мы всё ещё желаем его интеграции с доменом.Однако, вместо выбора установки нового Корня CA мы собираемся выбрать опции для
Subordinate CA (Подчинённого CA).
На самом деле, он уже был выбран для нас по умолчанию, так как он распознал что Корень CA уже присутствует в
нашей сетевой среде. Мы можем установить другой Корень CA, однако это не является нашей целью в
данном рецепте.Выберите Create a new private key.
Единственный раз, в который мы обычно захотим воспользоваться существующим частным ключом это когда мы
перестраиваем некий сервер CA.Выберите настройки криптографии. Они обычно выбираются теми же самыми, что и настроенные вами для
Корня CA.Присвойте имя своему новый Подчинённый CA. Если у вас имеется некая определённая функция на уме для этого
CA, вам на будущее определить имя в соответствии с нею. Например, я собираюсь использовать данный
Подчинённый CA для выпуска всех своих SSL сертификатов, которые мне понадобятся для внутренних вебстраниц,
таким образом, я должен включить в состав имениSSL.Теперь мы переходим к новому экрану. Нам необходимо получить некий сертификат от нашего родительского сервера
CA чтобы выпускать сертификаты из этого нового. Выберите параметр
Send a certificate request to a parent CA,
(Отправить запрос на сертификат родительскому CA), а затем воспользуйтесь кнопкой
Select… для выбора вашего Корня CA.На вашем следующем экране отрегулируйте местоположение его файлов сертификационной базы данных, если
это необходимо; в противном случае кликните Next,
а затем Configure.
Установка Подчинённого (Subordinate) сервера CA в сетевой среде очень похожа на реализацию нашего первого
сервера Корня CA. В нашем случае, мы упростили свою установку, не выбрав требований для веб служб для работы в
таком Подчинённом CA, мы будем выполнять все такие запросы из Корня CA. Теперь у нас имеется работающий
Корень CA и Подчинённый CA, работающий под ним. Для нашей другой установки мы собираемся оставить оба
включёнными и работающими, поскольку мы собираемся выпускать сертификаты с обоих. Мы легко можем пройти через
тот же самый процесс снова с другим новым сервером чтобы создать другой Подчинённый CA, возможно, для выпуска
другого вида сертификата или для использования другим подразделением вашей компании.
Рецепт Настройка первого сервера Сертификационной авторизации в
сети
Данный рецепт является первым барьером, с которым могут столкнуться многие администраторы сертификации.
Вы можете иметь сервер CA запущенным и работающим, но что дальше? Перед тем как вы начнёте предоставлять
сертификаты компьютерам и пользователям, вам необходимо установить шаблоны сертификатов, которые вы собираетесь
публиковать. Теперь вы должны настроить эти шаблоны с определёнными настройками, а когда некий сертификат
запрашивается для этого шаблона, тогда новый сертификат будет строиться на основе имеющейся в шаблоне
информации в комбинации с информацией, производимой запрашивающим этот сертификат.
Существуют некоторые встроенные шаблоны сертификата, которые предварительно устанавливаются когда вы
добавляете данную роль CA в свой сервер. Некоторые компании применяют эти встроенные шаблоны для выпуска
сертификатов, однако с практической точки зрения лучше создать свои собственные шаблоны. Это не требует
начала с нуля, однако. Вы можете взять один из встроенных шаблонов, причём найти тот, который наилучшим
образом соответствует вашим потребностям, и выполнить его подстройку, чтобы выполнить ваши предложения
с вашими особыми потребностями сертификата. Именно этот процесс мы и собираемся обсудить. Нам нужно выпустить
сертификат машины для каждой нашей системы в сетевой среде для аутентификации некоторых IPsec туннелей.
Существует несколько критериев, которым мы должны соответствовать в данных сертификатах, и встроенные шаблоны
Computer близки для соответствия всем нужным нам параметрам. Поэтому мы возьмём такой шаблон, скопируем его и
изменим чтобы соответствовать нашим требованиям.
Имеется среда домена Server 2021 с новым работающим сервером CA. Мы воспользуемся консолью CA в своём
сервере CA чтобы сейчас выполнить эту работу. Новый шаблон, который мы создадим, будет автоматически
реплицироваться для других серверов CA в нашем домене.
Следующие шаги помогут вам построить новый шаблон сертификата:
Запустите инструментарий управления Certification Authority
изнутри Диспетчера сервера.Раскройте имя вашего CA и кликните Certificate Templates.
Вы увидите список доступных вам встроенных сертификатов.Кликните правой кнопкой по Certificate Templates
и выберите Manage.Кликните правой кнопкой по имеющемуся шаблону
Computer и выберите
Duplicate Template.Теперь мы отрегулируем параметры внутри этого шаблона сертификата. Вы устанавливаете здесь в данных свойствах
шаблона все атрибуты, которые должен иметь ваш сертификат. В качестве примера, давайте настроим в качестве
действующих несколько элементов, которые должны содержать наши новые сертификаты IPsec.Перейдите в закладку General и установите
Template display name (Отображаемое имя шаблона)
с тем, чтобы вы могли определять такой новый выстраиваемый нами шаблон.В той же самой закладке отрегулируйте поле
Validity period (Период действия) на
2 года.Проследуйте в закладку Subject Name
и установите Common name для поля
Subject name format.
Это вызовет то, что имя предмета сертификата будет отображать имя хоста того компьютера, который запрашивает
данный сертификат. Использование имени DNS в качестве альтернативного имени предмета является другим
требованием, которое мы предоставим своему новому сертификату. Вы можете увидеть его отмеченным в нашем
снимке экрана внизу. Так как мы применяем встроенный шаблон Computer в качестве нашей отправной точки,
этот флаговый блок, а также прочие требования, которые необходимо охватывать, уже предоставлены нам.Кликните OK. Теперь в нашем перечне имеется
новый именованный сертификат с названиемIPsec Certificate
(или какое- либо иное предпочитаемое вами имя).
При установке любой новой технологии, которой необходим выпуск сертификатов, вашей первой остановкой
должны быть шаблоны сертификатов на вашем сервере CA. Вам необходимо удостовериться, что у вас имеется
шаблон, настроенный с соответствующими установками и переключателями, которые нужны вам в ваших новых
сертификатах. Продублировав один из встроенных сертификатов, которые поставляются с вашим сервером CA, мы
стали в состоянии построить новый шаблон без необходимости настраивать каждый отдельный параметр с нуля.
Одна из наиболее распространённых задач поиска неисправностей, которую я встречал, состоит в обнаружении
того, почему определённый шаблон сертификата не доступен, когда пользователь или компьютер пытаются запросить
некий сертификат. Наличие созданного нового шаблона сертификата не обязательно означает, что вы готовы начать выпуск
сертификатов на основе этого шаблона. Нам также необходимо опубликовать наш новый шаблон с тем, чтобы данный
сервер CA знал, что он готов публикацию для компьютеров и пользователей. Также существует раздел безопасности
свойств шаблонов, в котором нам необходимо определить кто или что могут иметь доступ или запрашивать сертификаты
на основе такого шаблона. В данном рецепте мы найдём эти настройки и сконфигурируем наш новый шаблон
сертификата так, чтобы любая подключённая к домену рабочая станция имела возможность запрашивать некий сертификат
у нашего нового шаблона.
Мы собираемся воспользоваться нашей машиной Windows Server 2021, которая является нашим Корпоративным
Корнем (Enterprise Root) CA.
Чтобы выпускать сертификаты на основе некоторого определённого шаблона, нам необходимо выполнить шаги
для публикации и отрегулировать свойства безопасности этого шаблона:
Новый шаблон сертификата не делает нам ничего полезного без пары дополнительных шагов для публикации
такого шаблона. Нам нужно пройтись через процесс определения нашего нового шаблона, который будет
публиковаться, что является достаточно простой опцией для выполнения, однако которая не является
видимой сразу внутри вашей консоли управления CA. Кроме того нам необходимо убедиться, что те полномочия,
которые мы установили на свой шаблон сертификата выстроены с целью для которой предназначен наш сертификат.
Если учётные записи ваших пользователей собираются запрашивать сертификаты, тогда вам необходимо
добавить пользователей или группы пользователей и предоставить им полномочия регистрации (enroll).
Если учётные записи компьютера собираются выступать в роли выполняющих такие запросы, тогда убедитесь,
что соответствующие группы также введены туда с правами регистрации (enroll).
Наиболее распространённый способ, который я наблюдаю в качестве взаимодействия администраторов со всеми
сертификатами в их системах состоит в инструменте оснастки MMC.
MMC является сокращением
(Microsoft Management Console, Консоль управления
Microsoft), а применяя MMC вы можете выполнять администрирование практически всем в своей операционной системе.
Хотя возможно это чрезвычайно незаслуженно обходимый вниманием инструмент, я обычно вижу его открытым для
некоторых избранных задач. Запрос сертификатов является одной из таких задач.
Мы собираемся применять консоль MMC в своём новом сервере, который имеется в нашей сетевой среде.
Существует новый шаблон сертификата, который мы создали, а также мы бы хотели выпустить один из этих
сертификатов для нашего нового веб- сервера.
Сервер Корпоративного Корня (Enterprise Root) CA, Server 2021, запущен и работает в нашей сетевой среде.
На нём мы должны настроить новый шаблон сертификата с названием IPsec Certificate.
Необходимо выполнить шаги для публикации этого шаблона с тем, чтобы его можно было запрашивать с компьютеров
в нашей сетевой среде. Теперь мы работаем с нового именованного веб сервера, который также исполняется под
Server 2021 и присоединён к нашему домену, где мы собираемся выполнить необходимую работу запроса вручную
некоторого сертификата со своего сервера CA.
Для запроса нового сертификата при помощи консоли MMC выполните следующие шаги:
Применение консоли MMC является быстрым и простым способом запроса нового сертификата, выпускаемого
вручную. В любой среде Active Directory будет доступен для просмотра и регистрации любой шаблон сертификата
на вашем сервере CA, на который у вас имеются полномочия для регистрации (enroll). Наш сегодняшний пример
отображает процесс регистрации для сертификата машины, который мы планируем применять в будущем для
аутентификации IPsec. Однако, существует множество вариантов использования, при которых вы можете
пожелать выпуск сертификатов уровня пользователя вместо сертификатов компьютера. В этих случаях вам
понадобится оснастка сертификатов учётных записей Пользователя в том месте нашего примера, где мы
определяем сертификаты учётных записей компьютера.
Иногда при запросе нового сертификата вы можете не иметь доступа для запроса к службам сертификатов напрямую
с использованием инструментов, аналогичных оснасткам MMC. Или, вероятно, вы желаете предоставить пользователю
способ иметь возможность запрашивать сертификаты даже когда он находится вне офиса. Разрешая фрагмент веб служб в
его роли CA, мы включаем веб сайт, который работает на нашем сервере CA. К такому веб сайту можно осуществить
доступ изнутри сетевой среды предприятия и он может даже потенциально быть опубликован во всемирном Интернете
при помощи некоторого вида решения с Обратным прокси.
Для нашего текущего рецепта давайте осуществим доступ к такому веб интерфейсу, который в настоящее время
работает на вашем сервере CA, на котором мы установили часть веб службы нашей роли CA. Мы воспользуемся этим
веб сайтом для запроса и получения сертификата для своего клиентского компьютера.
Нашим Корпоративным Корнем (Enterprise Root) CA является Windows Server 2021, который имеет установленную
роль Служб Сертификации AD (Active Directory Certificate Services). Когда мы установили и настроили эту роль,
мы проверили, что выбрали опцию для веб служб с тем, чтобы применять её для запроса нового сертификата.
Мы не обязаны быть зарегистрированы напрямую в сервере CA для выполнения данной работы. Вместо этого мы
регистрируемся в некотором новом веб сервере в нашей среде. Находясь в таком веб сервере мы выполняем
следующие шаги:
Откройте Internet Explorer и перейдите на
https://<CAServerName>/CertSrv/.
В нашем случае этоhttps://CA1/CertSrv/.Кликните Request a certificate.
Вы увидите предварительное построение запроса здесь для получения некоторого сертификата пользователя.
Если всё дело только в нём, вы просто кликните на эту ссылку, а затем кликните
Submit в следующем экране.
Однако, чтобы погрузиться слегка больше в наш рецепт, мы собираемся запросить некий сертификат SSL, а не
простой сертификат пользователя. Для начала этого процесса кликните на
advanced certificate request.Выберите Create and submit a request to this
CA (Выбрать и представить запрос к данному CA).Кликните Yes если получите следующее
сообщение:Выберите Certificate Template, котрый вы
хотите применить чтобы осуществить свой запрос сертификата. В моём Корне CA, в котором установлены
соответствующие веб службы, я настроил новый шаблон, который я продублировал из шаблона Web Server с
моими специфическими требования к сертификату. Я назвал этот шаблон
Custom Web Server
и опубликовал его для доступа в своём окружении.Так как это сертификат SSL, я обязан заполнить обычно запрашиваемую информацию. Здесь вводятся имя моего
веб сайта и контакты компании.Оставшиеся доступные для изменения опции уже настроены так, как мне нужно. Это происходит по той причине,
что когда я настраивал свой шаблон Custom Web Server,
я уже определил все эти элементы значениями по умолчанию. Вот мой запрос:Кликните Submit.
Ваш браузер покрутится минутку, пока ваш сервер CA создаст соответствующий новый сертификат основанный на
введённой вами информации. Когда он завершит свою работу, вы должны будете иметь некую ссылку для нажатия
Install this certificate. Пройдите далее и
нажмите на эту ссылку.
Выполнение веб службы на вашем сервере CA может давать преимущества, потому что позволяет другой метод
запроса сертификатов. В данном рецепте мы смогли очень быстро выкатить свою запрашиваемую страницу
сертификата CA и пройти по ней некоторые простые шаги. Это позволило нам загрузить новый сертификат,
который мы планируем применять со своим новым веб сервером сайта SharePoint.
Так как наш веб сервер находится внутри корпоративной сетевой среды, мы могли бы также выполнить этот
запрос напрямую из консоли Сертификатов MMC. Однако, если наш веб сайт находился в другом здании, отделённом
сетевым оборудованием и межсетевыми экранами, это могло бы не оказаться приемлемым вариантом для нас. Или,
если бы мы попытались получить некий сертификат из другой машины, которая не обладает доступом MMC по той
или иной причине, такая веб служба является прекрасным способом для выполнения той же самой задачи.
Множество новых технологий требуют применения сертификатов для аутентификации, запрашивая такие сертификаты для
распространения в больших масштабах. Например, если мы хотим применять подобную сертификацию Компьютеров для
аутентификации DirectAccess, нам необходимо выпускать некий сертификат для каждого клиентского компьютера
DirectAccess. Это могут быть тысячи ноутбуком в нашей сетевой среде. Если мы желаем начать шифровать обмен
внутри своей сетевой среды при помощи IPsec и требовать распространения сертификатов для этой цели, вам
потенциально понадобится выпустить некий вид сертификационной машины для каждого компьютера внутри вашей
сетевой среды. Хотя вы, несомненно, можете выдавать каждый сертификат вручную с применением консоли MMC или
через веб интерфейс CA, это не звучит как нечто, доставляющее удовольствие.
Введите Autoenrollment. Мы можем включить эту
функциональность, которая является неким видом зеркального отражения коммутации в Active Directory, и сделав это
мы можем запросить AD автоматически выпускать сертификаты для своих компьютеров, даже если нам нужно получать их
для каждого отдельного домена присоединённого к вашей системе. Давайте совместно пройдём этот рецепт чтобы
включить данную опцию и проверить её.
Мы работаем внутри некоего Windows Server 2021 на основе домена Active Directory. У нас также имеется
Корпоративный Корень (Enterprise Root) CA Server 2021, работающий в данной сети. Работа, которую мы будем
выполнять состоит в комбинации работы с вашим сервером CA и работой внутри Групповой политики в Контроллере
Домена.
Чтобы включить в вашем домене Autoenrollment (Автоматическую регистрацию), просмотрите следующие
инструкции:
Зарегистрируйтесь на своём сервере CA и откройте
Certification Authority.
Раскройте имя вашего CA, затем кликните правой кнопкой по
Certificate Templates и выберите
Manage.Теперь выберите какой шаблон сертификата вы хотите настроить для Автоматической регистрации. У меня имеется
шаблон с названием DA Cert., который я хочу
выпускать для каждого компьютера в своей сетевой среде. Кликните правой кнопкой по
DA Cert и пройдите в
Properties.Кликните закладку Security.
В ней вы должны настроить некие пользователей, компьютеры, или прочие объекты, для которых вы
хотите иметь полномочия Autoenroll в данном шаблоне. Я собираюсь AllowAutoenroll полномочия для всех
Domain Computers в
своей сетевой среде, как это показано на следующем снимке экрана:Кликните OK, и теперь вам необходимо
проследоватиь к Групповой политике (Group Policy). Зарегистрируйтесь в Контроллере домена и откройте
Group Policy Management Console.Я создал новую GPO для задач с названием
Certificate Autoenrollment Policy.
Эта новая GPO присоединена к вершине моего домена с тем, чтобы она применялась ко всем машинам, которые
подключены к домену. Если вам не нужна настолько широкая политика, конечно, вы могли бы урезать
доступ сюда ограничив эту ссылку или выполняя фильтрацию связанную с вашей GPO.
{Прим. пер.: советуем также вспомнить про Предварительная подготовка учётной записи компьютера в Active Directory,
позволяющую заблаговременно устранять создаваемый объект от применения такой Групповой политики.}Кликните правой кнопкой по GPO
Certificate Autoenrollment Policy и выберите
Edit….Переместитесь в Computer Configuration | Policies |
Windows Settings | Security Settings |Public Key Policies.Кликните дважды по Certificate Services Client – Auto-Enrollment.
Установите его в Enabled и выберите оба
флаговых блока в данном экране.Как только вы кликните OK, данная новая GPO
вступит в действие . Машины будут проверяться на данную Групповую политику и осознавать, что им необходимы
новые настройки от этой GPO. После ввода этого нового параметра на его место, все компьютеры будут затем
регистрироваться в сервере CA и запрашивать его для копии некоторого сертификата для которого у них
имеются полномочия Автоматической регистрации. Поскольку мы выполнили настройки таким образом, что все
Компьютеры в домене должны выполнять Автоматическую регистрацию с нашим шаблоном
DA Cert, наши рабочие станции и
сервера должны немедленно начать получать копии таких новых сертификатов. Вот снимок экрана из моего сервера
CA всего лишь через несколько минут после настройки данной GPO. Вы можете увидеть что она начала выпускать
сертификаты для моих подключённых к домену систем:
Мы применили Групповую политику чтобы перебросить свою Автоматическую регистрацию во включённое
состояние и немедленно запустили Автоматическую регистрацию сертификатов для своих подключённых к
домену систем. Существует пара различных способов, которыми может регулироваться Автоматическая
регистрация. Вы можете решать кто получает политику Автоматической регистрации применяя к ним
Групповую политику с привязыванием и фильтрацией в том смысле, что вы можете определять в самих
свойствах GPO какие пользователи или компьютеры предполагаются быть объектами для Автоматической регистрации
в этом первом месте. В качестве альтернативы, либо же в дополнение, вы можете также определять
полномочия внутри каждого шаблона сертификата в своём сервере CA с тем, чтобы вы могли лучше определять
какие пользователи или компьютеры в вашей среде будут получать копии каждого шаблона, после того как
Автоматическая регистрация включена.
Для данной задачи существенно планирование. Вам необходимо построить ясные определения для того,
какие сертификаты вам нужно публиковать, а также для каких устройств или людей вам нужно накатывать
сам этот сертификат. Если будете неверно выполнять последовательность это может не работать или,
что ещё хуже, вы можете закончить с выпуском тысяч сертификатов всем в вашей сетевой среде, которые
вы и не собирались распространять. Групповая политика чрезвычайно мощна, а перехват этой силы
приводит к значительной ответственности.
После настройки этих установок, если вы перезагрузите несколько подключённых к домену машинв своей
сетевой среде, вы заметите, что когда они вернутся назад в рабочее состояние, будут присутствовать новые
сертификаты, расположенные в хранилище персональных сертификатов компьютеров. Присядьте и подождите
несколько часов, и они накатятся на всех автоматически. Если вам не нравится ожидать обновления
Групповой политики, вы можете открыть приглашение командной строки в одном из этих компьютеров и выполнить
команду gpupdate /force для обновления политик вручную и установки
на место данного сертификата.
Помните, какое-то время тому назад, мы настраивали
самый первый сервер CA, а именно Корпоративный Корень (Enterprise Root)? Мы оставили многие из параметров на
их местах со значениями по умолчанию, и это означало, что наш сертификат корня устанавливался автоматически
с периодом действия в пять лет. Это выглядит достаточно продолжительным сроком, однако пять лет могут
пролететь за миг, в особенности если у вас есть дети. итак, что же случится когда сертификат корня наконец
истечёт? Случатся плохие вещи. Несомненно, вы захотите отследить дату истечения срока вашего корневого
сертификата и поторопиться обновить его до того, как закончится срок действия!
Мы только что построили такой новый сервер CA, поэтому мы не беспокоимся об истечении срока действия нашего
сертификата корня, во всяком случае, в скором времени. Однако, важно понимать как выполняется данная задача,
поэтому мы пройдём процесс обновления нашего сертификата корня. Мы выполним эту задачу прямо на самом нашем
сервере CA.
Чтобы обновить сертификат корня CA выполните следующие шаги:
Зарегистрируйтесь на своём сервере Корпоративного Корня (Enterprise Root) CA и откройте консоль
управления Certification Authority.Кликните правой кнопкой по имени вашего CA, переместитесь во
All Tasks, а затем выберите
Renew CA Certificate….В вашем экране Renew CA Certificate
у вас имеется только одна опция, о которой стоит побеспокоиться. Вам необходимо выбрать будете ли вы
создавать новую пару ключей для своего нового сертификата корня или повторно применять существующий.
Если вы уже опубликовали большое число сертификатов с этого CA, обычно проще ответить
No на это и повторно использовать существующую
пару ключей. Как вы можете видеть из информации на экране, существует ряд ситуаций, при которых вам следует
выбрать Yes и создать новую пару ключей, поэтому,
чтобы верно ответить на данный вопрос, необходимо осознавать ваши ситуацию и потребности.Кликните OK и новый сертификат корня немедленно
будет создан и начнёт распространяться через Групповую политику.
Ваш сертификат корня верхнего уровня критически важен для жизнеспособности всей вашей инфраструктуры PKI.
Если у этого сертификата истекает срок действия, все отдельные сертификаты, которые были выпущены этим сервером
CA немедленно становятся не действующими. К счастью, обновление такого сертификата обычно достаточно лёгкое.
Просто следуйте приведённым нами шагам и вы вернётесь в дело на следующие 5 или 10 лет. После того, как вы
обновите свой сертификат авторизации корня, он помещает новую копию такого сертификата в местоположение
Групповой политики Доверенных Авторизаций Корня. Все подключённые к домену системы хранят этот список
автоматически обновляемым через Групповую политику с тем, чтобы всякий раз когда добавляется новый сервер
CA или обновляется существующий сертификат корня, новые доверительные отношения, связанные с таким
новым сертификатом, автоматически распространялись на все ваши клиентские машины и серверы. По этой причине,
обычно, всё что вам нужно сделать – это обновить сам сертификат, а потом присесть и расслабиться, так как
Групповая политика начнёт размещать такой новый сертификат на место по все вашей сетевой среде.
Однако – и это является ЗНАЧИТЕЛЬНЫМ однако – если вы позволите вашему сертификату авторизации корня
превысить срок действия, а вы выпустили сертификаты, которые применяются клиентами и серверами для сетевой
аутентификации, истечение срока действия сертификата корня будет означать, что такие системы больше на смогут
подключаться в вашу сетевую среду. Вы можете легко обновить свой сертификат корня и привести сервер во
включённое и работающее состояние, однако, не имея действующего метода аутентификации в вашей сетевой среде,
ваши системы, которые полагаются на действующий сертификат для соединения с такой сетью сядут на мель.
Вам придётся искать альтернативный способ присоединения их в свою сетевую среду и обновления их Групповой
политики прежде чем они изучат как доверять вновь обновлённому сертификату авторизации корня. Это
предостережение приходит мне на ум, поскольку я только что помогал некоей компании воевать в точности с
этой проблемой. Срок действия их сертификата корня истёк, и они имели целые офисы, полные персонала, который
был подключён к их центру обработки данных и их домену исключительно через технологию удалённого соединения
DirectAccess. DirectAccess полагается на сертификаты как на часть своего процесса аутентификации, поэтому такие
удалённые системы полностью утратили возможность подключения к своей сетевой среде, раз уж срок действия их
сертификата корня истёк. нам пришлось подключать их к сети различными путями чтобы поместить установки GPO
и новую копию нового сертификата корня на место прежде чем начать удалённое соединение вновь.
Мораль этой истории: не забывайте отмечать в календарях необходимость обновления сертификатов ДО истечения
их срока действия!
Папка ‘пдд’ – елена евгеньевна поликарпова
 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| | Поиск по порталу | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 | ||||
|
|  | ||
 | ||||
§
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| | Поиск по порталу | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||
|
| | ||
| ||||
§
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| | Поиск по порталу | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||
|
| | ||
| ||||