Update 30.05.2012: исправлен процесс получения шаблонов CA.
Ссылки на другие материалы из этой серии:
В предыдущих частях мы рассмотрели принципы работы autoenrollment'а, который возможен только в доменной среде. Это значит, что для осуществления этой задачи мы должны иметь как минимум:
Я считаю, что следует ещё раз ознакомиться о порядке энроллмента сертификатов в домене из оснастки Certificates консоли MMC:
Примечание: более подробно все эти CryptoAPI DCOM интерфейсы описаны в спецификациях протокола [MS-WCCE].
Как вы можете видеть, этим мы зажаты доменом Active Directory, поскольку без него не можем найти ни один Enterprise CA и не можем получить список доступных шаблонов. Другая проблема — непосредственное подключение к CryptoAPI DCOM интерфейсам сервера CA, что не очень хорошо сказывается на безопасности.
Я сейчас не буду вдаваться в подробности организации серверов CA в лесу Active Directory, но требование DCOM коннекта делает невозможным изоляцию серверов CA от клиентов. Следовательно недоменные клиенты не могут энролить сертификаты через MMC, а доменные клиенты ограничены только серверами CA, которые зарегистрированы в текущем лесу. Для наглядности прилагаю картинку:
С выходом Windows 7 и Windows Server 2008 R2 мы имеем возможность как минимум частично разбить эти границы и получить более эффективную и пластичную инфраструктуру. Если предыдущая схема предполагает непосредственное подключение клиента к серверу CA, при использовании XCEP у нас появляется дополнительный промежуточный элемент — CEP (Certificate Enrollment Policy) Server. Данный сервер освобождает клиента от необходимости непосредственной связи с Active Directory и с серверами CA. В грубом представлении это выглядит примерно так:
При включениии сервера политик 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, которые содержат всю необходимую информацию:
И эти данные клиент использует для подготовки и отправки запроса на сервер CA.
В предыдущем разделе мы узнали о сути сервера XCEP, который позволяет даже недоменным клиентам и/или клиентам чужого леса получать политики энроллмента. Скажем, наш клиент находится в рабочей группе и по HTTPS получил всю необходимую информацию и уже готов отправлять запросы на получение сертификатов. Но, как мы знаем, при энроллменте клиент использует прямое подключение к DCOM сервера CA. Понятное дело, что никто выставлять сервер CA с открытым DCOM в интернет не будет. Как запрашивать сертификаты? А очень просто — по той же самой логике, как и с сервером XCEP у нас появляется ещё один (независимый от XCEP) промежуточный элемент — CES (Certiicate Enrollment Service) Server. В грубом представлении картинка будет выглядеть примерно так:
Клиент из политики, которую получил от XCEP, выбирает HTTP URL нужного сервера CA и начинает собирать запрос. После чего запаковывает всё в XML и по HTTPS отправляет запрос на сервер CES. CES в свою очередь обрабатывает полученный запрос, расшивает XML и уже классическим методом (через DCOM) пересылает запрос на сервер CA и получает от него ответ. Этот ответ CES перенаправляет клиенту снова в XML формате. По сути CES только проксирует запросы клиента, трансформируя их из XML в DCOM и ответы из DCOM в XML.
Примечание: по причине отсутствия в протоколе механизма шифрования и/или подписи передаваемых данных, между клиентом и CES используется HTTPS-транспорт.
Для улучшения понимания предлагаю простую картинку:
На данной картинке сервер getcerts.contoso.com является одновременно и сервером XCEP и CES. XCEP считывает настройки энроллмента для текущего леса из Active Directory с использованием стандартного LDAP. Клиент получает эту информацию с использованием XML over HTTPS. По тому же XML over HTTPS отправляет запрос службе CES, которая с использованием стандартного DCOM общается с Entrprise CA и транслирует (проксирует) ответы обратно клиенту. Может быть следующая картинка даст более понятное представление об этом непростом механизме:
На этой схеме в 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.
Что бы почитать?
Вадимс, по-моему у вас тут допущена неточность: 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: