Active Directory Certificate Services
2010-07-30, 12:00 / ArgonВ этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации PKI от Microsoft — Active Directory Certificate Services:
- Общие представления о PKI
- Автоматический запрос сертификатов
- Ручная установка сертификата корневого ЦС
- Проверка отзыва сертификатов
- Веб-службы регистрации сертификатов
- Запрос сертификата с альтернативным именем
- Обобщенные лучшие практики
- Полезные ссылки
Общие представления о PKI
Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public 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 будет выдаваться такая ошибка:
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, с помощью нее нужно выполнить следующую команду:
Проверка отзыва сертификатов
Некоторые сетевые службы (удаленные рабочие столы, 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) любого сертификата можно с помощью следующей команды:
где 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. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:
net stop certsvc
net start certsvc
Запрос через консоль MMC
Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…
- В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
- Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
- Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.
Запрос через утилиту certreq
Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq. Чтобы создать сертификат нужно действовать по следующему алгоритму:
1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU"
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = 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. На машине, для которой предполагается запрашивается сертификат, выполнить команду
Нам предложат сохранить подготовленный файл запроса в формате .req. Одновременно с этим в хранилище сертификатов компьютера будет сохранен закрытый ключ для будущего сертификата.
3. Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).
4. Выполнить установку полученного сертификата на целевой компьютер следующей командой
5. PROFIT. В результате описанных действий в хранилище сертификатов компьютера будет создан сертификат с закрытым ключом, пригодный для авторизации сервера по нескольким именами, прописанным .inf файле.
Обобщенные лучшие практики
Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2
- На контроллере домена развернут корневой центр сертификации
- Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
- В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
- На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
- Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
- Online Responder для проверки отзыва сертификатов по протоколу OCSP
- Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
- Remote Desktop Gateway
- Outlook Web Access
- DirectAccess
- SharePoint
Полезные ссылки
- PKI предприятия
- How to configure the Windows Server 2008 CA Web Enrollment Proxy
- How to add a Subject Alternative Name to a secure LDAP certificate
- How to Request a Certificate With a Custom Subject Alternative Name
- Устанавливаем Certification Authority — Vadims Podans’s blog
- OCSP (часть 1), OCSP (часть 2) — Vadims Podans’s blog
| Рубрика | Core Infrastructure |
|---|---|
| Метки | active directory, ad, pki, public key infrastructure, active directory certificate services, службы сертификатов, security, безопасность, windows server |
| Опубликовано | 2010-07-30, 12:00; обновлено 2011-02-05, 00:10 |
| Комментарии | 29 комментариев » | Лента комментариев RSS |
| Ссылки | Постоянная ссылка | Обратная ссылка |
29 комментариев
«Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат.»
Игорь, добрый день!
Получаю именно такую ошибку, хотя, как мне кажется, настроил все верно, не могли бы помочь разобраться в данной проблеме?
Могу прислать скриншот, где четко видно, как все настроено, но не знаю, куда именно надо слать.
Заранее признателен за содействие.
1. Зайди на комп, при подключении к которому есть проблемы, в оснастке сертификатов компьютера экспортируй сертификат, используемый для RDP в файл (без закррытого ключа).
2. Скинь этот сертификат на комп, при подключении с которого выдается ошибка проверки сертификатов.
Выполни certutil -url name.cer
Должна пройти проверка отзыва сертификата, либо по CRL, либо по OCSP.
Попробую, конечно, но проделать данную операцию на 150 пользователях нереально, хотелось бы, чтобы эти вещи отрабатывали автоматически, тем более, что для этого вроде все настроено, нужно разобраться в причинах, почему именно не отрабатывает проверка отзыва, а принудительно — это уже крайний случай…
Один раз попробовать проверить принудительно в контролируемой среде, чтобы найти и устранить причину. Про всех юзеров я и не говорил ;)
C:\Users\administrator>certutil -url c:\ts.cer
CertUtil: -URL — команда успешно выполнена.
Проверено базовый CRL бла-бла-бла
А это смотрел? Раньше на эту инструкцию технет ссылался в шагах по установке ЦА, сейчас пришлось отдельно поискать.
Даж теряюсь, что еще предложить. Начнем с простого.
1. Проверить, что сертификат на терминале действительно доверен клиентским компьютеором, вся цепочка от сертификата до Root CA. Причем доверие должно быть не на уровне хранилища пользователя, а на уровне компьютера.
2. Если есть машины, при доступе с которых не возникает этой проблемы, то сравнить конфиги с больными.
3. Если еще не стоит, попробовать развернуть Online Responder. Правда при этом нужно сертификаты перевыпускать, чтоб они содержали инфу о нём.
мы можем общаться по почте, а не на страницах сайта? в строке e-mail я всегда публикую свой адрес…
Конечно можем, но я считаю, что публичное обсуждение может быть полезно и другим читателям.
Статья написана больше года назад, если бы она была кому-то интересна, ее бы давно обсуждали, но это никому не интересно, кроме меня, потому что у меня реальная необходимость, а здесь я не могу даже скриншоты выложить…если это возможно, хотелось бы оперативного общения, иначе мы эту кашу будем жевать еще год…
Удалось проверить только с двух разных машин, на вин7 вываливается с ошибкой, на ХР работает без ошибок, доверие на уровне компьютера и там, и там.
Какие конфиги я должен сравнить? Может, ХР вовсе и не проверяет отзыв сертификатов?
- XP действительно не проверяет CRL при подключении по RDP.
- Скриншоты можно выложить на каком-нибудь image-хостинге типа imageshack.us, а сюда копипастить ссылки.
- По поводу интересности статьи и количества комментов — не самый весомый показатель. Лично я читаю море интересный статей, но комменты оставляю дай бог к одной из 300.
Теперь по делу, можно выложить скрины свойств сертификатов, либо сами сертификаты. Если беспокоишься о конфиденциальности, то можно ссылки скинуть мне в форму обратной связи.
Посмотрел. А если нажать на «просмотреть сертификат» в окне с предупреждением, выдает все тот же серт? Если его…
1. Сохранить на комп и проверить на валидность с помощью certutil.
2. Сохранить на комп и импортировать в хранилище «доверенные ЦC» компа, just for fun
Если в результате этих действий ничего нового не обнаружится, то присылай полные сертификаты, без приватных ключей, ессно.
«А если нажать на «просмотреть сертификат» в окне с предупреждением, выдает все тот же серт?»
Так он там же на картинке справа и показан.
«Сохранить на комп и проверить на валидность с помощью certutil.»
Сертификат валиден.
«Сохранить на комп и импортировать в хранилище «доверенные ЦC» компа, just for fun»
Ну и живет он там себе преспокойненько…
Вобщем ничего нового.
Что тут могу еще осоветовать…
1. Почистить хранилища компа/юзера от дублей сертификатов, который могут находится в разных категориях
2. Поставить радом второй Ent CA, можно подчиненный. И посмотреть, что будет.
3. Все-таки показать мне живые сертификаты.
Ну и лихи е пути…
4. Отключить в GPO проверку CRL для RDP
5. Через GPO установить на клиентские компы самоподписанные сертификаты TS в качестве доверенных.
«Все-таки показать мне живые сертификаты.»
Рутовый и RDP-шный?
отправил ссылку на архив с сертификатами в форму обратной связи
1. Меня смущает то, что в CRL/AIA сертификата на TS идет указание IP-адреса. Ни разу так не делал. Настоятельно рекомендую публиковать CRL/AIA по DNS-имени.
2. Также, проверить, что обращение к этому IP/DNS не идёт через прокси-сервер.
3. Если ЦС у тебя на винде, интегрированный с AD, то его нужно настроить на публикацию CRL/AIA в AD. Обычно так настроено по умолчанию.
1) попробую, конечно, но меня в IP-адресе, честно говоря, вообще ничего не смущает, по большому счету, должно работать еще лучше, чем по DNS :)
2) никаких прокси, все напрямую!
3) ну, собственно говоря, все действительно построено на 2008R2, но зачем абсолютно внешнему клиенту с улицы нужна публикация CRL/AIA в AD, если он все равно проверку должен осуществлять по http ?
Мда…а ведь ты оказался прав, причиной всей нашей полемики было не что иное, как использование в адресес списка отзыва IP. Ну не понимает этого тупая система проверки, хотя из браузера все нормально открывается, и все изначально было настроено вполне корректно. Совсем не понятны такие жесткие требования, ведь по IP гораздо проще проверить список отзыва, не привлекая к этому процессу разрешение имен. Ну да ладно, придется принять это как данность, от которой никуда не денешься, просто нужно взять на заметку.
Спасибо за помощь!!!
Отлично, что все разрешилось! И мне польза будет, теперь точно буду знать о вреде IP-адресов в CRL, а не гадать.
Прочитал и опять меня зацепило — решил прокомментировать:) …
«При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС»
Во-первых — зачем заморачиваться созданием политик, когда можно просто опубликовать сертификат в AD командой «certutil -dspublish -f FileName.cer RootCA» и именно при обновлении тех самых политик этот сертификат автоматически скачается и установится в доверенные?
Во-вторых — при разворачивании «Enterprise CA» (с правами Enterprise Admin) сертификат публикуется в AD автоматически и ни каких телодвижений предпринимать не нужно ;) .
«но отозваны ли они центром сертификации»
Видимо, имеет место опечатка и имелось в виду «не».
«CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый»
Лично я настраиваю центры сертификации на публикацию CRL’ей в DFS (с репликацией, в случае необходимости), откуда они спокойно раздаются IIS’ом — ни каких «регулярных обновлений» не нужно — всё автоматом. Пример такой настройки я показывал здесь.
«От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.»
Ну а в чём сложность сделать то же самое, когда внешнее доменное имя отличается от внутреннего? Обеспечение «прозрачности» доменного суффикса, с моей подачи, описаны здесь.
«Следует иметь ввиду, что проверка отзыва по протоколу OCSP проходит успешно только в том случае, если сертификат ЦС, выдавшего проверяемый сертификат, установлен в хранилище доверенных сертификатов локального компьютера»
Я бы ещё хотел добавить, что успешная проверка по OCSP пройдёт только в том случае, когда сам OCSP-сервер имеет доступ к CRL-файлам — именно оттуда он берёт информацию, избавляя клиента от их скачивания ;) .
«Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль»
А я бы сказал, что роль бесполезная и лично я от её использования давно отказался. Поданс, кстати, с этим мнением солидарен (тут и тут) :) .
«По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN.»
Всеобщее заблуждение ;) ! Центры сертификации прекрасно выдают SAN-сертификаты и без включения данной опции — когда-то Вадим мне «не верил», но по предыдущей ссылке сам признался в своём заблуждении и вредности данного флага.
«Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС»
Совершенно не обязательно ;) .
«Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq.»
На счёт универсального не поспоришь, а вот на счёт гибкости полностью не согласен :) ! На мой взгляд, самый гибкий — запрос через MMC-консоль в новых системах. И просто и удобно и наглядно и без создания файлов с кучей параметров, которые в голове не удержишь и нужно обращаться к заранее заготовленным шаблонам.
«Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).»
Я предпочитаю, в случае необходимости, отправлять запрос командой «certreq -Submit -attrib «certificatetemplate:WebServer» Request.req Response.cer».
«Если ЦС у тебя на винде, интегрированный с AD, то его нужно настроить на публикацию CRL/AIA в AD»
Тоже большое заблуждение ;) . Эти ссылки в интернет-сценариях только мешают и наилучшим вариантом является их полное «выпиливание» из сертификатов — оставить только публичные HTTP-ссылки.
Stanky, спасибо за комменты! Когда-нибудь руки дойдут допилить эту статью. Я тоже со временем развиваюсь, во многом с тобой согласен.
— Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
— Совершенно не обязательно ;) .
Можешь научить, как это сделать не с доменного компа?
Использовать XCEP/WSTEP.
P. S. Ещё раз хочу упомянуть, что подписки на комментарии тут очень не хватает — в их потоке я предыдущий «проморгал» ;) .
Запрос сертификатов с локальной доменной станции с использование утилиты certreq. Генерируем сертификат пользователя на рабочей станции Win7.Сертификат рабочий (подпись есть), можно шифровать документы и просматривать зашифрованные документы. Генерируем сертификат пользователя на рабочей станции WinXP. Сертификат рабочий (подпись есть), но просматривать зашифрованные документы невозможно. В чем может быть причина?