Установка служб сертификации active directory. Использование готовых шаблонов сертификатов. Проверка работы ЦС

Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (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.

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

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

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

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

  • Теги:

Please enable JavaScript to view the comments powered by Disqus.

Трекбэк

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

Этой небольшой статьей я планирую начать цикл статей, посвященных настройке Windows Server 2008 R2 . Планируется несколько статей — пошаговых мануалов, таких как миграция с Exchange 2003 на Exchange 2010, публикация сервисов Exchange на TMG, настройка Remote Desktop Services и опять же публикация их на TMG и т.п.

Мы рассмотрим установку служб сертификации Active Directory (AD CS), так как они мне понадобятся во всех последующих статьях.

Исходные данные : как всегда, имеется в наличии домен testcompany.local , контроллер домена dc01 под управлением Windows Server 2008 R2, единственный, для тестовой среды достаточно.

Будет рассматриваться упрощенная модель развертывания служб сертификации, достаточная для большинства небольших и средних организаций, с установкой единственного центра сертификации с типом Enterprise. Для развертывания инфраструктуры с подчиненными центрами сертификации эта статья не подходит. Впрочем, если всё же захочется, в Microsoft Technet всё есть, дерзайте. Также можно ознакомиться со статьей на сайте Вадима Поданса: Обсуждение схем иерархии Certification Authority .

В тестовой среде я буду устанавливать службы сертификации (AD CS) на контроллер домена, dc01 , в реальной же сети, есть варианты. Если поставить на контроллер домена, то корневой сертификат автоматом распространится на все компьютеры домена без каких-либо усилий с вашей стороны. На отдельном сервере придется публиковать его в AD. Редакцию лучше выбрать Windows Server 2008 R2 Enterprise Edition, в которой можно будет создавать свои шаблоны сертификатов, а также там присутсвуют другие возможности, недоступные в редакции Standard. Различия можно увидеть по этой ссылке: http://technet.microsoft.com/en-us/library/cc755071.aspx . Не всем это правда будет нужно, но тем не менее, всегда лучше иметь больше возможностей, чем меньше 🙂

Запускаем Server Manager > Roles > Add Roles. Запустится визард, в нем на шаге Select Server Roles ставим галку напротив строчки Active Directory Certificate Services и нажимаем кнопку Next:

На следующем шаге Introduction to Active Directory Certificate Services внимательно читаем, что там написано и нажимаем Next.

На шаге Select Role Services дополнительно ставим галку Certification Authory Web Enrollment, остальные компоненты нам пока не понадобятся:

Появится окно с компонентами, которые необходимо добавить для этой роли, в нем нажимаем Add Required Role Services:

Следующий шаг — Specify Setup Type — выбор типа Certificate Authority, выбираем Enterprise, как планировали выше и нажимаем Next:

Следующий шаг — Specify CA Type — выбор корневого или подчиненного CA, выбираем корневой естественно, нажимаем Next:

Далее на шагах Setup Privat Key и Criptography соглашаемся с значениями по умолчанию и переходим к шагу Configure CA Name . Здесь задаем понятное имя нашего корневого центра сертификации, в данном случае TestCompany Root CA:

На шаге Set Validate Period задаем срок действия сертификата корневого CA, в моем примере можно согласиться с значением по умолчанию в 5 лет, в производственной среде можно сделать побольше, лет 10-15:

На всех дальнейших шагах соглашаемся с значениями по умолчанию, нажимаем везде Next и на последнем шаге Install:

В предыдущей статье «Узел сеансов удаленных рабочих столов в Windows Server 2012 R2» было рассказано о настройке удаленных рабочих столов на основе сеансов. В этом случае клиенту необходимо зайти на страницу веб-доступа по защищенному протоколу https.

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

Чтобы https-страница открывалась без упоминаний об ошибке сертификата, необходимо на сервере с установленной ролью веб-доступа получить ssl-сертификат. Сделать этого можно абсолютно бесплатно при помощи Службы сертификации Active Directory, про установку которой было написано в статье «Установка Службы сертификации Active Directory (AD CS)».

Напомню, о каких серверах пойдет речь: FS-01 (сервер со службой сертификации AD CS) и TS-00 (сервер с ролью веб-доступа служб удаленных рабочих столов).

1. Настройка Центра сертификации

На сервере FS-01 открываем оснастку «Центр сертификации»:

Выбираем центр сертификации (в моем случае с названием sektor-gaza-FS-01-CA-2), кликаем правой кнопкой мыши на разделе «Шаблоны сертификации» и далее выбираем пункт «Управление»:

Откроется Консоль шаблонов сертификатов:

В области «Отображаемое имя шаблона» кликаем правой кнопкой мыши на «Веб-сервер» и далее из контекстного меню выбираем пункт «Свойства»:

В окне «Свойства: Веб-сервер» переходим на вкладку «Безопасность» и для группы «Прошедшие проверку» ставим галочку «Разрешить» напротив пункта «Заявка»:

Таким образом, мы разрешаем данной группе безопасности подавать заявки на запрос сертификатов. При необходимости можно добавить другую группу безопасности и выполнить данную настройку для нее, а для группы "Прошедшие проверку" оставить разрешение только на "Чтение".

2. Настройка веб-сервера IIS

На сервере TS-00 открываем оснастку «Диспетчер служб IIS»:

Нажимаем на названии сервера и двойным кликом левой кнопкой мыши запускаем «Сертификаты сервера»:

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

Чтобы создать ssl-сертификат, которому будут доверять другие клиенты вашей доменной сети, в области «Действия» выберите пункт «Создать сертификат домена».

Откроется окно создания сертификата домена:

Заполните все доступные поля и нажмите «Далее». Поскольку это будет ваш внутренний сертификат от Центра сертификации AD CS, то в качестве значений можно использовать любые данные. Но в поле «Полное имя» лучше указать название вашего сайта (мой сайт доступен по адресу , и в качестве имени я указал «TS-00»), т. к. в противном случае браузер может возвращать ошибку о несоответствии имени сайта, на который выдан сертификат.

Выбор Центра сертификации:

В этом окне в поле «Локальный центр сертификации» необходимо указать имя вашего Центра сертификации AD CS и имя сервера (с установленной Службой сертификации), а в поле «Понятное имя» укажите простое и короткое имя Центра сертификации. После нажимаем кнопку «Готово». Обратите внимание, что в первом поле присутствует символ «\», разделяющий имя центра сертификации и имя сервера. Также можно воспользоваться кнопкой «Выбрать» и далее указать необходимый Центр сертификации, но данная кнопка не всегда бывает доступной.

Через несколько секунд ssl-сертификат будет создан, и откроется окно «Сертификаты сервера»:

Теперь здесь отображается только что созданный сертификат. Как видим, его поставщиком является Центр сертификации AD CS sektor-gaza-FS-01-CA-2, т. е. все прошло успешно.

Переходим на сервер FS-01 в оснастку «Центр сертификации» и открываем раздел «Выданные сертификаты»:

Здесь также можно увидеть созданный ssl-сертификат для сервера TS-00.

Возвращаемся на сервер TS-00 в оснастку «Диспетчер служб IIS», открываем список «Сайты, нажимаем на названии нашего сайта (в моем случае это «Default Web Site») и в области «Действия» выбираем пункт «Привязки»:

В окне «Привязки сайта» выбираем протокол «https» и нажимаем кнопку «Изменить»:

В окне «Изменение привязки сайта» открываем раскрывающий список «SSL-сертификат» и выбираем наш созданный сертификат (в моем случае это «FS-01-CA-2»):

Нажимаем «ОК» и в окне «Привязки сайта» выбираем «Закрыть».

Теперь необходимо перезапустить веб-сайт:

Кликаем правой кнопкой мыши на названии нашего сайта, из контекстного меню выбираем пункт «Управление веб-сайтом» и далее нажимаем «Перезапустить».

3. Проверка правильности установки ssl-сертификата

Чтобы проверить, правильно ли установлен ssl-сертикат, можно зайти на страницу веб-доступа (в моем случае это

Служба сертификации Active Directory

Служба сертификации Active Directory (AD CS) в Windows Server 2008 R2

Windows Server 2008 R2 содержит встроенный центр сертификации (СА), называе­мый службой сертификации Active Directory (Active Directory Certificate Services - AD CS). Первый вариант AD CS появился в Windows Server 2008, а раньше эта технология называ­лась просто службой сертификации (Certificate Services). AD CS может использоваться для создания сертификатов и последующего управления ими и отвечает за обеспечение их под­линности. Зачастую AD CS в Windows Server 2008 R2 используется без особой необходимости проверки сертификатов организации какой-либо независимой стороной. Поэтому если сертификаты требуются только для участников внутри организации, часто применяется развертывание самостоятельного СА для шифрования сетевого трафика. Широко исполь­зуются и сторонние центры сертификации наподобие VeriSign, но они требуют дополни­тельного вложения средств.

Хотя в новом названии службы сертификации Windows упоминается Active Directory, сле­дует понимать, что для работы AD CS совсем не требуется интеграция с существующей средой леса доменной службы Active Directory (Active Directory Domain Services (AD DS)). Обычно это все же так, но важно понимать, что AD CS не зависит от структуры леса AD DS.

В Windows Server 2008 R2 добавлено несколько новых возможностей AD CS:

  • Веб-служба развертывания сертификатов и веб-служба политики развертыва­ния сертификатов. Это наиболее значительное усовершенствование позволяет раз­вертывать сертификаты непосредственно по протоколу HTTP и дает возможность клиентам, не принадлежащим домену или подключенным к Интернету, обращаться к серверу СА и запрашивать сертификаты.
  • Улучшенная поддержка объемных СА, используемых для NAP. В Windows Server 2008 R2 повышена скорость работы AD CS с базой данных, когда возникают ситуации массированной работы, как с NAP.
  • Поддержка развертывания сертификатов между лесами. AD CS в Windows Server 2008 R2 позволяет консолидировать СА между несколькими лесами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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



Просмотров