Active Directory Certificate Services

by Опубликовано

В этой статье рассмотрим следующие темы о тонкостях и лучших практиках для реализации PKI от Microsoft — Active Directory Certificate Services: Общие представления о PKI, Автоматический запрос сертификатов, Ручная установка сертификата корневого ЦС, Проверка отзыва сертификатов, Веб-службы регистрации, Запрос сертификата с альтернативным именем, Обобщенные лучшие практики, Полезные ссылки

Общие представления о PKI

Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Private Key Infrastructure, переводят как инфраструктура открытого ключа, однако если переводить дословно, то закрытого) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:

  • Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
  • отношения всеобщего доверия к ЦС
  • выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
  • различные службы поддержки PKI
    • списки отзывов сертификатов (CRL)
    • сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
    • Web Enrollment (средство запроса сертификатов через Web)

Автоматический запрос сертификатов

От центра сертификации нет толку, если клиентские компьютеры в вашей сети не имеют к нему доверия и/или не получают сертификаты. При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС и автоматический запрос сертификатов компьютера у него. Однако, при некоторых сценариях эти политики необходимо настраивать вручную и в этом поможет статья TechNet Configure Computer Certificate Autoenrollment.

Ручная установка сертификата корневого ЦС

Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации. Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:

Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов «server.argon.com.ru». Подключаться к серверам без удостоверений небезопасно.

This computer can’t verify the identity of the RD «server.argon.com.ru». It’s not safe to connect to servers that can’t be identified.

Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации

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

Через MMC

Открыть MMC с правами администратора » добавить оснастку Сертификаты » выбрать в качестве области Локальный компьютер » импортировать нужный сертификат в хранилище Доверенные корневые центры сертификации. Более подробно в статье TechNet Manage Trusted Root Certificates.

Через свойства сертификата

Запустить командную строку с правами админа » вызвать в нейс:\path\to\cert.crt» откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.

Через командную строку

Потребуется утилита CertMgr, с помощью нее нужно выполнить следующую команду:

certmgr.exe -add -c "с:\path\to\cert.crt" -s -r localMachine root

Проверка отзыва сертификатов

Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:

Не удалось проверить, не был ли отозван этот сертификат.
A revocation check could not be perfomed for the certificate.

Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:

  • CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
  • Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)

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

За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation. От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.

Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network. Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.

Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:certutil -url name.cer

где name.cer — имя выданного сертификата.

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

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

Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:

  • запрашивать сертификаты пользователями без участия администратора
  • предоставлять по требованию сертификат корневого ЦС
  • выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
  • делать это все через интернет
  • сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС

Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов

  • в случае установки Web Enrollment на отличный от ЦС компьютер, необходимо обязательно выполнить шаги, описанные в статье TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account, иначе служба не будет работать, выдавая следующую ошибку:

Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена.
An unexpected error has occurred: The Certification Authority Service has not been started.

  • та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
  • при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS

Запрос сертификата с альтернативным именем

Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).

По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Запрос через консоль MMC

Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…

  • В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
  • Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
  • Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.

Запрос через утилиту certreq

Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq. Чтобы создать сертификат нужно действовать по следующему алгоритму:

  1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.[Version]
    Signature="$Windows NT$"
    [NewRequest]
    Subject = "CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU"
    KeySpec = 1
    KeyLength = 2048
    HashAlgorithm = SHA256Exportable = TRUE
    MachineKeySet = TRUE
    SMIME = FALSE
    PrivateKeyArchive = FALSE
    UserProtected = FALSE
    UseExistingKeySet = FALSE
    RequestType = PKCS10
    KeyUsage = 0xa0
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    FriendlyName = "server.argon.local with SAN"    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.1 ; Server Authentication[RequestAttributes]
    CertificateTemplate = WebServer[Extensions]
    2.5.29.17 = «{text}»
    _continue_ = «DNS=*.argon.com.ru&»
    _continue_ = «DNS=argon.com.ru&»
    _continue_ = «DNS=server.argon.local&»
    _continue_ = «DNS=server&»
    _continue_ = «DNS=localhost»
  2. На машине, для которой предполагается запрашивается сертификат, выполнить командуcertreq -new request.infНам предложат сохранить подготовленный файл запроса в формате .req. Одновременно с этим в хранилище сертификатов компьютера будет сохранен закрытый ключ для будущего сертификата.
  3. Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).
  4. Выполнить установку полученного сертификата на целевой компьютер следующей командойcertreq -accept request.cer
  5. PROFIT. В результате описанных действий в хранилище сертификатов компьютера будет создан сертификат с закрытым ключом, пригодный для авторизации сервера по нескольким именами, прописанным .inf файле.

Обобщенные лучшие практики

Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2

  • На контроллере домена развернут корневой центр сертификации
  • Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
  • В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
  • На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
    • Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
    • Online Responder для проверки отзыва сертификатов по протоколу OCSP
  • Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
    • Remote Desktop Gateway
    • Outlook Web Access
    • DirectAccess
    • SharePoint

Опубликовано Администратор