Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.
Вторая часть серии
Третья часть серии
Введение
Целевая аудитория
ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.
Словарь терминов
В этой части серии использованы следующие сокращения и аббревиатуры:
- PKI (Public Key Infrastructure) — инфраструктура открытого ключа (ИОК), набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
- X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
- ЦС (Центр Сертификации) — служба, выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
- CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем.
- SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология, обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
- HTTPS (HTTP/Secure) — защищённый HTTP, являющийся частным случаем использования SSL.
- Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
Зачем нужен частный PKI?
Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).
Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.
Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.
Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.
Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:
Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.
Общие положения
PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:
- Шифрование – защищает данные от несанкционированного доступа третьих лиц путём шифрования данных криптографическими ключами. Только пользователи, имеющие необходимые ключи, могут получить доступ к данным. Шифрование обеспечивает секретность данных, но не защищает от их подмены.
- Цифровая подпись – защищает данные от несанкционированного изменения или подделки путём применения к данным специальных алгоритмов, которые образуют цифровую подпись. Любые манипуляции по изменению данных будут немедленно обнаружены при проверке цифровой подписи. Цифровая подпись обеспечивает не конфиденциальность данных, а их целостность. Путём комбинирования шифрования и цифровой подписи можно организовать обеспечение конфиденциальности и защиты данных от несанкционированных изменений.
Типичная инфраструктура PKI состоит из следующих компонентов:
- Центр Сертификации (ЦС) – служба, предоставляющая цифровые сертификаты потребителям и обеспечивающая функционирование PKI.
- Сервер отзыва – служба, предоставляющая информацию о списках отозванных (скомпрометированных или недействительных) сертификатов, выпущенных конкретным ЦС.
- Клиент – получатель заверенного цифрового сертификата от центра сертификации. Клиентами могут выступать люди, устройства, программное обеспечение, а также другие ЦС.
Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:
- Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева. Важно отметить, что доверие транзитивно. Клиент при проверке конечного сертификата будет выстраивать цепочку (путь) от конечного сертификата до вершины иерархии (корневого сертификата). И если клиент доверяет вершине, то будут и основания доверять конечному сертификату на правах транзитивности.
- ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.
- Издающий ЦС – это ЦС общего назначения, который выполняет подпись и выдачу цифровых сертификатов потребителям.
Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine — how it works. Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.
Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.
Отзыв сертификатов
Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.
Каждый клиент после установки доверия сертификата через цепочку должен убедиться, что ни один сертификат в цепочке не был отозван своим издателем. Для этого клиент перебирает каждый сертификат в цепочке, выбирает CRL предоставленный издателем и проверяет наличие/отсутствие текущего сертификата в списке CRL. Если текущий сертификат находится в CRL, то доверие к сертификату (и всем ветвям дерева под ним) автоматически обрывается.
Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:
When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.
А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.
Проблема отзыва корневых сертификатов во многих случаях будет одним из решающих факторов в выборе подходящей для компании иерархии ЦС. А также будет диктовать дополнительные меры безопасности для корневых ЦС, чтобы предельно снизить риск компрометации корневого ЦС.
Типовые схемы развёртывания иерархии PKI
В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.
Одноуровневая иерархия
Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:
Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.
Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.
Другой момент связан с гибкостью разделения ЦС на функциональные уровни (делегирование). Например, невозможно организовать несколько различных политик выдачи, разделить на классы (например, один ЦС издаёт сертификаты только машинам и устройствам, другой только для пользователей) и т.д., потому что он всего один.
Недостатки одноуровневой иерархии заметно перевешивают её преимущества в лёгкости и компактности. Именно поэтому такая конфигурация имеет смысл лишь в каких-то небольших и изолированных сетях с низкими требованиями по безопасности. Например, это может быть какая-то тестовая среда. В бизнес-среде такое решение использовать не рекомендуется.
Двухуровневая иерархия
Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:
Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.
В двухуровневой иерархии уже возможно решить недостатки одноуровневой иерархии. Здесь корневой ЦС выпускает сертификаты только для подчинённых ЦС, а уже подчинённый ЦС выдаёт сертификаты конечным потребителям. Поскольку издающие ЦС развёртываются не так часто, и срок их действия достаточного велик, это позволяет изолировать корневой ЦС от сети. Это автоматически сводит к нулю шанс компрометации такого ЦС, поскольку без сети к нему не добраться. Более того, основное время жизни он может (и должен) проводить в выключенном состоянии. Включать его нужно только для обновления собственного сертификата, подчинённого ЦС или для публикации нового CRL. В остальное время он никому не нужен.
Другим достоинством двухуровневой иерархии является улучшенная гибкость в разбиении подчинённых ЦС на какие-то классы. Тот же типичный сценарий, когда два ЦС управляются разными подразделениями ИТ, и каждый ЦС выпускает сертификаты для своих групп потребителей. Например, для машин отдельно, для пользователей отдельно. Можно для корпоративных разработчиков (которые обычно живут в своих средах) выделить свой подчинённый ЦС.
Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи) и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.
Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.
Для небольших и средних предприятий такая схема является наиболее оптимальной, поскольку она позволяет обеспечить должный уровень безопасности и приемлемый уровень гибкости разделения ЦС на определённые функции.
Трёх- и более уровневые иерархии
В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе. Представьте международную компанию с региональными офисами в разных странах. В них может действовать своё законодательство в вопросах безопасности, например, при обработке персональных данных. Для соблюдения подобных юридических формальностей на каждый такой регион выделяется свой собственный ЦС политик (при этом, размещается он, как правило, в головном офисе компании). В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).
В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:
Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.
К плюсам такой схемы можно отнести гибкость полученной PKI с возможностью адаптации под практически любые условия. Правда, за это придётся платить. Во-первых, многоуровневые иерархии удорожают стоимость развёртывания и сопровождения PKI. Во-вторых, клиентам требуется больше времени на построение и проверки на отзыв полных цепочек сертификатов, что может вызывать отказы из-за превышения таймаутов верхних протоколов передачи данных. И на практике такие схемы зачастую являются избыточными. Поэтому при выборе подходящей иерархии ЦС следует искать баланс между гибкостью и практической целесообразностью с учётом капитальных и операционных затрат на содержание PKI.
В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.
Об авторе
Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.
В этой статье я подробно расскажу о процессе установки и настройки Active Directory Certificate Services.
Служба сертификации Active Directory создает центр сертификации, предназначенный для выдачи сертификатов пользователям. Служба может быть настроена и работать через веб-интерфейс.
В примере я разбираю Active Directory Certificate Services на операционной системе Windows Server 2012.
Первым делом нам нужно установить службу сертификации Active Directory.
Для этого нужно запустить диспетчер сервера.
Далее жмем «Добавить роли и компоненты». Кнопка далее.
Выбираем пункт установка ролей или компонентов, а затем выбираем наш сервер.
В следующем окне выбираем пункт службы сертификатов Active Directory.
В окне выбора компонентов жмем далее.
В окне служба ролей выбираем пункт центр сертификации.
Запускаем процесс установки.
После этого по аналогии устанавливаем веб-службу регистрации сертификатов.
Установка завершена. Перейдем к настройке.
Настройка службы сертификатов Active Directory
Заходим в настройки.
Выбираем службу центр сертификации.
Вариант установки – центр сертификации предприятия.
Тип центра сертификации – корневой. Это необходимо для того, что бы в дальнейшем мы могли самостоятельно выдавать и подписывать сертификаты.
В следующем окне нужно выбрать пункт создать новый закрытый ключ.
Затем необходимо указать параметры шифрования. Вы можете указать свои параметры, или параметры как у меня на рисунке ниже.
В следующем окне указывается имя центра шифрования.
Затем указывается срок действия центра сертификации. По умолчанию он равен 5 годам. Так и оставим.
После нажатия кнопки далее вам нужно будет указать физическое место на жестком диске для хранения базы данных.
Подтверждаем настройку.
Перейдем к настройке web-службы регистрации сертификатов.
Настройка web-службы регистрации сертификатов
В окне указать центр сертификации для веб-службы регистрации сертификатов выбираем пункт «Имя ЦС».
Тип проверки подлинности – имя пользователя и пароль.
Учетная запись службы CES – использовать встроенное удостоверение пула приложений.
В окне выбора сертификата проверки подлинности сервера выберите существующий сертификат, затем нажмите кнопку настроить.
Настройка выполнена.
Выберите тип проверки подлинности – имя и пароль пользователя.
Включите режим обновления на останове ключей. Этот режим позволяет автоматически обновлять сертификаты ключей для компьютеров, которые не подключены к внутренней сети.
Перезагрузите сервер.
Установка и настройка удостоверяющего центра
Запустите консоль управления Microsoft (пуск, выполнить, mmc).
Далее нажмите файл, а затем добавить или удалить оснастку.
В левой части нужно выбрать пункт «Сертификаты» и нажать кнопку добавить.
В появившемся окне выбрать пункт учетной записи компьютера.
В следующем окне ничего не меняем и нажимаем кнопку готово. Оснастка добавлена.
В левой части окна можно увидеть папки, в которых хранятся сертификаты (11 штук). Они сортированы по типам сертификатов. Если нажать на папку «Личное» то можно посмотреть сертификаты в этой папке.
Запросим новый ключ, для этого нужно нажать на сертификате и выбрать меню «все задачи», а затем «запросить сертификат с новым ключом».
Появится окно перед началом работы. Жмем далее.
Видим окно запрос сертификатов и нажимаем «заявка».
Запускается процесс установки сертификата. После успешной установки появиться следующая надпись «Состояние: Успешно».
Теперь нам нужно связать сертификат с веб-сервером. Для этого нужно запустить диспетчер служб IIS.
В левой части окна нажать сайты, default web site, изменить привязки.
В появившемся окне нажмите добавить и введите данные как на изображении ниже.
Сохраните изменения и закройте окно.
Для проверки работоспособности Центра сертификации запустите браузер Internet Explorer и в строке навигации наберите адрес «https://192.168.0.1/certsrv/» (ip-адрес может отличаться от того, который указали вы).
Управление шаблонами сертификата
Работа с шаблонами сертификата требует установки оснастки «Шаблоны сертификатов». Откроем нашу консоль, которую мы создавали ранее и добавим оснастку «Шаблоны сертификатов».
Откроем шаблоны в главном окне консоли. Создадим новый шаблон.
Сначала нужно выбрать любой шаблон сертификата и нажать скопировать его.
Настроим шаблон. Выберите совместимость шаблона сертификата.
Задайте общие свойства шаблона.
В поле «отображаемое имя» , в строке «имя шаблона» будет тоже самое только без пробелов.
Параметры достоверности по умолчанию и периода обновления для сертификатов, выдаваемых службами сертификатов Active Directory (AD CS), предназначены удовлетворить большинство требований безопасности. Однако для сертификатов, используемых определенными группами пользователей, может потребоваться указать другие параметры достоверности и обновления, такие как более короткие срок действия или периоды обновления.
За это два параметра отвечают для поля «период действия» и «период обновления».
Параметр «опубликовать сертификат в Active Directory» определяет, будут ли сведения о шаблоне сертификата доступными по всему предприятию.
Параметр «не использовать автоматическую перезаявку, если такой сертификат уже существует в Active Directory». С помощью этого параметра автоматическая подача заявки на сертификат не подаст запрос повторной заявки, если в доменных службах Active Directory (AD DS) существует дубликат сертификата. Это дает возможность обновлять сертификаты, но предотвращает выдачу нескольких дубликатов сертификатов.
Обработка запроса. Цель имеет 4 возможных параметра:
- Вход с подписью и смарт-картой. Разрешает первоначальный вход в систему с помощью смарт-карты и цифровую подпись данных. Нельзя использовать для шифрования данных.
- Подпись. Содержит шифровальные ключи только для подписи данных.
- Подпись и шифрование. Охватывает все основные применения шифровального ключа сертификата, включая шифрование данных, дешифрование данных, первоначальный вход в систему и цифровую подпись данных.
- Шифрование. Содержит шифровальные ключи для шифрования и дешифрования.
Параметр «включить симметричные алгоритмы, разрешенные субъектом» позволяет администратору выбрать алгоритм стандарта AES для шифрования закрытых ключей, когда они передаются в ЦС для архивации ключа.
Если установлен этот параметр, клиент будет использовать симметричное шифрование AES-256 (наряду с сертификатом обмена ЦС для асимметричного шифрования), чтобы отправить закрытый ключ в ЦС для архивации.
Параметр «авторизация дополнительных учетных записей служб для доступа к закрытому ключу» позволяет задать настраиваемый список управления доступом (ACL) к закрытым ключам сертификатов компьютеров на основе любых шаблонов сертификатов компьютера версии 3 за исключением корневого ЦС, подчиненного ЦС и перекрестных шаблонов ЦС.
Настраиваемый список управления доступом необходим в случае, если учетная запись службы, которой требуется доступ к закрытому ключу, не включена в разрешения по умолчанию.
Вкладка шифрование. Определяется максимальный размер ключа. Я оставлю его без изменений.
Безопасность можно настроить по вашему усмотрению.
Шаблон сертификата готов.
На этом статья подходит к концу. Мы установили и настроили Active Directory Certificate Services.
Работа с корпоративными и автономными центрами сертификации CA Центр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), является ключевым компонентом программного обеспечения
Работа с корпоративными и автономными центрами сертификации CA
Центр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), является ключевым компонентом программного обеспечения инфраструктуры открытых ключей PKI (Public Pey Infrastructure) в среде Windows Server 2003. Центр CA принимает и обрабатывает запросы на получение сертификатов от пользователей PKI, идентифицирует эти запросы и проверяет их правомерность, выдает сертификаты в соответствии с политикой безопасности PKI, обновляет и аннулирует сертификаты, размещает сертификаты на различных узлах хранения, создает и публикует списки аннулированных сертификатов CRL (Сertificate Revocation Lists), а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL. Центр сертификации Windows 2003 CA может выполнять в безопасном режиме архивирование и восстановление секретных ключей. Чтобы оценить степень развития возможностей центров CA и PKI в среде Windows 2003, в этой статье мы рассмотрим компоненты архитектуры последней реализации служб Certificate Services, а также различия в процедурах развертывания корпоративного и автономного центра CA в среде Windows 2003.
Архитектура Windows 2003 Certificate Services. Архитектура Windows 2003 Certificate Services почти идентична той, которая использовалась Microsoft при реализации предыдущих версий названных служб. Основное различие состоит в том, что здесь Microsoft изменила структуру базы данных CA для реализации поддержки процедур архивирования и восстановления секретных ключей пользователей. Схема данной архитектуры показана на рисунке. Она включает в себя различные модули, базы данных, инструментальные средства администрирования, посредников и прикладной интерфейс CryptoAPI.
|
Рисунок. Архитектура CA |
Модули. Сердцем Certificate Services является исполнительный механизм CA (certsrv.exe), который генерирует сертификаты и занимается управлением потоками сообщений между CA и другими компонентами служб Certificate Services. Серверный механизм CA взаимодействует с другими компонентами архитектуры через входные модули, модули политики и выходные модули.
Входной модуль принимает запросы на сертификаты, соответствующие формату криптографического стандарта открытых ключей № 10 (Public-Key Cryptography Standards, PKCS #10) или криптографического протокола управления, использующего синтаксис криптографических сообщений (Cryptographic Management protocol using Cryptographic Message Syntax, CMS). После приема запроса входной модуль помещает его в очередь для дальнейшей обработки модулем политики.
Модуль политики реализует правила политики центра CA в соответствии с установками, заданными администратором CA. Данный модуль передает исполнительному механизму CA информацию о структуре сертификата и принимает решение о выдаче сертификата, об отказе в его выдаче или о переводе запроса сертификата в режим ожидания. Для обновления информации о структуре сертификата модуль политики может обращаться к информации, хранящейся в каком-либо каталоге (например, Active Directory) либо в базе данных. Модуль политики, имеющийся в Windows 2003, называется certpdef.dll. Он поддерживает два типа политики: режим корпоративной политики и режим автономной политики. Эти режимы будут подробно рассмотрены ниже. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, следует запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Policy Module, показанной на экране 1.
|
|
Экран 1. Вкладка Policy Module в свойствах объекта |
Выходные модули занимаются распространением и публикацией сертификатов, цепочек сертификатов, а также полных списков CRL и списков изменений CRL. Выходной модуль может записывать данные PKI в файл или передавать эти данные на удаленный узел, используя в качестве транспорта протокол HTTP или механизм удаленного вызова процедур RPC. Windows 2003 CA может поддерживать несколько выходных модулей, соответственно распространение и публикация сертификатов, цепочек сертификатов, полных cписков CRL и списков изменений CRL может выполняться одновременно в различные пункты назначения, включая каталоги LDAP, файловые ресурсы совместного пользования, каталоги Web и, наконец, ODBC-совместимые базы данных. По умолчанию в Windows 2003 CA входит выходной модуль, называемый certxds.dll, в котором реализована поддержка LDAP, FTP, HTTP и SMTP (в центрах Windows 2000 CA также поддерживаются все эти протоколы, за исключением последнего). Выходной модуль позволяет организовать автоматическую рассылку уведомлений от центра CA пользователям PKI и администраторам. Чтобы убедиться в том, что на данном центре CA установлен модуль политики, нужно запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Exit Module, показанной на экране 2.
|
|
Экран 2. Вкладка Exit Module в свойствах объекта |
Модули политики и выходные модули являются настраиваемыми и заменяемыми компонентами, поэтому любая организация может разработать на языках C++ или Visual Basic (VB) собственные модули и интегрировать их в архитектуру Certificate Services. Вся необходимая информация о процессах создания и замещения модулей имеется в комплекте документации Software Development Kit (SDK) для платформы Windows 2003.
Настройка модулей политики и выходных модулей осуществляется с помощью оснастки Certification Authority или через утилиту командной строки certutil.exe. Используя окно свойств объекта CA оснастки Certification Authority, можно добавлять выходные модули, настраивать расширения X.509 для сертификатов (например, определять узлы CDP (CRL Distribution Points) и узлы AIA (Authority Information Access)), а также настраивать параметры публикации для полных списков CRL и списков изменений CRL.
Базы данных. Центр CA имеет собственную базу данных, которая называется CAname.edb. В этой базе хранится информация по транзакциям, связанным с сертификатами, и собственно сертификаты. Здесь же хранятся архивированные секретные ключи. По умолчанию эта база данных хранится в каталоге %systemroot%system32certlog. Исполнительный механизм центра CA взаимодействует с базой данных с помощью файла certdb.dll. С появлением службы Windows 2000 Certificate Services изменилась используемая Microsoft технология работы с базами данных. Теперь здесь используется процессор баз данных Jet, что позволило сделать архитектуру Windows 2000 CA масштабируемой. Отметим, что аналогичная технология используется в базах данных AD и Microsoft Exchange Server.
Средства администрирования. В большинстве случаев для администрирования центра сертификации Windows 2003 CA используется оснастка Certification Authority, но это можно делать и с помощью утилиты командной строки certutil.exe. Оба средства взаимодействуют с исполнительным механизмом центра CA через библиотеку certadm.dll.
Посредники (intermediaries). Прикладные программы, помогающие клиенту корректно сформировать запрос сертификата, соответствующий формату PKCS #10 или CMS, называются посредниками или Registration Authorities (RA). Эти программы собирают специальные данные о пользователе и о запросе, которые необходимы для формирования корректного запроса сертификата. Например, любой запрос, направляемый корпоративному центру Windows 2003 CA, должен содержать ссылку на шаблон сертификата. Программы RA могут добавлять к запросу описание шаблона. Следует отметить, что эти программы используют определенные транспортные протоколы (например, HTTP и RPC), соответственно при этом и исполнительный механизм CA не должен использовать для работы другие типы транспорта.
Примерами посредников в Windows 2003 могут служить Web-страницы регистрации сертификатов, которые являются посредниками HTTP, а также оснастка Certificates консоли MMC, вызывающая мастер Certificate Request Wizard, которая играет роль RPC-посредника. При генерации секретных ключей на клиентской машине посредник HTTP обращается к библиотеке xenroll.dll, а при генерации секретных ключей на смарт-картах он использует библиотеку scenroll.dll. Посредник RPC для выполнения данных процедур вызывает библиотеку certcli.dll.
Прикладной интерфейс CryptoAPI. Для реализации всех криптографических функций, включая доступ и использование секретных ключей CA, центр сертификации задействует вызовы интерфейса CryptoAPI. Центр CA может хранить свой секретный ключ на жестком диске или на специальном аппаратном устройстве (например, на аппаратном модуле безопасности Hardware Security Module, HSM).
Установка Windows 2003 Certificate Services
При выполнении установки Windows 2003 Certificate Services может быть развернут корневой CA, подчиненный CA, корпоративный CA (интегрированный в AD) или автономный CA (не интегрированный в AD). Если служба Certificate Services устанавливается в корпоративном режиме, то в этом случае активируется аналогичный режим и для модуля политики центра Windows 2003 CA. Рассмотрим, чем отличаются корпоративный и автономный режимы. В таблице приведены сравнительные характеристики параметров, установленных по умолчанию, для автономного и корпоративного центров Windows 2003 CA.
При установке корпоративного центра CA та учетная запись, от имени которой выполняется установка, должна иметь привилегии Enterprise administrator и Domain administrator в корневом домене леса AD. Кроме того, сервер, на который устанавливается корпоративный CA, должен являться членом домена с функционирующей в нем службой AD. Если эти условия не выполнены, в CA installation Wizard будут недоступны возможности перехода в режим установки enterprise CA, соответственно развернуть центр CA можно будет только в автономном режиме.
Для того чтобы установить автономный центр CA, использовать AD необязательно. CA может устанавливаться как на автономный сервер, так и на сервер, входящий в домен, или на контроллер домена (DC). При такой установке не требуются и полномочия Enterprise administrator и Domain administrator, вполне достаточно прав локального администратора на данном сервере. Если при установке автономного центра CA все-таки использовать привилегии Enterprise administrator, в этом случае данный центр будет обладать некоторой дополнительной функциональностью. В частности, если пользователь с правами Enterprise administrator устанавливает автономный центр CA на сервер, входящий в состав домена, то в этом случае центр CA сможет публиковать выпущенные им сертификаты в AD.
Шаблоны сертификатов
Корпоративный центр CA использует шаблоны сертификатов, которые хранятся в структуре AD в контексте имен конфигурации. Шаблон определяет содержание и характеристики сертификата. Кроме того, с помощью шаблонов можно контролировать типы выпускаемых центром CA сертификатов и определять, какие пользователи могут запрашивать сертификаты у корпоративного центра CA, а также сертификаты какого типа могут им выдаваться. В инфраструктуре PKI среды Windows 2003 поддерживаются шаблоны сертификатов версии 2, которые, в отличие от шаблонов версии 1, являются полностью настраиваемыми. Настройка шаблонов осуществляется с помощью оснастки Certificate Templates консоли MMC.
Автономный центр CA не может использовать шаблоны сертификатов AD, в этом случае нельзя выполнять контроль типов сертификатов и пользователей, их получающих. По умолчанию автономный CA может выдавать только сертификаты, предназначенные для Web-аутентификации (Secure Sockets Layer, SSL; или Transport Layer Security, TLS), защиты электронной почты (Secure MIME, S/MIME), аутентификации сервера, цифровой подписи и для работы с протоколом IP Security (IPSec). Тем не менее можно модифицировать Web-интерфейс автономного центра CA (например, для того чтобы в списке отображались другие типы сертификатов) или запрашивать другие типы сертификатов, используя для этого значения специальных идентификаторов объектов (OID), которые хранятся в X.509-расширении сертификата Extended Key Usage.
Получение дополнительной информации при запросе сертификата
В процессе регистрации сертификата корпоративный центр CA ищет в структуре Active Directory информацию о пользователе, которая потребуется центру для заполнения определенных полей сертификата. Например, в поле X.509 SubjectAltName сертификата, выданного корпоративным центром CA, содержится ссылка на имя пользователя, определяющее его в AD, — User Principal Name (UPN). Если центр CA является автономным, он не имеет доступа к AD, поэтому информация, идентифицирующая пользователя и необходимая для получения сертификата с Web-сайта регистрации, должна вводиться пользователем вручную.
Как в корпоративных, так и в автономных центрах CA можно изменять установленные по умолчанию параметры, добавляемые центром CA к запросу сертификата. Это делается в процессе регистрации сертификатов путем редактирования файла certdat.inc, который находится в каталоге %systemroot%system32certsrv. Допускается изменение значений, установленных по умолчанию, для следующих параметров сертификата: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, и sDefaultCountry. Если привести значения этих параметров в соответствие с используемыми в организации наименованиями, можно будет сократить объем вводимой пользователем информации при запросе сертификата.
Автоматическая регистрация сертификатов
Центр CA корпоративного типа поддерживает технологию автоматической регистрации сертификатов, причем в Windows 2003 возможности данной технологии расширены и теперь распространяются как на пользовательские сертификаты, так и на сертификаты компьютеров. Более подробно эти вопросы рассматриваются в статье «Технология регистрации PKI сертификатов в Windows 2003 Server», опубликованной на сайте журнала Windows IT Pro/RE (http://www.osp.ru/win2000/safety/511_29.htm). Отметим, что если пользователь запрашивает сертификат от автономного центра CA, процесс регистрации должен быть запущен вручную, так как в данном случае какие-либо процедуры автоматизации отсутствуют.
Централизованное архивирование ключей
Корпоративный центр CA поддерживает механизмы централизованного архивирования ключей в базе данных CA, а автономный центр — нет. Возможности технологии архивирования и восстановления ключей CA более подробно обсуждаются в статье «Автоматическое архивирование и восстановление ключей в инфраструктуре Windows Server 2003 PKI», опубликованной в № 3 журнала Windows IT Pro/RE за 2006 г.
Утверждение запроса сертификата
В корпоративных центрах CA имеется поддержка механизмов автоматического и ручного утверждения запросов сертификатов. Для того чтобы настроить свойства режима обработки запросов сертификатов, можно воспользоваться либо свойствами корпоративного CA (через свойства модуля политики), либо свойствами шаблона сертификата версии 2 (с помощью вкладки Issuance Requirements окна свойств шаблона сертификата). Если настройка режима обработки запросов выполняется через свойства шаблона сертификата версии 2, то следует иметь в виду, что внесенные при этом изменения будут применены только к сертификатам того типа, который определяется данным шаблоном. Можно задать настройку, обязывающую администратора утверждать все поступающие запросы сертификатов вручную, независимо от установок в шаблоне сертификата. Для этого при настройке режима обработки запросов в свойствах CA нужно выбрать пункт Set the certificate request status to pending. The administrator must explicitly issue the certificate. Эти же пункты доступны и для автономного центра CA, с той лишь разницей, что автономный CA не может использовать шаблоны сертификатов, и, следовательно, не удастся настроить свойства обработки запросов для отдельного шаблона сертификата. В отличие от корпоративного центра, автономный CA при аутентификации поступающих запросов не использует внутренние механизмы аутентификации Windows, соответственно компания Microsoft не рекомендует устанавливать режим автоматического утверждения в свойствах обработки запросов для автономных центров CA. В этих случаях всегда следует оставлять установку, сделанную по умолчанию, в соответствии с которой каждый поступающий запрос сертификата должен утверждаться администратором вручную.
Опубликование сертификатов и списков CRL
Корпоративные центры CA хранят и публикуют сертификаты, а также полные списки CRL и списки изменений CRL в Active Directory. В то же время как корпоративные центры, так и автономные CA могут осуществлять размещение данных в файловой системе. Каждый размещенный в AD сертификат автоматически отображается на учетную запись того, кто его запрашивал. Служба Active Directory добавляет сертификат к многозначному атрибуту UserCertificate пользователя или объекта AD inetOrgPerson. Отметим, что не каждый выданный корпоративным центром CA сертификат автоматически публикуется в AD. Примерами сертификатов, которые не будут публиковаться автоматически, могут служить сертификат агента регистрации или сертификат для подписи списка CTL (certificate trust list).
В принципе автономный центр CA тоже может публиковать выпущенные им сертификаты в AD, но по умолчанию этот режим не поддерживается. Данная возможность может быть реализована только при развертывании автономного центра CA на сервере, который является членом домена. Отметим, что всегда можно явно размещать сертификаты в AD в ручном режиме.
Выбор типа CA, оптимального для решаемых задач
Итак, мы определили различия между корпоративным и автономным центром CA и теперь, на основании полученных знаний, можем выбирать конфигурацию центра CA, оптимальную для конкретной ситуации. Развертывание корпоративного центра Windows 2003 CA будет наилучшим решением для работы с сертификатами пользователей, имеющих учетные записи в AD и использующих протокол Kerberos для их аутентификации в инфраструктуре AD. Для внешних пользователей (например, пользователей из внешней сети, не имеющих учетных записей в инфраструктуре Windows внутренней сет) оптимальным решением будет использование автономного центра Windows 2003 СA.
Жан де Клерк — Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com
Таблица. Сравнение основных характеристик автономного и корпоративного центров сертификатов Windows2003 CA
| Свойство | Автономный Windows 2003 CA | Корпоративный Windows 2003 CA |
| Возможность интеграции в AD | По умолчанию отсутствует | Интегрированный в AD |
| Протоколы взаимодействия с CA | Клиенты взаимодействуют с CA по протоколам HTTP или HTTP Secure (HTTPS) | Взаимодействие клиентов с CA может осуществляться через RPC или Distributed COM DCOM), а также по протоколам HTTP или HTTPS |
| Распространение сертификатов | Центр CA загружает CA в пользовательский профиль, когда пользователь получает в ручном режиме сертификат с Web-сайта центра CA. Есть возможность автоматического размещения списков CRL и сертификатов в AD | В зависимости от настройки шаблона сертификата центр CA может автоматически загрузить сертификат в пользовательский профиль, поместить сертификат в AD либо выполнить оба действия |
| Утверждение запросов сертификатов | Процедура выдачи разрешений на регистрацию сертификатов может быть автоматической или ручной. Режим работы данной процедуры контролируется в центре CA с помощью одной общей настройки для всех типов сертификатов | Процедура выдачи разрешений на регистрацию может быть автоматической или ручной. Есть возможность как глобального контроля данного режима на уровне центра CA, так и задания различных режимов для разных типов сертификатов, что достигается соответствующей настройкой шаблонов сертификатов. В процессе выдачи разрешений на регистрацию сертификатов могут также использоваться имеющиеся в AD механизмы аутентификации и контроля доступа, базирующиеся на списках контроля доступа (ACL), которые могут быть заданы в шаблонах сертификатов |
| Ограничения по типам пользователей инфраструктуры PKI | Ориентируется на работу с инфраструктурой PKI пользователей Internet и внешних сетей | Ориентируется на работу с инфраструктурой PKI пользователей корпоративной сети |
| Требования по платформе | Данная версия может устанавливаться на контроллер домена (DC) Windows 2003, на сервер домена или на авто- номный сервер, не являющийся членом какого-либо домена. | Данная версия устанавливается только на контроллер домена (DC) Windows 2003 или на сервер домена |
| Поддерживаемые типы сертификатов | Может выдавать ограниченный набор типов сертификатов и сертификаты, требующие наличия специального идентификатора OID в расширении Extended Key Usage. Работа с шаблонами сертификатов не поддерживается | Может выпускать для среды Windows 2003 сертификаты любых типов из тех, которые представлены в оснастке Windows 2003 Certificate Templates. Поддерживаются шаблоны сертификатов версии 1 (Windows 2000 PKI) и версии 2 (Windows 2003 PKI) |
| Идентификация пользователей | При запросе сертификата пользователь должен ввести идентифицирующую его информацию вручную | Центр CA автоматически получает информацию, идентифицирующую пользователя, из AD |
| Управление пользователями | Пользователь регистрируется через Web-интерфейс. Можно также использовать утилиту командной строки c ertreq.exe | Пользователь регистрируется через Web-интерфейс или с помощью оснастки Certificates. Также существуют возможности автоматической регистрации сертификатов и регистрации с помощью утилиты командной строки certreq.exe |
Практическая работа с центром сертификации. Настройка и управление
Практическая работа с центром сертификации
Настройка публичного хранилища в MS Windows Server 2012 R2
Для того, чтобы создать и использовать публичное хранилище сертификатов, необходимо:
Создать папку Public в каталоге C:\Inetpub\wwwroot\ на сервере сертификации:
Запустить Диспетчер служб IIS. В левой части окна
Диспетчера служб IIS раскрыть дерево подключений /сайты/Default Web Site/Public. При выделении курсором
ветки Public в правой стороне откроется Начальная страница Public, в которой нужно дважды
нажать на Просмотр каталога:
В крайне правом окне нажать на Включить:
Скопировать из каталога C:\Windows\System32\Certsrv\CertEnroll корневого и
подчиненного центров сертификации списки отозванных сертификатов и
сертификаты в каталог C:\Inetpub\wwwroot\Public.
Проверить доступ к этим файлам по адресу https://«имя сервера»/public и скачать любой файл.
Управление шаблонами сертификатов в MS Windows Server 2012 R2
В рамках этого раздела рассматриваются создание нового шаблона
пользователя с возможностями подписи документов и создание сертификата
пользователя по созданному шаблону через веб-сайт центра сертификации.
Создание шаблона сертификата
Запустить Центр сертификации. Для этого нажать кнопку Пуск, в открывшемся окне на значок стрелки
в кружке. Кликнуть дважды мышкой на Центр сертификации. В центре сертификации
переместиться на Шаблоны сертификатов, вызвать
контекстное меню, нажать на Управление. Выделить
шаблон Пользователь, вызвать контекстное меню, выбрать
в нем Скопировать шаблон:
В окне Совместимость оставить все по умолчанию. В окне
Общие задать отображаемое имя шаблона – Сертификат пользователя УЦ
. Снять флажок Опубликовать сертификат в Active Directory:
Перейти в закладку Обработка запроса. В поле Цель
выбрать Подпись.
На запрос об изменении назначения сертификата нажать Да:
Перейти в закладку Шифрование, выбрать:
В запросах могут использоваться любые поставщики, доступные на компьютере пользователя
:
В закладке Имя субъекта установить флажок Предоставляется в запросе:
Перейти на вкладку Безопасность и для группы Прошедшие проверку
требуется установить флажок Заявка в колонке Разрешить:
Перейти на вкладку Расширения и изменить настройки
Политики применения. Для этого необходимо нажать на кнопку Изменить:
В открывшемся диалоговом окне необходимо выбрать политику Подписывание документа,
удалить Шифрующая файловая система (EFS) и нажать на кнопку
ОК. В том случае, если данный пункт отсутствует,
необходимо нажать на кнопку Добавить:
Создание сертификата пользователя по созданному шаблону
В Центре сертификации необходимо вызвать контекстное
меню пункта Шаблоны сертификатов, в котором необходимо
нажать на кнопку Создать – Выдаваемый шаблон сертификата:
В открывшемся диалоговом окне необходимо выбрать ранее созданный шаблон
и нажать на кнопку ОК:
Проверяем шаблон, для этого в браузере открываем страницу центра сертификации:
Нажимаем на строку Запроса сертификата. В следующем
окне нажать на Расширенный запрос сертификата:
Нажать на строку Создать и выдать запрос к этому ЦС:
В окне запроса сертификата выбираем шаблон сертификата Сертификат пользователя УЦ. Обязательно должны быть
заполнены поля Имя и Страна, регион
(ввести значение RU). Нажать кнопку Выдать:
В случае правильного заполнения полей шаблона будет сформирован
сертификат. Нажать Установить этот сертификат:
Заходим в центр сертификации в ветку Выданные сертификаты. Последний
сертификат будет тот, который был сформирован через веб-сайт:
Установка и настройка OCSP-службы подчиненного центра сертификации на базе MS Windows Server 2012 R2
Для установки и настройки OCSP-службы необходимо:
- установить OCSP-службу;
- настроить шаблон для выпуска сертификата OCSP-службы;
- настроить центр сертификации для работы с OCSP-службой;
- настроить службу.
Установка сетевого ответчика
Для установки доменной службы запустите Диспетчер серверов.
В окне Панель мониторинга нажать Добавить роли и
компоненты. В окне Мастера добавления ролей и компонентов оставить по
умолчанию тип установки Установка ролей или компонентов. В окне выбора сервера
нажать Далее , оставив все по умолчанию. В окне выбора
ролей сервера найти Службу сертификатов Active Directory, раскрыть
строку дважды кликнув мышкой по строке, поставить флажок в строке Сетевой ответчик:
В появившемся окне нажать кнопку Добавить компоненты:
В окне выбора компонентов нажать Далее:
Нажмите Установить. После установки необходимо
настроить службу, для этого нажмите на строку
Настроить службу сертификатов Active Directory на конечном сервер
:
В окне учетные данные нажмите кнопку Далее. Поставить
флажок в строке Сетевой ответчик и нажать Далее:
Нажать кнопку Настроить:
После настройки закрыть все окна.
Настройка шаблона сетевого ответчика
Запустить Центр сертификации. Для этого нажать кнопку Пуск, в
открывшемся окне на значок стрелки в кружке. Кликнуть дважды мышкой на Центр сертификации.
В центре сертификации переместиться на Шаблоны сертификатов, вызвать контекстное меню, нажать
на Управление. Выделить шаблон Подписывание отклика OSPC, вызвать контекстное меню,
выбрать в нем Свойства. Перейти в закладку Безопасность.
Нажать кнопку Добавить. В окне выбора нажать кнопку Дополнительно:
Нажать кнопку Типы объектов. Поставить флажок в строке
Компьютеры и нажать ОК:
В окне выбора нажать кнопку Поиск. После окончания
поиска в окне результатов найти ваш сервер и нажать ОК:
В окне Группы или пользователи выбрать ваш сервер и
для него в окне Разрешения поставить флажок в строке Заявка:
В Центре сертификации необходимо вызвать контекстное
меню пункта Шаблоны сертификатов, в котором необходимо
нажать на кнопку Создать – Выдаваемый шаблон сертификата. В открывшемся
диалоговом окне необходимо выбрать ранее настроенный шаблон и нажать на
кнопку ОК.
Настройка центра сертификации для поддержки службы сетевых ответчиков
Открыть Центр сертификации. Через контекстное меню откройте Свойства.
Перейти в закладку Расширения. В списке расширений
выбрать Доступ к сведениям о центрах сертификации (AIA):
В строке Размещение написать путь https://«ваш сервер»/ocsp/ocsp.srf.
Поставить флажок в строке Включать в расширение протокола OCSP:
Перезапустить Центр сертификации.
Настройка сетевого ответчика
Запустить Сетевой ответчик:
В окне управления выделить Конфигурация отзыва,
вызвать контекстное меню, выбрать Добавить конфигурацию отзыва:
Введите имя конфигурации отзыва, например, OCSP:
В окне выбора расположения сертификата ЦС должен быть выбран пункт
Выберите сертификат для существующего ЦС предприятия:
Нажать кнопку Обзор:
Выбрать корневой сертификат ЦС и нажмите ОК:
После выбора сертификата ЦС в окне выбора появиться ссылка на сертификат.
Нажмите Далее:
Если OCSP-служба настроена правильно, то в конфигурации сетевых
ответчиков служба будет в рабочем состоянии.
Центр сертификации (ЦС, СА) — важнейший элемент в безопасности ИТ инфраструктуры организации. Для того чтобы выдавать серверам и рабочим станциям сертификаты, нам нужно иметь в нашей локальной сети минимум один ЦС. Для этого на любом сервере нашей сети под управлением Windows 2008 R2 (непринципиально) нам нужно установить роль Службы сертификации Active Directory.
Установка:
- Открываем Диспетчер Сервера и нажимаем «Добавить роли» (Рис.1):
Рис.1.
2. На странице приветствия нажимаем Далее (Рис.2):
Рис.2.
3. Выбираем роль «Службы сертификации Active Directory» и нажимаем Далее (Рис.3):
Рис.3.
4. На странице знакомства со службами сертификации нажимаем Далее (Рис.4):
Рис.4.
5. На странице «Выбор служб ролей» добавляем галку «Служба регистрации в центре сертификации через Интернет», откроется «Мастер добавления ролей», нажимаем «Добавить требуемые службы роли». Окно «Мастера добавления ролей» закроется и в окне «Выбор служб ролей» жмем Далее (Рис.5-6):
Рис.5.
Рис.6.
6. Далее, в окне «Задание типа установки» выбираем «Предприятие» и нажимаем Далее (Рис.7):
Рис.7.
7. В окне «Задание типа ЦС» выбираем «Корневой ЦС» и нажимаем Далее (Рис.8):
Рис.8.
8. В окне «Установка закрытого ключа» выбираем «Создать новый закрытый ключ» и нажимаем Далее (Рис.9):
Рис.9.
9. В окне «Настройка шифрования для ЦС» нажимаем Далее (Рис.10):
Рис.10.
10. На странице «Задание имени ЦС» нажимаем Далее (Рис.11):
Рис.11.
11. В окне «Установить срок действия» устанавливаем нужный нам срок действия сертификата и нажимаем Далее (Рис.12):
Рис.12.
12. В окне «Настройка базы хранения сертификатов» можем изменить каталог с БД или оставить по умолчанию. Нажимаем Далее (Рис.13):
Рис.13.
13. На странице «Веб-сервер» нажимаем Далее (Рис.14):
Рис.14.
14. На странице «Выбор служб ролей» оставляем все по умолчанию и нажимаем Далее (Рис.15):
Рис.15.
15. Далее будет страница «Подтверждение выбранных элементов для установки», нажимаем Установить (Рис.16):
Рис.16.
16. После успешной установки нажимаем Закрыть (Рис.17):
Рис.17.
17. Консоль Центра Сертификации можно открыть так: Пуск -> Администрирование -> Центр Сертификации (Рис.18):
Рис.18.
18. Запрашивать, загружать и проверять статус запроса на сертификат необходимо через браузер по адресу: http://your_server/certsrv (Рис.19):
Рис.19.
Успехов!