Contents of this directory is archived and no longer updated.

Update 30.05.2012: исправлен процесс получения шаблонов CA.


Ссылки на другие материалы из этой серии:

Windows Client Certificate Enrollment (WCCE)

В предыдущих частях мы рассмотрели принципы работы autoenrollment'а, который возможен только в доменной среде. Это значит, что для осуществления этой задачи мы должны иметь как минимум:

  • Контейнер в AD с информацией о шаблонах сертификатов. CA локально не хранит сами шаблоны, а хранятся они только в AD;
  • Контейнер в AD с информацией о выдающих Enterprise CA (Issuing CA).

Я считаю, что следует ещё раз ознакомиться о порядке энроллмента сертификатов в домене из оснастки Certificates консоли MMC:

  1. Клиент инициализирует необходимые COM интерфейсы для CryptoAPI;
  2. Используя LDAP получает список всех доступных в лесу шаблонов сертификатов;
  3. Используя LDAP получает список всех доступных в лесу Enterprise CA. Именно по этой причине Enterprise CA не могут существовать вне домена Active Directory, поскольку Active Directory используется для их обнаружения и хранения шаблонов;
  4. Используя LDAP получает список доступных шаблонов CA;
  5. На данном этапе клиент в окне MMC отображает список шаблонов, которые вы можете выбирать;
  6. Вы вибираете нужный шаблон и клиент используя множество COM интерфейсов. Пример их использования можете посмотреть в следующем посте: Generating a certificate (self-signed) using powershell and CertEnroll interfaces;
  7. Когда запрос подготовлен, клиент подключается к DCOM интерфейсу ICertRequest::Submit() сервера CA и отправляет этот запрос на сервер.
  8. После отправки запроса на сервер, клиент через тот же интерфейс получает статус своего запроса.

Примечание: более подробно все эти CryptoAPI DCOM интерфейсы описаны в спецификациях протокола [MS-WCCE].

Как вы можете видеть, этим мы зажаты доменом Active Directory, поскольку без него не можем найти ни один Enterprise CA и не можем получить список доступных шаблонов. Другая проблема — непосредственное подключение к CryptoAPI DCOM интерфейсам сервера CA, что не очень хорошо сказывается на безопасности.

Я сейчас не буду вдаваться в подробности организации серверов CA в лесу Active Directory, но требование DCOM коннекта делает невозможным изоляцию серверов CA от клиентов. Следовательно недоменные клиенты не могут энролить сертификаты через MMC, а доменные клиенты ограничены только серверами CA, которые зарегистрированы в текущем лесу. Для наглядности прилагаю картинку:

Windows Client Certificate (WCCE) protocol limitations 

X.509 Certificate Enrollment Policy (XCEP)

С выходом Windows 7 и Windows Server 2008 R2 мы имеем возможность как минимум частично разбить эти границы и получить более эффективную и пластичную инфраструктуру. Если предыдущая схема предполагает непосредственное подключение клиента к серверу CA, при использовании XCEP у нас появляется дополнительный промежуточный элемент — CEP (Certificate Enrollment Policy) Server. Данный сервер освобождает клиента от необходимости непосредственной связи с Active Directory и с серверами CA. В грубом представлении это выглядит примерно так:

Certificate Enrollment Policy Server

При включениии сервера политик XCEP, он читает из Active Directory всю необходимую информацию и хранит её у себя. При этом XCEP использует стандартные механизмы общения с Active Directory, как это раньше делал клиент. На сервере XCEP работает веб-приложение, которое позволяет клиентам подключаться к нему по HTTP. Это означает, что для выполнения шагов 2 и 3 (см. последовательность работы клиента при использовании протокола WCCE) клиенту совсем не обязательно иметь прямое подключение к Active Directory, но достаточно только знать HTTP-адрес сервера XCEP. Если это кому-то интересно, скажу, что клиент и XCEP используют XML сообщения.

Примечание: HTTP здесь указан только для обозначения типа протокола. В действительности XCEP использует только HTTPS, поскольку протокол [MS-XCEP] не предусматривает защиту передаваемых данных как их шифрование и/или подпись. Для решения этих задач используется HTTPS-транспорт.

Из этого следует, что CEP политики может получать даже недоменный клиент или член другого леса. Протокол [MS-XCEP] использует различные схемы XML, которые содержат всю необходимую информацию:

  • Список шаблонов и их настройки;
  • Все используемые OID'ы для использования нестандартных политик выдачи или политики применения ключа (EKU);
  • Список и адреса серверов CA, которые позволяют.

