Центр сертификации windows для чего нужен — Ваш верный помощник с OS Windows

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе 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 Certificate Services (ADCS) – это серверная роль Windows Server, которая позволяет нам развернуть инфраструктуру PKI внутри корпоративного домена. В зависимости от размеров вашей сети, требований бизнеса, требований службы безопасности вашей организации может быть организована такая архитектура открытых ключей, которая будет соответствовать всем предъявляемым требованиям.

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

Планируемая инфраструктура

Перед началом работ необходимо составить план и нарисовать схему, которую мы будем реализовывать. Как я уже писал выше – у нас будет двухуровневая инфраструктура PKI. Архитектура решения представлена на рисунке ниже:

В данной схеме представлены следующие объекты:

Объект	Описание
Root CA	Корневой центр сертификации. На данном сервере будет сформирован корневой сертификат, после чего данный сервер будет находиться в выключенном состоянии для уменьшения возможности компрометации ключа.
Subordinate CA	Издающий центр сертификации. Данный сервер будет находиться в домене и должен быть в постоянно включенном состоянии. Данный сервер будет выдавать сертификаты для серверов и клиентов.
Infrastructure Servers	Инфраструктурные серверы или сервисы, которым необходимы сертификаты для полноценной работы
Application Servers	Различные серверы приложений
Clients	Клиентские рабочие станции

Развертывание инфраструктуры

Развертывание корневого центра сертификации

1. Заходим на сервер корневого центра сертификации;

2. Идем в Server Manager – Manage – Add Roles and Features:

3. Откроется Add Roles and Features Wizard:

На странице Before you begin нажимаем Next;

4. В окне Installation Type оставляем все по умолчанию и нажимаем Next:

5. На странице Select destination server выбираем наш сервер:

И нажимаем Next;

6. На странице Select server roles выбираем Active Directory Certificate Services:

Нам сразу будет предложено установить Remote Server Administration Tools. Нажимаем Add Features и затем нажимаем Next;

7. На странице Select features нажимаем Next;

8. На странице Active Directory Certificate Services нажимаем Next;

9. На странице Select role services убеждаемся, что у нас выбран пункт Certification Authority (он, как правило, выбран по умолчанию):

И нажимаем Next;

10. На странице Confirm installation selections нажимаем Install:

11. Начнется процесс установки:

12. После окончания установки мы увидим такое окно:

Для продолжения настройки выбираем Configure Active Directory Certificate Services on the destination server;

13. Откроется окно AD CS Configuration:

На странице Credentials необходимо указать учетные данные. Поскольку у нас сервер будет недоменный и настройка в режиме Standalone, то оставляем нашу административную учетную запись по умолчанию и нажимаем Next;

14. На странице Role Services выбираем Certification Authority и нажимаем Next:

15. На странице Setup Type выбираем Standalone CA и нажимаем Next:

16. На странице CA Type выбираем Root CA и нажимаем Next:

17. На странице Private Key выбираем Create a new private key:

И нажимаем Next;

18. На странице Cryptography for CA оставляем все по умолчанию и нажимаем Next:

19. На странице CA Name:

Заполняем поле Common name for this CA. Остальные поля в рамках нашей сегодняшней инфраструктуры мы не трогаем. Нажимаем Next;

20. На странице Validity Period выставляем 15 лет и нажимаем Next:

21. На следующей странице CA Database можно настроить пути для баз данных:

Оставляем все по умолчанию и нажимаем Next;

22. На странице Confirmation проверяем наши настройки и нажимаем Configure:

23. Начнется процесс установки и если все хорошо, то мы увидим такую страницу:

24. Идем в Server Manager – Tools – Certification Authority:

25. И попадаем в консоль CA:

Далее, идем по стандартрому пути C:\Windows\System32\CertSrv\CertEnroll и копируем оттуда сертификат и список отзыва сертификатов. Они нам понадобятся на этапе настройки выдающего центра сертификации.

Настройка выдающего центра сертификации

Для начала нам необходимо установить службу ADCS на нашем сервере, который будет выполнять роль выдающего центра сертификации. Для развертывания данной роли повторяем шаги 2-12 из раздела «Развертывание корневого центра сертификации«. После того, как мы завершили установку службы сертификатов, перейдем к ее настройке.

1. Откроется окно мастера AD CS Configuration:

На странице Credentials необходимо выбрать доменную учетную запись с правами Domain Admin и Enterprise Admin и нажимаем Next;

2. На странице Role Services необходимо выбрать роль Certification Authority:

И нажимаем Next;

3. На странице Setup Type выбираем Enterprise CA:

И нажимаем Next;

4. На странице CA Type выбираем Subordinate CA:

И нажимаем Next;

5. На странице Private Key выбираем Create a new private key:

И нажимаем Next;

6. На странице Cryptography for CA оставляем все по умолчанию и нажимаем Next;

7. На странице CA Name указываем имя в поле Common name for this CA:

И нажимаем Next;

8. На странице Certificate Request необходимо выбрать вариант запроса к корневому центру сертификации:

Выбираем (если не выбран) Save a certificate request to file on the target machine и нажимаем Next;

9. На странице CA Database оставляем все по умолчанию и нажимаем Next;

10. На странице Confirmation проверяем наши настройки и если все в порядке, то нажимаем Configure:

11. Начнется установка, и после завершения на странице Result можно посмотреть результаты установки:

Как видим, система сообщает, что установка полностью не завершена, поскольку не установлен сертификат. Этим сейчас и займемся.

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

1. Копируем наш созданный *.req – запрос на сервер RootCA в корень диска C;

2. На сервере RootCA запускаем CMD имени администратора и выполняем следующую команду:

certreq -submit "C:\subordCA.domain.com_domain-SUBORDCA-CA-1.req"

3. Во время запуска команды появится окно Certification Authority List:

Выбираем наш CA и нажимаем ОК;

4. Если запрос выполнен успешно, то мы увидим сообщение примерно такого содержания:

Нам сообщают, что наш запрос на сертификат ждет выдачи;

5. Идем по пути Server Manager – Tools – Certification Authority:

6. Заходим в Pending Requests:

И видим наш запрос с присвоенным Request ID 2;

7. Вызываем контекстное меню:

Выбираем All Tasks – Issue;

8. Переходим в Issued Certificates и видим наш сертификат:

9. Возвращаемся в командную строку и вводим следующую команду:

certreq -retrieve 2 C:\SubCA.crt

В данном случае нашему сертификату будет присвоено имя SubCA, но при желании можете указать любое другое название для выгружаемого сертификата;

10. В форме Certification Authority List выбираем наш CA и нажимаем ОК;

11. Теперь у нас готов сертификат для нашего промежуточного сервера Subordinate CA.

Теперь, мы должны скопировать полученный нами сертификат, а также корневой сертификат и список отзыва (которые мы получили раньше) на наш промежуточный сервер сертификации в каталог C:\Install.

Установка корневого и промежуточного сертификатов

1. Открываем PowerShell с правами администратора и выполняем следующие команды:

certutil -dspublish -f "C:\install\RootCA_CompanyRootAuthority.crt"
certutil -addstore -f root "C:\install\RootCA_CompanyRootAuthority.crt"
certutil -addstore -f root "C:\install\CompanyRootAuthority.crl"

Данными командами мы выполняем публикацию и добавление корневого сертификата, полученного от сервера RootCA и список отзыва сертификатов. Если все команды отработали успешно, то можно устанавливать полученный сертификат SubCA.crt;

2. Открываем CMD от имени администратора и вводим следующую строку:

certutil -installcert C:\install\SubCA.crt

Эта команда установит наш сертификат на сервер Subordinate CA;

3. Если команда отработала без ошибок, то необходимо выполнить запуск службы CertSrv и наш сервер выдачи сертификатов готов к работе:

Итог

В рамках данной статьи мы развернули корневой и промежуточный центр сертификации. И данная система уже может функционировать, но если необходимо, чтобы клиенты автоматически получали сертификаты — потребуется дополнительная настройка внутри GPO. Статья по настройке автоматической выдачи сертификатов выйдет чуть позже.

Источник

Для чего нужен центр сертификации Windows: Глубокое погружение в мир цифровых гарантий

😇Комментировать📧

В современном цифровом мире, где информация передается со скоростью света, безопасность данных становится критически важной. Центры сертификации Windows — это краеугольный камень этой безопасности, играющий роль цифрового нотариуса, подтверждающего подлинность и надежность участников онлайн-взаимодействия. 🛡️ Они выступают в качестве доверенных третьих лиц, выдавая цифровые сертификаты, которые служат своего рода паспортами в мире интернет-коммуникаций. 🌐

Откройте желаемый раздел, нажав на соответствующую ссылку:

🔘 Что такое центр сертификации и как он работает

🔘 Корневые и подчиненные центры сертификации: иерархия доверия

🔘 Зачем нужны сертификаты Windows

🔘 SSL-сертификаты: гарантия безопасности в интернете

🔘 Центр сертификации ключей: хранитель цифровых подписей

🔘 Полезные советы и выводы

🔘 FAQ: Часто задаваемые вопросы

😹 Полная версия

🔐 Центр сертификации Windows: Ваш цифровой нотариус 🔐
В мире цифровых технологий, где информация передается со скоростью света, безопасность данных становится первостепенной задачей. Именно здесь на помощь приходит Центр сертификации Windows (ЦС) — надежный страж ваших цифровых ключей. 🗝️
Представьте себе ЦС как цифрового нотариуса, который подтверждает подлинность и целостность данных. Он выпускает цифровые сертификаты — своего рода электронные паспорта — для пользователей 🧑‍💻, компьютеров 🖥️ и служб ⚙️. Эти сертификаты содержат информацию о владельце и его публичном ключе, подтверждая его идентичность.
Центры сертификации бывают двух типов: корневые и подчиненные. 🌳 Корневой ЦС, подобно вершине пирамиды, является самым доверенным звеном. Он самостоятельно подписывает свой собственный сертификат и служит основой для доверия ко всем остальным сертификатам в иерархии. ⛰️
Подчиненные ЦС, как ветви дерева, получают свои полномочия от корневого ЦС. 🌳➡️🌳 Они выпускают сертификаты для конечных пользователей и устройств, опираясь на доверие к корневому центру.
Зачем же нужны эти цифровые сертификаты? 🤔 Они играют ключевую роль в обеспечении:
✅ Конфиденциальности: шифрование данных, защищая их от несанкционированного доступа. 🤫
✅ Аутентификации: подтверждение личности пользователей и устройств, предотвращая подделку. 🛂
✅ Целостности данных: гарантия того, что данные не были изменены в процессе передачи. 🛡️
Центр сертификации Windows — это невидимый, но незаменимый элемент инфраструктуры безопасности, который обеспечивает надежную защиту вашей цифровой жизни. Он позволяет вам спокойно работать и общаться в онлайн-среде, зная, что ваши данные находятся под надежной защитой. 🛡️🌐

Что такое центр сертификации и как он работает

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

Выдача цифровых сертификатов: ЦС выдает цифровые сертификаты, которые содержат информацию о владельце (например, имя пользователя, организации или веб-сайта) и его открытый ключ. Эти сертификаты служат цифровыми удостоверениями личности в онлайн-мире. 🧑‍💻
Проверка подлинности: Прежде чем выдать сертификат, ЦС тщательно проверяет информацию о заявителе, чтобы убедиться в его подлинности. Это предотвращает мошенничество и обеспечивает доверие к выданным сертификатам. ✅
Управление жизненным циклом сертификатов: ЦС отслеживает срок действия сертификатов, отзывает их при необходимости (например, в случае компрометации ключа) и обеспечивает бесперебойную работу системы безопасности. 🗓️

Корневые и подчиненные центры сертификации: иерархия доверия

Центры сертификации организованы в иерархическую структуру, похожую на генеалогическое древо. 🌳 В основе этой иерархии лежат корневые центры сертификации (Root CA), которые являются самыми доверенными институтами в этой системе. Они самостоятельно подписывают свои сертификаты, создавая основу для цепочки доверия.

Подчиненные центры сертификации (Subordinate CA) получают свои сертификаты от корневых ЦС или других подчиненных ЦС, находящихся выше в иерархии. Это позволяет распределять нагрузку по выдаче сертификатов и упрощает управление системой.

