Posts on this page:
- Немного про Web Enrollment Pages
- Certificate Autoenrollment от А до Я — подведение итогов
- Certificate Autoenrollment от А до Я (часть 6) — XCEP/WSTEP Autoenrollment
- Certificate Autoenrollment от А до Я (часть 5) — расширения в Windows 7/2008 R2
- Certificate chaining engine и certificate revocation checking — FAQ
Что-то в последнее время участились вопросы связанные с проблемами Web Enrollment Pages. В этом посте я рассмотрю 3 момента:
- Запрос сертификатов для компьютера (с установкой сертификата в хранилище LocalMachine);
- Запрос сертификатов от имени другого пользователя (Enroll On Behalf Of);
- Настройка Web Enrollment Pages при работе на отдельном от CA сервере.
История Web Enrollment Pages
В системах до Windows Vista/Server 2008 клиентская часть запроса сертификатов была уныла чуть более чем полностью. Из того, что вы могли делать:
- запрашивать сертификаты только тех шаблонов, где Subject строился автоматически на основе данных в Active Directory учётной записи, от имени которой происходил запрос;
- Если в шаблоне разрешено использовать несколько CSP (Cryptographic Service Provider), можно было выбирать тот, который нужен для конкретного сертификата или который вам просто больше нравится;
- Изменять длину ключа;
- Включать/выключать возможность экспорта сертификата вместе с закрытым ключом (в PKCS#12);
- Включать/выключать функцю Private Key Strong Protection (только для пользовательских сертификатов).
Если хотите использовать шаблон, Subject которого должен указываться в запросе (обычно используется для недоменных клиентов или клиентов других лесов Active Directory) или что-то ещё, вам было необходимо решать данный вопрос иными путями. Например, использовать текстовый файл настроек policy.inf совместно с утилитой CertReq.exe, или Web Enrollment Pages. Web Enrollment Pages был неотъемлемой частью компонента Certification Authority. При установке Web Enrollment Pages устанавливалась роль IIS (в реальности, чаще приходилось его устанавливать заранее, чтобы потом не настраивать его вручную) и в систему копировался набор ASP файлов и элемент ActiveX под названием Xenroll. Этот ActiveX является «прослойкой» между клиентом и сервером и отвечал за cookies и много чего ещё. В этих cookies сохраняется некоторая служебная информация, например, номер запроса, который был отправлен на сервер CA и по которому вы потом могли получить сертификат.
И используя Web Enrollment Pages вы могли запрашивать сертификаты для недоменных компьютеров (или клиентов других лесов Active Directory):
У нас там есть поля, которые позволяют вручную указать информацию о владельце сертификата. И галочка, которая указывала, что сертификат будет установлен в компьютерное хранилище. Для выпуска сертификатов для смарт-карт мы могли использовать галочку Enroll On Behalf Of с указанием пользователей для которых предназначен сертификат для смарт-карт.
Так же, как и с консолью MMC, вы не могли переопределять какие-то вещи, например, экспорт закрытого ключа, если это не разрешено в шаблоне и другое. Вобщем, как альтернатива, Web Enrollment Pages была весьма полезная и зачастую нужная вещь.
С выходом Windows Vista и Windows Server 2008 ситуация круто изменилась и началась всеобщая шумиха (она ещё до сих пор не утихает), что это всё перестало работать. В связи с некоторыми проблемами безопасности (любой запрос сертификата выполнялся в контексте пользователя, который аутентифицировался в IIS) и изменением функциональности консоли MMC, некоторые вещи были удалены с Web Enrollment Pages и изменён элемент Activex, который теперь называется CertEnroll. В новой консоли MMC (оснастка Certificates) вы можете выполнять абсолютно любые запросы. В том числе в клиенте реализована возможность ручного указания поля Subject и многих других полей (добавлять Application Policies, управлять экспортом закрытого ключа, его длиной, CSP и многое другое), а так же реализована возможность запрашивать сертификаты для смарт-карт от имени другой учётной записи (Enroll On Behalf Of).
По указанным причинам даже необходимость в Web Enrollment Pages скатилась до отвратительно низкой отметки. Но жадные детипользователи продолжают негодовать: верните всё как было! Я не могу с ними согласиться, поскольку дублировать реализованный функционал совсем не обязательно, а повышение в безопасности лишним не будет. Просто случилась миграция необходимого функционала с серверной части (Web Enrollment Pages) в клиентскую (Certificates snap-in).
Дополнительная информация по проблеме находится здесь: http://support.microsoft.com/kb/922706
Web Enrollment Pages и сервер CA на раздельных компьютерах
Эта проблема появилась начиная с выходом Windows Server 2008, когда этот компонент стал необязательным при установке роли Certification Authority и появилась возможность установить его не на сервере CA. Чаще на выделенном веб-сервере для обслуживания внешних клиентов.
При установке компонента на Web Enrollment Pages вы указываете сервер CA, с которым они будут работать и устанавливаете необходимые компоненты IIS для этого. Однако, сразу это не будет работать. Если быть точнее, то будет, но криво. Итак, какие вещи нужно настроить для такой конфигурации:
- Включить SSL для веб-сайта, в котором будут размещены Web Enrollment Pages:
- Для IIS 7 и IIS 7.5: How to Setup SSL on IIS 7.0
- Отключить анонимную и ядерную (kernel) аутентификацию и включить только Integrated Authentication:
- Для IIS 7 и IIS 7.5: Configure Windows Authentication (IIS 7)
- Настроить делегирование для учётной записи, от имени которой работает пул, в котором работает веб-сайт с Enrollment Web Pages, как это описано здесь: Install Web Enrollment Support on Another Computer (Optional)
Надеюсь это будет полезным.
Этим постом я подвожу итоги эпик-проповеди в 6 частях, посвящённой такой занимательной теме как Certificate Autoenrollment. Это достаточно популярная технология, которая позволяет автоматически подавать заявки на получение сертифкатов, что значительно снижает нагрузку на пользователей и администраторов. Хоть эта технология и популярна, её принципы работы в деталях далеко не всем известны, а некоторые моменты даже не освещены в библиотеке TechNet. И вот что у нас есть на текущий момент:
Вводная часть, которая описывает основные компоненты автоэнроллмента и требования к нему.
Данный пост раскрывает основные особенности шаблонов версии 1 и работу механизма Automatic Certificate Request (ACR).
Здесь рассказывается о шаблонах версии 2 и 3, включая описание каждого свойства шаблона и его влияния на работу механизма автоэнроллмента.
В этом посте уже рассказывается о работе т.н. классического автоэнроллмента, который позволяет автоматически подавать заявки и издавать сертификаты как компьютерам, так и пользователям.
С выходом Windows 7/Windows Server 2008 R2 у нас появляются новые механизмы энроллмента сертификатов, которые значительно расширяют возможности и удобство распространения сертификатов.
И, собственно, описание принципа и порядка работы клиентов Windows 7/Windows Server 2008 R2 с новыми механизмами XCEP/WSTEP как в доменной, так и не в доменной среде.
Enjoy, greetings!
Примечание: материал данной статьи относится только к клиентам под управлении Windows 7/Server 2008 R2 или выше.
Ссылки на другие материалы из этой серии:
В предыдущей части мы кратко просмотрели назначение новых протоколов [MS-XCEP] и [MS-WSTEP], которые позволяют автоматически подавать заявки на сертификаты без непосредственного подключения к домену. Сегодня мы посмотрим порядок работы клиента автоэнроллмента с этими протоколами.
Примечание: для недоменных клиентов доступна возможность использования только автоэнроллмента. ACR (Automatic Certificate Request) для не поддерживается.
Group Policy configuration
После установки службы CEP у вас появляется адрес HTTP, который указывает на сервер CEP и этот адрес имеет вид:
https://www.example.com/ADPolicyProvider_CEP_auth_protocol/service.svc/CEP
где auth_protocol указывает на протокол аутентификации клиента на сервере CEP. Это может быть Kerberos (только для доменных клиентов), Password или Certificate. Вот этот адрес нужно добавить в настройки групповой политики. Для этого откройте редактор групповой политики (gpmc.msc или gpedit.msc для недоменных машин) и в секции: Computer Configurtion\Windows Settings\Security Settings\Public Key Policies настроить параметр Certificate Services Client — Certificate Enrollment Policy. В свойствах следует включить эту политику и вы увидите окно Certificate Enrollment Policy list и в котором уже одна политика будет определена. Предопределённую политику следует удалить совсем и кнопкой Add добавить новую. В открывшемся окне вставить эту ссылку, указать нужный тип аутентификации и нажать Validate. В результате вы должны получить нечто вроде такого:
fig.1
Если вам это удалось сделать, значит клиент смог успешно пообщаться с сервером XCEP и CES. Причём, вы увидите, что клиент по этой ссылке смог найти название данной политики и вставить её в окошко:
fig.2
И таким образом вы можете добавлять несколько различных адресов политик, которые могут относиться к различным организациям. Причём, организация может развернуть несколько серверов XCEP для обеспечения высокой доступности, тогда вы можете добавлять несколько адресов серверов CEP и они будут линковаться к одной политике.
Следует чётко понимать, что на предыдущей картинке вы видите коллекцию серверов CEP (Policy collection). Каждое имя уникально идентифицирует политику, которая может поддерживаться несколькими серверами CEP. Чтобы посмотреть сколько серверов CEP обслуживают ту или иную политику, выделите нужную политику и нажмите Properties. В результате вы увидите нечто похожее на это:
fig.3
Уникальность политики определяется по её GUID'у. В этом окне может формироваться список всех серверов CEP, которые обслуживают одну и ту же политику (с одинаковым GUID'ом). По умолчанию для всех политик включается разрешение автоэнроллмента.
Примечание: галочка Enable for automatic enrollment and renewal не является самодостаточной и зависит от классической политики автоэнроллмента. Если автоэнроллмент отключен, то соответственно, автоматическая подача заявок на сертификаты производиться не будет.
Как обычно, триггер автоэнроллмента устанавливается в групповых политиках. Для его установки необходимо в редакторе групповой политики выключить следующие опции:
- создать новый объект групповой политики или отредактировать существующую политику по адресу:
Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment
данный элемент политики следует установить в состояние Enabled, поставить галочку Update certificates that use certificate templates и при необходимости выбрать автоматическое обновление просроченных сертификатов и удалении отозванных сертификатов из хранилища. - Те же параметры настраиваются и в секции User Configuration, чтобы обеспечить автоматическое распространение пользовательских сертификатов. Это могут быть сертификаты EFS, подписи электронной почты или сертификаты для аутентификации пользователей:
User Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment - прилинкуйте созданную или отредактированную политику к нужному OU (чаще всего её применяют для всего домена).
Примечание: для успешного энроллмента сертификатов на основе новых шаблонов (для которых у клиента ещё нет ни одного сертификата) галочка Update certificates that use certificate templates обязательна!
В общем смысле, новый автоэнроллмент работает примерно так:
fig.4
Client behavior
Примечание: по причине громоздкости текста, я не буду приводить содержание ответа сервера XCEP. Но его cтруктуру можно увидеть в §4.1.1.2 (GetPoliciesResponse Response) документа [MS-XCEP]. Поэтому я буду подразумевать, что вы ознакомились с его примерным содержанием.
Когда срабатывает триггер автоэнроллмента, клиент считывает параметры из реестра:
- HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Autoenrollment
- HKCU\SOFTWARE\Policies\Microsoft\Cryptography\Autoenrollment
Данные разделы реестра содержат настройки автоэнроллмента для конфигурации компьютера и пользователя, соответственно (более подробней о содержимом этих разделов реестра читайте во второй части). А так же будет считывать следующие ключи реестра:
- HKLM\SOFTWARE\Policies\Microsoft\Cryptography\PolicyServers
- HKCU\SOFTWARE\Policies\Microsoft\Cryptography\PolicyServers
Данные ключи будут содержать подключи политик. Каждому подключу политики присваивается уникальный GUID и внутри него будет содержаться необходимая информация о каждой политике, как URI, метод аутентификации, «стоимость» политики и флаги автоэнроллмента. После этого происходит сортировка политик по следующим правилам:
- сортируются по «стоимости» политики. Политика с меньшей стоимостью будет более приоритетной и политика с большей стоимостью будет менее приоритетной, соответственно. Если 2 и более политик имеют одинаковую стоимость, то идёт второй уровень сортировок по методу аутентификации (в порядке приоритета):
- используется аутентификация Kerberos;
- используется анонимная аутентификация;
- остальные политики используются в том порядке, в каком они записаны в реестре.
Когда политики отсортированы, клиент подключается к серверу XCEP из каждой политики по HTTPS. Если по какой-то ссылке не удаётся подключиться или сервер возвращает ошибку (SOAP), клиент переходит к следующей ссылке. Если в ответ получены политики, клиент извлекает следующие параметры:
- адрес или адреса серверов CES;
- список серверов CA, на работу с которыми настроен сервер CES. Один сервер CES должен быть настроен на работу с неболее, чем одним сервером CA;
- список шаблонов и их параметры.
Pended request processing
Как и в случае с ACR, клиент после всех подготовительных процедур пытается получить сертификаты в ответ на запросы. Как мы уже знаем, запросы хранятся в контейнере Certificate Enrollment Requests. Сперва клиент удаляет все запросы, которые старше 60 дней, а затем посылает запрос на CES для выяснения статуса каждого запроса. Если в ответ на запрос был получен сертификат, то он помещается в список ToBeAdded. Если статус запроса Denied, то запрос удаляется. Если статус неизвестен, клиент переходит к следующему запросу.
Certificate update and enrollment
После обработки всех ожидающих запросов, клиент проверяет статус каждого существующего сертификата. Если сертификат отозван или его срок истёк, он помещается в список ToBeDeleted.
Примечание: просроченные сертификаты будут помещены в этот список только если в групповой политике выставлен флаг Renew expired certificates, update pending certificates, and remove revoked certificates и сертификат не используется для шифрования.
Если срок действия сертификата преодолел отметку 80% и шаблон этого сертификата находится в списке доступных шаблонов (который был получен после нескольких уровней фильтрации в предыдущих шагах), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, то запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2). Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.
Примечание: здесь и далее. Если по каким-либо причинам запрос подписать невозможно, клиент вместо обновления сертификата выполняет стандартную процедуру запроса сертификата с генерацией новой ключевой пары.
Примечание: здесь и далее. Если необходимый шаблон находится в выдаче более одного CA, клиент по очереди посылает запрос на каждый сервер CES в соответствии с их сортировкой.
Если версия шаблона (Major Version), который использовался при предыдущем энроллменте отличается от текущего Major Version шаблона, клиент посылает запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.
Примечание: при каждом редактировании шаблона (кроме вкладки Security) изменяется только Minor Version. И держатели сертификатов этого шаблона не увидят, что шаблон изменён, поскольку они проверяют только Major Version. В случае, если после внесения изменений в шаблон необходимо переиздать все сертификаты этого шаблона, администратор должен изменить Major Version. Для этого администратор в оснастке certtmpl.msc должен выбарть нужный шаблон, нажать правой кнопкой и выбарть Reenroll All Certificate Holders. Этот шаг изменит Major Version шаблона и все клиенты, которые уже имеют сертификат данного шаблона его обновят, получив новый сертификат с новыми изменениями.
Если шаблон, который использовался при предыдущем энроллменте был заменён более новым (вкладка Superseded Templates нового шаблона содержит устаревший шаблон), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2). Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.
Для необработанных шаблонов клиент отправляет запросы на получение сертификатов на основе этих шаблонов.Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.
Когда все запросы, сертификаты и шаблоны были обработаны, триггер автоэнроллмента очищает список ToBeDeleted и все сертификаты из списка ToBeAdded копирует в контейнер Personal.
Epilogue
Вот, вроде и всё. На этом я завершаю цикл статей, посвящённых Certificate Autoenrollment во всех его вариациях и с рассказом о новых возможностях Windows 7 и Windows Server 2008 R2. Рассказал как умел и, мне кажется, материал получился достаточно исчерпывающим и у читателя должно появиться понимание принципа работы всех внутренних механизмов. Если что-то осталось непонятным или появились вопросы — комментарии внизу :)
Что бы почитать?
Update 30.05.2012: исправлен процесс получения шаблонов CA.
Ссылки на другие материалы из этой серии:
Windows Client Certificate Enrollment (WCCE)
В предыдущих частях мы рассмотрели принципы работы autoenrollment'а, который возможен только в доменной среде. Это значит, что для осуществления этой задачи мы должны иметь как минимум:
- Контейнер в AD с информацией о шаблонах сертификатов. CA локально не хранит сами шаблоны, а хранятся они только в AD;
- Контейнер в AD с информацией о выдающих Enterprise CA (Issuing CA).
Я считаю, что следует ещё раз ознакомиться о порядке энроллмента сертификатов в домене из оснастки Certificates консоли MMC:
- Клиент инициализирует необходимые COM интерфейсы для CryptoAPI;
- Используя LDAP получает список всех доступных в лесу шаблонов сертификатов;
- Используя LDAP получает список всех доступных в лесу Enterprise CA. Именно по этой причине Enterprise CA не могут существовать вне домена Active Directory, поскольку Active Directory используется для их обнаружения и хранения шаблонов;
- Используя LDAP получает список доступных шаблонов CA;
- На данном этапе клиент в окне MMC отображает список шаблонов, которые вы можете выбирать;
- Вы вибираете нужный шаблон и клиент используя множество COM интерфейсов. Пример их использования можете посмотреть в следующем посте: Generating a certificate (self-signed) using powershell and CertEnroll interfaces;
- Когда запрос подготовлен, клиент подключается к DCOM интерфейсу ICertRequest::Submit() сервера CA и отправляет этот запрос на сервер.
- После отправки запроса на сервер, клиент через тот же интерфейс получает статус своего запроса.
Примечание: более подробно все эти CryptoAPI DCOM интерфейсы описаны в спецификациях протокола [MS-WCCE].
Как вы можете видеть, этим мы зажаты доменом Active Directory, поскольку без него не можем найти ни один Enterprise CA и не можем получить список доступных шаблонов. Другая проблема — непосредственное подключение к CryptoAPI DCOM интерфейсам сервера CA, что не очень хорошо сказывается на безопасности.
Я сейчас не буду вдаваться в подробности организации серверов CA в лесу Active Directory, но требование DCOM коннекта делает невозможным изоляцию серверов CA от клиентов. Следовательно недоменные клиенты не могут энролить сертификаты через MMC, а доменные клиенты ограничены только серверами CA, которые зарегистрированы в текущем лесу. Для наглядности прилагаю картинку:
X.509 Certificate Enrollment Policy (XCEP)
С выходом 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, которые содержат всю необходимую информацию:
- Список шаблонов и их настройки;
- Все используемые 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. В грубом представлении картинка будет выглядеть примерно так:
Клиент из политики, которую получил от 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.
Что бы почитать?
Предлагаю немного отвлечься от autoenrollment и поговорить о часто задаваемым вопросам, которые относятся к проблемам certificate chaining engine. Данный FAQ основывается на вопросах, которые часто задаются на форумах TechNet.
Q: За что отвечают расширения CRL Distribution Points (CDP) и Authority Information Access (AIA) в цифровых сертификатах?
A: Расширение Authority Information Access всегда содержит ссылки на сертификат Certification Authority (CA), который издал рассматриваемый сертификат. Например, у вас есть сервер CA, который издаёт пользователям сертификаты. Каждый такой сертификат будет содержать ссылку на скачивание сертификата этого самого CA. Это необходимо для построения цепочки сертификатов. Как известно, любая иерархия PKI включает себя как минимум один корневой CA (Root CA) и может содержать несколько уровней промежуточных CA. Используя расширение AIA конечного сертификата, клиент скачивает сертификат издающего CA, который в расширении AIA так же содержит ссылки на скачивание сертификата вышестоящего CA. Этот процесс происходит до тех пор, пока цепочка не закончится самоподписанным сертификатом и который уже не содержит расширения AIA. Поскольку корневой сертификат самоподписанный, он является конечной точкой цепочки. По корневому сертификату определяется доверие цепочке. Чтобы доверять такой цепочке, корневой сертификат, на котором эта цепочка заканчивается, должен быть установлен в контейнере Trusted Root CAs в оснастке Certificates консоли MMC.
Расширение CRL Distribution Point содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. Сертификаты могут быть отозваны, когда есть подозрения или уже констатирован факт получения несанкционированного доступа к закрытому ключу третьим лицом. Закрытый ключ должен быть доступен только тому пользователю или компьютеру, которому выдан данный сертификат. Если третье лицо получило доступ к закрытому ключу, это лицо может воспользоваться им для получения конфиденциальной информации или выдавать себя за легитимного пользователя. В таких случаях администратор CA может отозвать такой сертификат. В таком случае если сертификат содержится в файле CRL, предъявителю данного сертификата никакого доверия не будет. Следует понимать, что CDP/AIA рассматриваемого сертификата содержат ссылки на файлы вышестоящего CA. Даже если владельцем рассматриваемого сертификата является сервер CA (Intermediate CA), ссылки будут указывать на файлы вышестоящего CA.
Более подробно вопрос рассмотрен по ссылке: Certificate Chaining Engine — как это работает.
Q: Нужны ли расширения CDP и AIA в сертификатах корневых CA?
A: Нет. Как уже было сказано, CDP и AIA содержат ссылки на файлы вышестоящего CA, а корневой сертификат является высшей точкой в иерархии и выше корневого CA ничего быть не может. Поэтому данные расширения бесполезны для сертификатов корневых CA и обычно просто отсутствуют.
Более подробно вопрос рассмотрен здесь: Certificate chaining engine (CCE) и отзыв корневых сертификатов
Q: На каком сервере CA я могу отозвать определённый сертификат?
A: каждый сервер CA поддерживает свой список CRL в который может включать только те сертификаты, которые были выданы именно этим CA. Это означает, что сертификат отозвать может только CA, который указан в поле Issuer рассматриваемого сертификата.
Q: Стоит ли использовать Certificate Hold в качестве причины отзыва сертификата? Если да, то в каких случаях?
A: Причина отзыва как Certificate Hold обладает одной особенностью — его можно извлечь обратно из CRL файла, после чего он перестанет считаться отозванным. Данная причина задумана для случаев когда сотрудник уходит в отпуск и такой отзыв позволит избежать использование отозванного сертификата на этот период. Однако, данную причину не следует никогда использовать. Это связано с тем, что после извлечения сертификата из CRL вы не можете узнать был ли он отозван в какой-то период времени. Например, вы отозвали сертификат с причиной Certificate Hold и через некоторое время передумали и извлекли сертификат из CRL. В последствии вы получаете документ, подписанный этим сертификатом именно в период фактического нахождения сертификата в CRL. Фактически получается, что документ был подписан в тот момент, когда сертификат был отозван. Поскольку он был потом извлечён из CRL, вы больше не можете доказать, что сертификат был отозван на момент подписания документа. По этой причине вы не должны использовать данную причину отзыва.
Q: При установке сертификата на сервер иногда получаю ошибку: The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613). Что это может означать и как эту ошибку исправить?
A: Данная ошибка указывает на то, что системе не удалось проверить сертификат на отзыв. Иными словами, система извлекла ссылку из CDP расширения сертификата и по этой ссылке не удалось скачать CRL файл. В данном случае вы должны обратиться к администратору сервера CA, чтобы тот обеспечил доступность файла по ссылкам в CDP расширении. Если же вы сами исполняете эти обязанности, то вы должны самостоятельно решить этот вопрос — настроить точки публикации CRL файлов. В качестве временного решения (например, вы опубликовали CRL только в Active Directory и у вас несколько доменов в лесу, причиной этого может быть репликация AD. В таком случае вы можете скачать CRL файл локально на компьютер (любым удобным способом) и выполнить команду: certutil –addstore –f Root <path\file.crl>
где <path\file.crl> — путь к файлу CRL.
Q: При открытии файла сертификата я вижу следующее сообщение: Windows does not have enough information to verify this certificate. Что это означает и как с этим бороться?
A: Данное сообщение говорит о том, что системе не удалось найти сертификат вышестоящего CA. Как уже было отмечено, этот сертификат можно скачать по ссылке (ссылкам) в расширении AIA, но по всей видимости они нерабочие. Вы можете попробовать вручную скачать файл по этим ссылкам и вероятней всего вам это не удастся. Для решения этой проблемы вы должны опубликовать физический файл в соответствующие места: папка веб-сервера (для протокола HTTP) или контейнер AIA в Active Directory (для протокола LDAP). Если файл сертификата CA публикуется только в AD и у вас лес с несколькими доменами, данная ошибка может быть кратковременно вызвана задержками репликации. В таком случае для временного решения вы можете скачать файл на локальную машину (любым удобным для вас способом) и выполнить одну из двух команд:
certutil –addstore –f SubCA <path\file.crt> — если вышестоящий CA не является корневым
certutil –addstore –f Root <path\file.crt> — если вышестоящий CA является корневым.
где <path\file.crt> — путь к файлу CER/CRT.
Q: Я отозвал сертификат, опубликовал новый CRL, однако при запуске файла сертификата я не вижу ошибок, что сертификат отозван. Почему?
A: Когда вы запускаете файл сертификата (просматриваете его содержимое), проверка на отзыв не происходит. Система только строит цепочку, но ни один сертификат на отзыв не проверяется. Это by design. Для проверки статуса сертификата вы можете воспользоваться следующими командами:
certutil –url <path\file.cer> — этой командой вызывается удобный графический интерфейс, в котором вы можете выяснить статус отзыва сертификата.
certutil –verify –urlfetch <path\file.cer> — данная команда выведет очень подробный текстовый лог проверки. Рекомендуется для использования профессионалами, которые в состоянии проанализировать этот лог.
где <path\file.cer> — путь к файлу проверяемого сертификата.
Q: Я отозвал сертификат, опубликовал новые CRL, однако certutil показывает, что сертификат не отозван. Как так?
A: Это вызвано тем, что CRL'ы, как и ответы от OCSP Responder кешируются в оперативной памяти и жёстком диске. Для обновления кеша в памяти, следует перезапустить приложение, которое проверяет статус сертификата. А на самом диске CRL кешируется на срок действия конкретного CRL. Это значит, что клиент будет использовать данный кешированный CRL до срока указанного в поле Next update конкретного CRL файла. Кеширование используется для экономии ресурсов и пропускной способности сети. Но вы можете очистить кеш CRL (при этом удалятся все кешированные CRL), вы можете воспользоваться следующей командой:
certutil -setreg chain\ChainCacheResyncFiletime @now
после этого обязательно следует выполнить следующую команду:
certutil –delreg chain\ChainCacheResyncFiletime
Данные команды поддерживаются системами начиная с Windows XP SP3. Предыдущие системы не поддерживают очистку кеша CRL.
Q: Какие протоколы разрешены для расширений CDP/AIA?
A: Для Windows систем доступны только следующие протоколы:
HTTP:// — только для публикации в расширение сертификата.
LDAP:// — для публикации физических файлов и для публикации ссылки в расширение сертификата.
FILE:// — только для публикации физических файлов в сетевой папке (например, на веб-сервере). Хотя Windows Server 2003 и предыдущие системы позволяли такие ссылки в расширениях CDP/AIA, начиная с Windows Vista/Windows Server 2008 они больше не допускаются и не используются.
C:\path — только для публикации физических файлов в файловой системе локального компьютера.
Более подробно можно прочитать по ссылке: CRL Distribution Points и Authority Information Access
Q: есть ли какие-то best practices по планированию расширений CDP/AIA?
A: да, существют определённые best practices по настройке расширений CDP/AIA на сервере CA. И вот как они выглядят в общем виде:
1) не следует использовать ссылки вида LDAP:// если ваши сертификаты могут использоваться вне пределах вашего леса AD. Это вызвано тем, что скачивать файлы по таким ссылкам могут только клиенты текущего леса, остальные клиенты будут получать ошибки по этим ссылкам. Целесообразно использовать более универсальные протоколы как HTTP. Данный протокол поддерживается множеством систем, в том числе и мобильными системами (смартфоны) и пользователями других операционных систем. При использовании HTTP рассмотрите возможность высокой доступности этих веб-серверов, как NLB-кластер или использования двух различных веб-серверов. В таком случае вы должны будете указать ссылки на скачивание файла для каждого веб-сервера.
2) используйте веб-сервера, которые доступны как изнутри сети, так и из интернета (если сертификаты могут использоваться пользователями интернета, например SSL-сертификаты) по одному и тому же URL.
3) при планировании ссылок, которые будут публиковаться в расширениях CDP/AIA сертификатов следует учитывать их очерёдность. Если вы решили использовать 2 независимых веб-сервера, первым указывайте тот, который будет являться основным. Это обусловлено тем, что клиент скачивает файлы по ссылкам в порядке их следования. Первая ссылка будет использоваться в первую очередь. Для ссылок публикации физического файла очерёдность не имеет значения.
4) для HTTP ссылок никогда не используйте SSL (т.е. HTTPS ссылки), поскольку это вызовет бесконечную проверку сертификатов, в результате чего вы никогда не скачаете нужный файл.
Более подробно можно прочитать по ссылкам: CRL Distribution Points и Authority Information Access, OCSP или CRL?
Q: Какие версии ОС Windows поддерживают нативного клиента OCSP?
A: Только ОС начиная с Windows Vista/Windows Server 2008 включают в себя клиента OCSP. Предыдущие системы никогда не поддерживали и не будут поддерживать клиента OCSP. Для них придётся приобретать отдельный программный продукт сторонних компаний.
Q: Я хочу использовать OCSP Responder как для внутренней, так и для внешней сети (интернета). На какое имя должен выдаваться сертификат OCSPResponseSigning?
A: на самом деле клиенту всё равно на какое имя выдаётся данный сертификат. Главное — сертификат должен отвечать следующим условиям:
1) должен быть выдан тем же CA для которого OCSP Responder осуществлял проверку статуса сертификата.
2) в Application Policies (Extended Key Usage) должен быть указан: OCSP Signing
3) в сертификате должно присутствовать расширение: OCSP No Revocation Checking
4) срок действия сертификата должен быть действующий.
Q: Мы в компании перешли на Windows Vista/Windows 7 и развернули OCSP Responder. Однако в сети уже выпущено огромное количество сертификатов, которые не содержат ссылок на OCSP Responder. Надо ли перевыпускать все сертификаты для включения в них ссылки на OCSP?
A: нет, вам не нужно перевыпускать все сертификаты, которые уже используются. Вы можете для доменных клиентов настроить групповую политику так, чтобы они получили адрес вашего OCSP Responder и которым они будут пользоваться при проверке сертификатов. В качестве руководства по настройке этой политики можете воспользоваться вот этой ссылкой: Appendix A: Managing OCSP Settings with Group Policy
Что бы почитать?