И эти данные клиент использует для подготовки и отправки запроса на сервер CA.

WS-Trust X.509v3 Token Enrollment Extensions (WSTEP)

В предыдущем разделе мы узнали о сути сервера XCEP, который позволяет даже недоменным клиентам и/или клиентам чужого леса получать политики энроллмента. Скажем, наш клиент находится в рабочей группе и по HTTPS получил всю необходимую информацию и уже готов отправлять запросы на получение сертификатов. Но, как мы знаем, при энроллменте клиент использует прямое подключение к DCOM сервера CA. Понятное дело, что никто выставлять сервер CA с открытым DCOM в интернет не будет. Как запрашивать сертификаты? А очень просто — по той же самой логике, как и с сервером XCEP у нас появляется ещё один (независимый от XCEP) промежуточный элемент — CES (Certiicate Enrollment Service) Server. В грубом представлении картинка будет выглядеть примерно так:

Certificate Enrollment Service

Клиент из политики, которую получил от XCEP, выбирает HTTP URL нужного сервера CA и начинает собирать запрос. После чего запаковывает всё в XML и по HTTPS отправляет запрос на сервер CES. CES в свою очередь обрабатывает полученный запрос, расшивает XML и уже классическим методом (через DCOM) пересылает запрос на сервер CA и получает от него ответ. Этот ответ CES перенаправляет клиенту снова в XML формате. По сути CES только проксирует запросы клиента, трансформируя их из XML в DCOM и ответы из DCOM в XML.

Примечание: по причине отсутствия в протоколе механизма шифрования и/или подписи передаваемых данных, между клиентом и CES используется HTTPS-транспорт.

Для улучшения понимания предлагаю простую картинку:

Simple XCEP/CES communications

На данной картинке сервер getcerts.contoso.com является одновременно и сервером XCEP и CES. XCEP считывает настройки энроллмента для текущего леса из Active Directory с использованием стандартного LDAP. Клиент получает эту информацию с использованием XML over HTTPS. По тому же XML over HTTPS отправляет запрос службе CES, которая с использованием стандартного DCOM общается с Entrprise CA и транслирует (проксирует) ответы обратно клиенту. Может быть следующая картинка даст более понятное представление об этом непростом механизме:

Extended XCEP/CES scenario

На этой схеме в DMZ расположены RODC (Read-Only Domain Controller), сервер XCEP и CES. В корпоративную сеть из DMZ у нас разрешены только DCOM сообщения и только до Enteprise CA. А из DMZ в интернет доступен только HTTPS. Это достаточно безопасная и удобная схема, когда клиент из интернета может энролить сертификаты только с использованием HTTPS.

Можно задать резонный вопрос: а как сделать все эти XCEP и CES? Существует достаточно детальный документ, который описывает установку и настройку XCEP/CES: Certificate Enrollment Web Services in Windows Server 2008 R2.

В следующий раз мы посмотрим как работает автоэнроллмент при использовании XCEP/CES.

Что бы почитать?


Share this article:

Comments:

Maximus43

Вадимс, по-моему у вас тут допущена неточность: 1. Клиент инициализирует необходимые COM интерфейсы для CryptoAPI; 2. Используя LDAP получает список всех доступных в лесу шаблонов сертификатов; 3. Используя LDAP получает список всех доступных в лесу Enterprise CA. Именно по этой причине Enterprise CA не могут существовать вне домена Active Directory, поскольку Active Directory используется для их обнаружения и хранения шаблонов; 4. Используя свдения полученные на предыдущем этапе, клиент подключается к DCOM интерфейсу ICertRequest3::GetCAProperty() сервера CA и получает список доступных шаблонов CA; 5. На данном этапе клиент в окне MMC отображает список шаблонов, которые вы можете выбирать; 6. Вы выбираете нужный шаблон и клиент используя множество COM интерфейсов. Пример их использования можете посмотреть в следующем посте: Generating a certificate (self-signed) using powershell and CertEnroll interfaces; 7. Когда запрос подготовлен, клиент подключается к DCOM интерфейсу ICertRequest::Submit() сервера CA и отправляет этот запрос на сервер. 8. После отправки запроса на сервер, клиент через тот же интерфейс получает статус своего запроса. В пункте 4 написано, что список шаблонов клиент получает от CA через DCOM, но это не так, данная информация запрашивается так же из ActiveDirectory с помощью LDAP/LDAPS. Обращение к CA идет только на этапе отправки запроса.

Comments are closed.