Зачем нужны сертификаты Windows

Сертификаты Windows играют важнейшую роль в обеспечении безопасности и надежности операционной системы. Они используются для:

Аутентификации пользователей и устройств: Сертификаты позволяют системе Windows подтверждать личность пользователей и устройств, предотвращая несанкционированный доступ. 🔐
Шифрования данных: Сертификаты используются для шифрования конфиденциальной информации, обеспечивая ее защиту от несанкционированного просмотра. 🔒
Цифровой подписи кода: Сертификаты позволяют проверять подлинность программного обеспечения, гарантируя, что оно не было изменено злоумышленниками. ✍️

SSL-сертификаты: гарантия безопасности в интернете

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

SSL-сертификаты также подтверждают подлинность веб-сайта, гарантируя, что пользователь взаимодействует именно с тем ресурсом, который он ожидает. Это помогает предотвратить фишинговые атаки и другие виды мошенничества. 🎣

Центр сертификации ключей: хранитель цифровых подписей

Центр сертификации ключей (ЦСК) — это специализированный ЦС, который фокусируется на управлении ключами электронной цифровой подписи (ЭЦП). ЭЦП — это цифровой аналог собственноручной подписи, который используется для подтверждения подлинности электронных документов. ✍️

ЦСК выполняет следующие функции:

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

Полезные советы и выводы

Доверяйте только надежным центрам сертификации: Убедитесь, что ЦС, выдавший сертификат, является доверенным и имеет хорошую репутацию.
Регулярно обновляйте сертификаты: Сертификаты имеют ограниченный срок действия. Убедитесь, что ваши сертификаты действительны и своевременно обновляйте их.
Храните свои ключи в безопасности: Ключи ЭЦП — это важная информация, которая должна храниться в безопасном месте.
Будьте внимательны при установке сертификатов: Устанавливайте сертификаты только из доверенных источников.

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

FAQ: Часто задаваемые вопросы

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

🎯 Для чего нужны центры сертификации

🎯 Сколько стоит доставка курьера на озон

🎯 Как отправить товар транспортной компанией луч

🎯 Кому принадлежит Сгб банк

Источник

Содержание

Зачем нужен центр сертификации windows
Записки IT специалиста
Windows Server. Создание автономного центра сертификации.
ЦС предприятия
Изолированный (автономный) ЦС
Windows Server 2003
Windows Server 2008 R2
Проверка работы ЦС
Службы сертификации Active Directory. Базовые знания

Зачем нужен центр сертификации windows

Сообщения: 181
Благодарности: 0

Выяснил, что почта Exchange опубликована в инет по протоколу https, для этого в ИСА указан сертификат, который, видимо, и был создан с помощью СА на этом КД. Я попробовал отключить службу СА на сервере, почта через Интернет не перестала работать. То есть если я правильно понял, то после генерации нужного сертификата эту службу можно остановить или даже удалить безболезненно? Тогда зачем в этой оснастке прописаны сертификаты для серверов-контроллеров домена? Какую роль они выполняют?

По поводу остального из списка — ничего в сети больше не используется.

то после генерации нужного сертификата эту службу можно остановить или даже удалить безболезненно? »

——-
MVP: Exchange Server 2009 — 2018
Microsoft Regional Director 2015 — 2017

По поводу переноса сервера — тут http://support.microsoft.com/kb/298138 написано, что нужно полностью убрать старый сервер и назвать новый сервер как старый. Но я уже назвал новый сервер и имя старого сервера совсем к нему не приемлимо

Получается нужно заново все сертификаты создавать?

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Главная
Windows Server. Создание автономного центра сертификации.

Windows Server. Создание автономного центра сертификации.

Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (PKI) и службы сертификации Windows.

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

Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

Для создания центра сертификации нам понадобится сервер, работающий под управлением Windows Server, который может быть как выделенным, так и совмещать роль центра сертификации с другими ролями. Однако следует помнить, что после развертывания центра сертификации вы не сможете поменять имя компьютера и его принадлежность к домену (рабочей группе).

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

ЦС предприятия

Требует наличия ActiveDirectory
Автоматическое подтверждение сертификатов
Автоматическое развертывание сертификатов
Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

Не требует наличия ActiveDirectory
Ручное подтверждение сертификатов
Отсутствие возможности автоматического развертывания
Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

Для возможности использования Web-интерфейса для выдачи сертификатов нам понадобится установленный web-сервер IIS. Установим его через диспетчер сервера: Пуск — Управление данным сервером — Добавить или удалить роль.

В списке ролей выбираем роль Сервера приложений. В следующем окне устанавливаем галочку Включить ASP.NET, если IIS уже установлен данный шаг можно пропустить.

После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ — Установка компонентов Windows, где выбираем Службы сертификации.

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

Далее вводим имя ЦС (должно совпадать с именем сервера) и пути размещения файлов. В процессе установки программа предложит перезапустить IIS и, если не была включена поддержка страниц ASP.NET, предложит ее включить, с чем следует согласиться.

Windows Server 2008 R2

В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера — Роли — Добавить роли, в списке ролей выбираем Службы сертификации Active Directory.

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

Дальнейшая настройка аналогична Windows Server 2003. Вводим тип ЦС, его имя и место хранения файлов, подтверждаем выбор компонент и завершаем установку.

Проверка работы ЦС

Для первоначальной проверки работоспособности ЦС можете запустить оснастку Центр сертификации (Пуск — Администрирование — Центр Сертификации). Если все сделано правильно вы должны увидеть следующее окно:

Попробуем теперь получить сертификат для клиентского ПК. Запустим браузер, в адресной строке которого укажем адрес http://имя_сервера/certsrv, где имя_сервера — имя сервера ЦС. Вы попадете на главную страницу центра сертификации.

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

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

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

При попытке создать запрос сертификата вы можете получить следующее предупреждение:

В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

Теперь на сервере откроем оснастку Центр сертификации и в разделе Запросы на ожидание найдем наш запрос и щелкнув на него правой кнопкой выберем Все задачи — Выдать.

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

Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Службы сертификации Active Directory. Базовые знания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление сервисом
Консоли сертификатов

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

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

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

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

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

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

Источник

Установка и настройка Active Directory Certificate Services

В этой статье я подробно расскажу о процессе установки и настройки Active Directory Certificate Services.

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

В примере я разбираю Active Directory Certificate Services на операционной системе Windows Server 2012.

Первым делом нам нужно установить службу сертификации Active Directory.

Для этого нужно запустить диспетчер сервера.

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

Выбираем пункт установка ролей или компонентов, а затем выбираем наш сервер.

В следующем окне выбираем пункт службы сертификатов Active Directory.

В окне выбора компонентов жмем далее.

В окне служба ролей выбираем пункт центр сертификации.

Запускаем процесс установки.

После этого по аналогии устанавливаем веб-службу регистрации сертификатов.

Установка завершена. Перейдем к настройке.

Настройка службы сертификатов Active Directory

Заходим в настройки.

Выбираем службу центр сертификации.

Вариант установки – центр сертификации предприятия.

Тип центра сертификации – корневой. Это необходимо для того, что бы в дальнейшем мы могли самостоятельно выдавать и подписывать сертификаты.

В следующем окне нужно выбрать пункт создать новый закрытый ключ.

Затем необходимо указать параметры шифрования. Вы можете указать свои параметры, или параметры как у меня на рисунке ниже.

В следующем окне указывается имя центра шифрования.

Затем указывается срок действия центра сертификации. По умолчанию он равен 5 годам. Так и оставим.

После нажатия кнопки далее вам нужно будет указать физическое место на жестком диске для хранения базы данных.

Подтверждаем настройку.

Перейдем к настройке web-службы регистрации сертификатов.

Настройка web-службы регистрации сертификатов

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

Тип проверки подлинности – имя пользователя и пароль.

Учетная запись службы CES – использовать встроенное удостоверение пула приложений.

В окне выбора сертификата проверки подлинности сервера выберите существующий сертификат, затем нажмите кнопку настроить.

Настройка выполнена.

Картинка с сайта: abuzov.com

Выберите тип проверки подлинности – имя и пароль пользователя.

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

Перезагрузите сервер.

Установка и настройка удостоверяющего центра

Запустите консоль управления 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.

Источник