Update 25.01.2010: добавлено обязательное включение галочки Update certificates that use certificate templates.

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

•  Certificate Autoenrollment от А до Я — подведение итогов

Продолжаем тему автоэнроллмента и сегодня рассмотрим принцип т.н. «классической» модели автоматической подачи заявок на сертификаты. Данная модель поддерживается клиентами начиная с Windows XP и которые являются членами домена Active Directory.

Group Policy settings

Как и в случае с Automatic Certificate Request (ACR), триггер автоэнроллмента устанавливается в групповых. Для его установки необходимо в редакторе групповой политики выключить следующие опции:

• в оснастке CertSrv.msc любого Enterprise CA в секции Certificate Templates убедиться, что в списке присутствует нужный шаблон версии 2 или 3. Если нет, то All Tasks –> New –> Certificate Template to issue и добавить шаблон;
• в редакторе групповой политики (Group Policy Management) создать новый объект групповой политики или отредактировать существующую политику по адресу:
  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 обязательна!

В общем смысле, автоэнроллмент работает примерно так:

Но дальше мы рассмотрим весь этот процесс более подробно.

Client bahavior

Когда срабатывает триггер автоэнроллмента, клиент считывает параметры из реестра:

• HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Autoenrollment
• HKCU\SOFTWARE\Policies\Microsoft\Cryptography\Autoenrollment

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

• сертификаты CA из контейнера по адресу:
  CN=AIA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• сертификаты корневых CA из контейнера по адресу:
  CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• сертификаты агентов восстановления из контейнера по адресу:
  CN=KRA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• сертификаты CA, которые могут издавать сертификаты для аутентификации по Kerberos из записи NTAuthCertificates по адресу:
  CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain

На основе этих сертификатов, клиент обновляет свои локальные хранилища. Далее, считываются все шаблоны и сведения об Enterprise CA из следующих контейнеров:

• CN=Certificate Templates, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain

После чего клиент считывает сертификаты из контейнера Personal и помещает их в процессинговый список, а так же генерирует списки ToBeAdded и ToBeDeleted. В эти списки попадут все сертификаты, которые будут добавлены к локальному хранилищу и удалены из него, соответственно.

Примечание: в процессинговый список попадают только сертификаты основанные на шаблонах. Например, самоподписанные сертификаты EFS не попадают в этот список.

Certificate template sorting

И вот здесь начинается процесс организации порядка обработки сертификатов. Клиент из полученных шаблонов сертификатов выбирает только те, на которые у пользователя или компьютера (в зависимости от контекста) есть все права: Read, Enroll и Autoenroll. Если же хоть одного права не хватает, то шаблон исключается из списка. Для оставшихся шаблонов проверяется содержимое Superseded Templates. Как я уже говорил в предыдущей части, любой шаблон версии 2 или 3 может заменять устаревший шаблон. Например, новый шаблон Advanced EFS может заменять шаблон Basic EFS. В таком случае шаблон Advanced EFS считается более новым и все держатели сертификатов шаблона Basic EFS получат новый сертификат шаблона Advanced EFS. Поскольку список Superseded Templates содержит устаревшие и неиспользуемые более шаблоны, то они так же исключаются из списка. Следующим этапом исключаются шаблоны, в настройках которых содержится:

• число This Number Of Authorized Signatures (во вкладке Issuance Requirements) больше 1;
• выставлен чек-бокс Supply in the request (во вкладке Subject name);
• выставлен чек-бокс Prompt the user during enrollment (во вкладке Request handling компьютерных шаблонов).

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

Когда шаблоны сертификатов отсортированы, клиент обрабатывает список Enterprise CA. Их записи в Active Directory содержат достаточно информации, чтобы клиент мог их найти. Получив список Enterprise CA в текущем лесу, клиент проверяет сертификат каждого CA. Если цепочка какого-то CA не может быть построена, недоверена или какой-то элемент цепочки был отозван, то такой CA исключается из списка. Клиент может использовать только доверенные CA для формирования запроса и получения сертификатов.

После составления списка всех пригодных Enterprise CA, клиент обращается к каждому из них и получает список шаблонов, на основании которых CA может издавать сертификаты. Здесь клиент делает последний процесс сортировки шаблонов, которые будут обработаны. Все шаблоны, которые не находятся в выдаче хотя бы одного CA, удаляются из списка. Таким образом фильтр обеспечивает, что каждый шаблон может быть обработан потому что он содержит правильные настройки, разрешения и находится в выдаче хотя бы одного CA.

Pended request processing

Как и в случае с ACR, клиент после всех подготовительных процедур пытается получить сертификаты в ответ на запросы. Как мы уже знаем, запросы хранятся в контейнере Certificate Enrollment Requests. Сперва клиент удаляет все запросы, которые старше 60 дней, а затем посылает запрос на CA для выяснения статуса каждого запроса. Если в ответ на запрос был получен сертификат, то он помещается в список ToBeAdded. Если статус запроса Denied, то запрос удаляется. Если статус неизвестен, клиент переходит к следующему запросу.

Certificate update and enrollment

После обработки всех ожидающих запросов, клиент проверяет статус каждого существующего сертификата. Если сертификат отозван или его срок истёк, он помещается в список ToBeDeleted.

Примечание: просроченные сертификаты будут помещены в этот список только если в групповой политике выставлен флаг Renew expired certificates, update pending certificates, and remove revoked certificates и сертификат не используется для шифрования.

Если срок действия сертификата преодолел отметку 80% и шаблон этого сертификата находится в списке доступных шаблонов (который был получен после нескольких уровней фильтрации в предыдущих шагах), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.

Примечание: здесь и далее. Если по каким-либо причинам запрос подписать невозможно, клиент вместо обновления сертификата выполняет стандартную процедуру запроса сертификата с генерацией новой ключевой пары.

Примечание: здесь и далее. Если необходимый шаблон находится в выдаче более одного CA, клиент рандомно выбирает CA которому будет отправлен запрос. Если CA вернул ошибку или недоступен, клиент выбирает другой CA, который может выпускать сертификаты на основе конкретного шаблона.

Если версия шаблона (Major Version), который использовался при предыдущем энроллменте отличается от текущего Major Version шаблона, клиент посылает запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.

Примечание: при каждом редактировании шаблона (кроме вкладки Security) изменяется только Minor Version. И держатели сертификатов этого шаблона не увидят, что шаблон изменён, поскольку они проверяют только Major Version. В случае, если после внесения изменений в шаблон необходимо переиздать все сертификаты этого шаблона, администратор должен изменить Major Version. Для этого администратор в оснастке certtmpl.msc должен выбарть нужный шаблон, нажать правой кнопкой и выбарть Reenroll All Certificate Holders. Этот шаг изменит Major Version шаблона и все клиенты, которые уже имеют сертификат данного шаблона его обновят, получив новый сертификат с новыми изменениями.

Если шаблон, который использовался при предыдущем энроллменте был заменён более новым (вкладка Superseded Templates нового шаблона содержит устаревший шаблон), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.

Для необработанных шаблонов клиент отправляет запросы на получение сертификатов на основе этих шаблона. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.

Epilogue

Когда все запросы, сертификаты и шаблоны были обработаны, триггер автоэнроллмента очищает список ToBeDeleted и все сертификаты из списка ToBeAdded копирует в контейнер Personal.

Как вы видите, процесс автоэнроллмента в очень степени похож на процесс Automatic Certificate Request и отличается лишь дополнительными шагами обработки шаблонов версии 2 и 3.

Что дальше?

В этой и предыдущих частях мы рассмотрели основные концепции и особенности работы Automatic Certificate Request и autoenrollment'а при использовании протокола MS-WCCE, основанном на DCOM сообщениях. В следующей части будет рассмотрена концепция и порядок работы автоэнроллмента с использованием более нового набора протоколов: MS-XCEP и MS-WSTEP/WS-TRUST, которые значительно расширяют наши возможности управления сертификатами.

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

• Certificate Autoenrollment in Windows Server 2003
• [MS-WCCE]
• [MS-CAESO]

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

•  Certificate Autoenrollment от А до Я — подведение итогов

Preamble

В предыдущих материалах мы ознакомились с шаблонами версии 1 и достаточно простым методом автоэнроллмента — Automatic Certificate Request (ACR). Этот метод достаточно прост и позволяет автоматически распространять сертификаты на основе шаблонов версии 1 и поддерживается серверами CA под управлением любой версии ОС, начиная с Windows 2000. Эта простота, в свою очередь, выливается в соответствующую функциональность. Это значит, что мы таким образом можем распространять сертификаты только для компьютеров. И можем использовать только те шаблоны, которые поставляются с ролью CA. Мы не имеем возможности изменять эти шаблоны, поэтому приходится использовать как есть. Хотя, в ряде случаев этого бывает достаточно. Например, шаблон Computer очень часто удовлетворяет требованиям для компьютерных сертификатов общего назначения. Однако, часто этого бывает недостаточно, особенно не хватает возможности автоматического распространения сертификатов пользователям. Для решения этой и не только задачи мы можем использовать шаблоны версии 2 и 3 и классический автоэнроллмент.

Примечание: чтобы узнать какие операционные системы поддерживают шаблоны версии 2 и 3, ознакомьтесь с обеими таблицами, приведённвми в первой части материала.

V2/V3 Templates

Примечание: хоть шаблоны версии 3 немного отличаются от шаблонов версии 2, я не буду ничего говорить отдельно по ним, поскольку в контексте автоэнроллмента эти шаблоны никаких изменений не содержат и все особенности присущие шаблонам версии 2 для новой версии шаблона так же действительны. За дополнительными сведениями по шаблонам обратитесь по ссылке в конце поста.

Шаблоны версии 2 и 3 уже являются управляемыми и их можно очень гибко конфигурировать:

 

Безусловно, возможность настраивать шаблоны резко усложняет понимание и управление процессом. В этой части я планирую только показать настройки шаблонов и какие настройки несовместимы с автоэнроллментом.

Вкладка General

• Template display name — отображаемое имя шаблона. Используется для удобства распознавания шаблона пользователем.
• Template name — это уже внутреннее имя шаблона по которому учётные записи и службы находят шаблоны.
• Validity period — устанавливает срок действия сертификата на основе конкретного шаблона.

Примечание: срок действия сертификата может быть ограничен не только этой настройкой. В действительности принимается во внимание ещё остаточный срок действия сертификата самого сервера CA и значение реестра на сервере CA по адресу: HKLM\System\CurrentControlSet\ Services\CertSvc\Configuration\<CA sanitized name> и значения Validity period и Validity period units. Наименьшее из трёх значений будет определять реальнй срок действия сертификатов.

• Renewal period — указывает срок за который до окончания действия сертификата, механизм автоэнроллмента будет пробовать обновить сертификат.

Примечание: данная опция используется только при активной политике автоэнроллмента и в остальных случаях игнорируется. Так же следует учитывать, что этот срок не является абсолютным. Есть ещё предустановленное значение, которое равно 80% от срока действия сертификата. Это означает, что триггер автоэнролмента будет будет пытаться обновить сертификат либо по истечении 80% (т.е. за 20% до конца) срока действия сертификата или значения этой опции. В итоге выбирается то значение, которое больше (иными словами, срабатывает раньше). По умолчанию 6 недель для срока действия в 1 год составляет эти самые 20% до срока окончания сертификата.

• Publish certificate in Active Directory — публикует сертификат в свойствах учётной записи пользователя или компьютера. Публикация полезна, когда кто-то будет использовать сертификат конкретного пользователя. Например, при предоставлении общего доступа к шифрованным файлам или для шифрования почты, сертификаты других пользователей должны быть опубликованы в Active Directory.
• Do not automatically reenroll if a duplicate certificate exist in Active Directory — инструктирует клиента автоэнроллмента не запрашивать новые сертификаты на основе текущего шаблона, если действующий сертификат уже существует в свойствах учётной записи в AD. В случае использования перемещаемых пользователей и/или частого перемещения пользователя между компьютерами эта опция позволяет не плодить большое количество сертификатов на основе одинакового шаблона. Работает только при использовании предыдущей опции. В остальных случаях игнорируется. Следует учитывать, что массовая публикация сертификатов в AD может значительно увеличить объём реплицируемых данных между контроллерами доменов.
• For automatic renewal of smart card certificates, use the existing private key if a new key cannot be created — позволяет смарт-карте использовать существущий закрытый ключ при обновлении сертификата на ней. При нехватке свободного места на смарт-карте может оказаться, что записать новую пару ключей некуда и энроллмент закончится неудачей. Данную опцию рекомендуется включать для шаблонов, которые используют CSP смарт-карт.

Вкладка Request Handling

• Purpose — указывает целевое назначение закрытого ключа данного шаблона. Это может быть цифровая подпись, шифрование, или оба значения, а так же использование для смарт-карт.
• Delete revoked or expired certificate — инструктирует клиента автоэнроллмента удалять просроченные или отозванные сертификаты из хранилища пользователя или компьютера. Используется только при активной политике автоэнроллмента. Данная опция недоступна, если предыдущее поле Purpose содержит Encryption.
• Include symmetric algorithms allowed by the subject — позволяет приложениям использовать новые симметричные алгоритмы CNG (Cryptography New Generation) при использовании данного сертификата. Доступно только начиная с Windows Server 2008.
• Archive subject's private key — инструктирует клиента инициировать процедуру архивации закрытого ключа на сервере CA при энроллменте сертификата. Данная опция недоступна, если Purpose выставлен в Signature или в Signature and smartcard logon.

Примечание: как вы можете зметить, опции: Delete revoked or expired certificate и Archive subject's private key являются взаимоисключаемые. Вы не можете использовать обе эти опции в пределах одного шаблона.

• Minimum key size — указывает минимальную длину ключа, который будет генерироваться при запросе сертификата.
• Allow Private Key To Be Exported — позволяет экспортировать (например, для бэкапа) закрытый ключ данного сертификата из локального хранилища сертификатов.
• Enroll subject without requiring any user input — инструктирует клиента не выводить пользователю никаких окошек, которые бы требовали ввода от пользователя. Данный параметр обязателен для компьютерных шаблонов, которые используются для автоэнроллмента.
• Prompt the user during enrollment — выводит диалоговое окно при энроллменте. Данный параметр обязателен, если закрытый ключ сертификата будет храниться на смарт-карте. Эта опция позволит CSP смарт-карты выводить окно ввода PIN от смарт-карты.
• Prompt The User During Enrollment And Require User Input When The Private Key Is Used — при энроллменте выводит диалоговые окна настройки private key strong protection и включает этот режим для закрытого ключа.
• CSP — позволяет выбрать Cryptographic Service Provider для генерации закрытого ключа. Для автоэнроллмента следует установить не более одного провайдера.

Вкладка Subject name

• Supply in request — требует явного задания поля Subject при энроллменте. Недопустимо при автоэнроллменте.
• Build From This Active Directory Information — инструктирует сервер CA заполнять поле Subject основываясь на данных учётной записи в Active Directory. Обязателен для автоэнроллмента.

Вкладка Issuance Requirements

• CA Certificate Manager Approval — для всех запросов данного шаблона требуется явное одобрение администратора CA. При автоэнроллменте в первый раз будет отправлен запрос и потом, после принятия положительного решения администратором, при повторных срабатываниях триггера автоэнроллмента будет импортирован сам сертификат.

Примечание: при автоэнроллменте автоматическое получение сертификата после одобрения администратором произойдёт только при условии, если в политике автоэнроллмента выставлен чек-бокс на Renew expired certificates, update pending certificates, and remove revoked certificates. В противном случае, автоэнроллмент не будет работать для конкретного шаблона.

• This Number Of Authorized Signatures — указывает количество подписей, которыми должен быть подписан запрос. Для автоэнроллмента это значение не должно быть большье 1, иначе автоэнроллмент для конкретного шаблона работать не будет.

Примечание: строго говоря, выставлять данный параметр в 1 тоже не очень рекомендуется. Если с сертификатом что-то случится (будет утерян, просрочен или отозван), то обновление такого сертификата средствами автоэнроллмента будет невозможным, поскольку запрос нечем будет подписать и получить новый сертификат можно будет только после ручного энроллмента через консоль MMC.

• Если предущее значение больше нуля, то вы можете настроить для шаблона настроенные политики выдачи.
• Require The Following For Reenrollment: Same criteria as for enrollment — при обновлении сертификата, используются те же требования, что и при первом запросе сертификата. Для успешной работы автоэнроллмента не следует включать эту опцию, если количество требуемых подписей при запросе больше нуля, поскольку запрос надо будет чем-то подписать и если специального сертификата в локальном хранилище не окажется, то автоэнроллмент не будет работать для конкретного шаблона.
• Require The Following For Reenrollment: Valid existing certificate — при обновлении сертификата требуется наличие существующего действующего и не отозванного сертификата на основе данного шаблона. Действующий сертификат будет использоваться для подписи запроса обновления сертификата.

Примечание: если количество требуемых подписей при энроллменте больше 0 (обычно используется при Enroll On Behalf Of), то первый раз сертификат должен быть получен через ручной запрос с использованием оснастки MMC. Это полностью соответствует идеологии EOBO, когда администратор регистрирует каждую смарт-карту в учётных журналах, запрашивает сертификат для неё и под роспись выдаёт пользователю. Обновление сертификата уже будет происходить автоматически. Для этого данный переключатель следует переставить в Valid existing certificate. Существующий сертификат будет использоваться для подписи нового запроса. Соответственно, если сертификат будет утерян, отозван или просрочен, то обновление по очевидным причинам не будет, поскольку запрос подписать будет нечем. Для получения нового сертификата придётся повторить всю процедуру, как и при первом получении сертификата с помощью EOBO.

Вкладка Superseded templates

Данная вклкадка показывает какие существующие шаблоны будут заменены текущим шаблоном. Если вы решили использовать специально настроенный шаблон для смарт-карт, то вы можете этим специально настроенным шаблоном версии 2 заменить стандартные преднастроенные шаблоны (Smart Card Logon и Smart Card User). Это запретит дальнейший энроллмент сертификатов на основе устаревших шаблонов, которые заменяет новый шаблон. И если у пользователей есть сертификаты на основе устаревших шаблонов, то добавление их во вкладку Superseded templates проинструктирует клиентов обновить сертификаты на основе нового специально настроенного шаблона. Автоэнроллмент автоматически следит за обновлениями шаблонов. И если какой-то шаблон был заменён другим и у пользователя есть сертификат на основе устаревшего шаблона, автоэнроллмент запросит новый сертификат для нового шаблона.

Примечание: в настоящее время смарт-карты не поддерживают использование шаблонов версии 3.

Вкладка Extensions

Данная вкладка позволяет настраивать определённые расширения, которые будут опубликованы в сертификатах. В контексте автоэнроллмента ничего интересного не представляет.

Вкладка Security

Достаточно важная вкладка, поскольку она определяет, может ли автоэнроллмент использовать конкретный шаблоны или нет. Если вы планируете использовать шаблон для автоэнроллмента, то соответствующие учётные записи (или группы) должны иметь следующие права:

• Read
• Enroll
• Autoenroll

Отсутствие любого из этих прав не позволит автоэнроллменту запрашивать сертификаты на основе конкретного шаблона.

Примечание: это достаточно распространённая ошибка. Следует понимать, что пользовательским сертификатам права назнаются учётным записям пользователей, а компьютерным сертификатам права назначаются учётным записям компьютеров.

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

• Implementing and Administering Certificate Templates in Windows Server 2008

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

•  Certificate Autoenrollment от А до Я — подведение итогов

В первой части мы рассмотрели общие положения по системе автоматической подачи заявок на сертификаты — autoenrollment и сегодня поговорим об одной составляющей этой системы — Automatic Certificate Request (или сокращённо просто ACR). Пержде чем начать экшн, следует поговорить о шаблонах версии 1.

Шаблоны версии 1 (V1 Templates)

При установке в лесу Enterprise Certification Authority, в Active Directory устанавливаются и преднастроенные шаблоны сертификатов. Зачем они нужны? Поскольку сертификаты у нас могут использоваться для решения различного рода задач, например, для SSL или аутентификации смарт-картой или для установки цифровой подписи файлов. В связи с этим конечные сертификаты будут очень сильно различаться по настройкам. Безусловно, очень трудно запомнить все требования для каждого типа сертификатов и вручную их заполнять. Для этого Microsoft с ролью CA поставляет ряд преднастроенных шаблонов, которые отвечают требованиям наиболее частых случаев использования. Чтобы посмотреть доступные шаблоны в лесу необходимо запустить оснастку Certificate Templates (certtmpl.msc) и получите примерно такое окно:

Здесь мы видим несколько колонок:

• Template Display Name — это отображаемое и понятное имя шаблона. Как правило используется только для отображения. Внутренние механизмы используют сокращённое common name;
• Minimum Supported CAs — указывает версию и редакцию ОС, под которой должна работать служба Certification Authority для выдачи такого сертификата.
• Version — внутренняя версия ревизии шаблона. Ревизия состоит из Major revision (число до точки) и Minor revision (число после точки). Имеет достаточно важное значение, о котором поговорим чуть ниже;
• Windows XP Autoenrollment — указывает, может ли данный шаблон использоваться для классического автоэнроллмента (только для шаблонов версии 2 и 3);
• Intended Purposes — уазывает целевое назначение сертификатов данного шаблона.

В настоящее время существует 3 версии шаблонов: 1, 2 и 3 версии. Важно понимать, что эти версии не имеют  ничего общего с внутренней версией конкретного шаблона, которая показана в оснастке. Что такое шаблоны версии 1? Это стандартные и неуправляемые шаблоны. Их можно отличить по одному из 2-х признаков:

• В колонке Minimum Supported CAs указано Windows 2000;
• Major revision является числом от 1 до 9.

шаблоны версии 1 являются преднастроенными и не поддерживают какую-либо модификацию, кроме назначения прав во вкладке Security. Microsoft в своё время хорошенько пожадничало (вплоть до выхода Windows Server 2008 R2), заставляя кастомеров приобретать Windows Server 2003/2008 Enterprise или Datacenter Edition редакции для серверов CA, поскольку только эти редакции могли издавать сертификаты на основе управляемых шаблонов версии 2 или 3 и использовать все возможности автоэнроллмента. И даже Windows Server 2008 Standard в этом плане был почти такой же, как и Windows 2000 Server. Но это было изменено с выходом Windows server 2008 R2, потому что PKI всё больше и больше входила в сектор малого бизнеса и адекватные инструменты им стали столь же необходимы как и более крупным компаниям. Именно по этой причине Windows Server 2008 R2 Standard Edition обладает большинством тех возможностей, которые раньше были доступны только в Enterprise и Datacenter редакциях.

Поскольку шаблоны версии 1 неуправляемы, поэтому тут говорить особо не о чем, поэтому продолжим дальше.

Automatic Certificate Request

Примечание: данный материал не охватывает всех особенностей, которые присущи для Windows 7 и Windows Server 2008 R2. О них пойдёт речь в следующих частях.

Но для кого-то это может стать секретом, но даже Windows 2000 (и Windows Server 2003/2008/2008R2 Std, EE, DC) поддерживали базовый автоэнроллмент — Automatic Certificate Request. Это позволяло автоматически распространять сертификаты для компьютеров на основе шаблонов версии 1. Для включения данного режима нужно сделать следующее:

• в оснастке CertSrv.msc любого Enterprise CA в секции Certificate Templates убедиться, что в списке присутствует нужный шаблон версии 1 (например, шаблон Computer или IPsec). Если нет, то All Tasks –> New –> Certificate Template to issue и добавить шаблон;
• в редакторе групповой политики (Group Policy Management) создать новый объект групповой политики или отредактировать существующую политику по адресу:
  Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Certificate Services Client — Autoenrollment
  данный элемент политики следует установить в состояние Enabled и при необходимости выбрать автоматическое обновление просроченных сертификатов и удалении отозванных сертификатов из хранилища. Этим самым мы включим сам Autoenrollment engine, который используется для ACR.
• в редакторе групповой политики (обычно в той же самой, где включали движок автоэнроллмента) по адресу:
  Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies –> Automatic Certificate Request Settings
  создать необходимые запросы сертификатов. При этом в каждый элемент вы можете включить только один шаблон версии 1.
• прилинкуйте созданную или отредактированную политику к нужному OU (чаще всего её применяют для всего домена).

Примечание: опция Renew expired certificates, update pending certificates, and remove revoked certificates не позволяет удалять отозванные и/или просроченные сертификаты, у которых во вкладке Request Handling в списке Purposes содержится Encryption.

И как это работает.

При срабатывании триггера автоэнроллмента клиент считывает групповую политику с контроллера домена и определяет настройки политики. Эти настройки записываются в DWORD значение реестра AEFlags по адресу: HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Autoenrollment; Флаги могут иметь следующие значения или сумму следующих значений:

Примечание: триггер автоэнроллмента срабатывает при следующих действиях:

• обновление групповой политики;
• добавление машины в домен любым доступным способом.

Примечание: при установлении флажка на Renew expired certificates, update pending certificates, and remove revoked certificates активируются оба значения: 0x2 и 0x4. Из графического интерфейса не представляется возможным устанавливать эти флаги отдельно.

Далее клиент скачивает сертификаты из Active Directory:

• сертификаты CA из контейнера по адресу:
  CN=AIA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• сертификаты корневых CA из контейнера по адресу:
  CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• сертификаты агентов восстановления из контейнера по адресу:
  CN=KRA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
• сертификаты CA, которые могут издавать сертификаты для аутентификации по Kerberos из записи NTAuthCertificates по адресу:
• CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain.

На основе этих сертификатов обновляется локальное хранилище сертификатов. Теперь осталось получить список шаблонов из Active Directory по адресу:

CN=Certificate Templates, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain

После чего читается следующий раздел реестра:

HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ACRS\CTLs\<HashOfData>

в котором хранятся шаблоны для ACR (которые мы указали в политике). Шаблоны хранятся в BLOB формате. Когда шаблоны для ACR получены, клиент читает разрешения на шаблоны и из шаблонов выбирает только те, которые указаны в реестре и для которых у учёной записи компьютера есть права Read и Enroll.

Примечание: это частая ошибка, когда на компьютерные шаблоны не выданы права для учётной записи компьютера. И для успешного энроллмента, учётная запись компьютера или группа, в которой он состоит, должен иметь оба права: Read и Enroll.

Следующим этапом клиент генерирует 2 списка:

• ToBeAdded — в этот список попадут все сертификты, которые получены в результате последующих операций.
• ToBeDeleted — в этот список попадут все сертификаты, срок которых истёк и/или истекает (прошло более 80% срока жизни сертификата). А так же отозванные сертификаты.

Примечание: как я уже говорил, сертификаты у которых в Purpose содержится Encryption не помещаются в список ToBeRemoved.

Примечание: список ToBeDeleted будет создаваться только если выставлен чек-бокс Renew expired certificates, update pending certificates, and remove revoked certificates. В действительности процесс обработки этого списка отличается от написанного. Это сделано для лучшего понимания его работы. В реальности все сертификаты из контейнера Personal попадают в этот список, после чего за счёт фильтрации необходимые сертификаты удаляются из этого списка.

Клиент обновляет данные из контейнера Certificate Enrollment Requests локального хранилища сертификатов. В этом контейнере хранятся копии запросов на сертификаты, которые требуют ручного одобрения администратора CA и клиент удаляет те запросы, которые старше 60 дней. И клиент пытается получить сертификаты для каждого из запросов. Если статус запроса остаётся Pending (т.е. ещё не одобрен администратором), то переходит к следующему запросу. Если статус запроса Issued — клиент посылает запрос на получение сертификата. По получении сертификата, он помещается в список ToBeAdded. Если статус запроса Denied, то запрос удаляется из контейнера.

Примечание: эту операцию клиент будет делать только при условии, что в политике выставлен чек-бокс на Renew expired certificates, update pending certificates, and remove revoked certificates.

Когда запросы в ожидании обработаны, клиент обрабатывает контейнер Personal и список ToBeDeleted. Если сертификат на основе шаблона(-ов) политики ACR находится в контейнере Personal и содержится в списке ToBeDeleted, или вообще отсутствует в контейнере Personal, то для этих сертификатов генерируется новый запрос. Если сертификат есть в контейнере Personal, но не содержится в списке ToBeDeleted, то данный шаблон пропускается.

Если в ответ на запросы были получены сертификаты, они помещаются в список ToBeAdded. Когда все запросы и шаблоны обработаны, клиент удаляет все сертификаты из списка ToBeDeleted, а сертификаты из списка ToBeAdded помещаются в контейнер Personal локального хранилища сертификатов, после чего триггер автоэнроллмента прекращает работу.

Сегодня мы посмотрели два интересных момента: особенности шаблонов версии 1 и работу Automatic Certificate Request. В следующих частях мы рассмотрим шаблоны версии 2 и 3 и классический автоэнроллмент. Так что не отключайтесь.

Сегодня начинаю публикацию достаточно обширного и объёмного материала про автоматическую подачу заявок на сертификаты (autoenrollment). Данная тема настолько проста и на столько же сложна. И я постараюсь заполнить все пробелы в этой теме и повторить то, что мы уже знаем. Безусловно можно надеяться на ТЗ (Тайное Знание), так что кроме очевидных вещей, немного треша ожидается.

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

•  Certificate Autoenrollment от А до Я — подведение итогов

Autoenrollment background

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

• шифрование данных;
• подпись данных;
• аутентификация.

При помощи сертификатов мы можем шифровать файлы, почту, сетевой трафик, удостоверять личность пользователя с применением двухфакторной аутентификации, подпись документов, почты для предотвращения несанкционированного изменения и подлога. Поэтому компании развёртывающие инфраструктуру PKI задаются вопросом максимально быстрого и удобного способа распространения сертификатов между пользователями и компьютерами. Начиная с Windows Server 2003, Microsoft предлагает унифицированное решение этой задачи — autoenrollment. С его помощью клиенты сами без участия людей подают заявки для получения сертификата на сервер CA и устанавливают выданные сертификаты во внутреннее хранилище сертификатов. Это позволяет распространить сертификаты на огромное количество компьютеров затратив на это минимум усилий. Даже в условиях небольших компаний (до 50 машин) ручной запрос и установка сертификатов будет крайне утомительным делом, поскольку недостаточно запросить сертификат, но и нужно вовремя его обновить. В обычных условиях пришлось бы держать выделенного человека, который будет следить за всеми сертификатов всех пользователей и компьютеров и платить ему зарплату. Именно для устранения этой проблемы и ускорению ввода PKI в эксплуатацию и был разработан автоэнроллмент.

Autoenrollment requirements

Примечание: данный цикл статей не будет затрагивать особенности эксплуатации автоэнроллмента для Windows 2000.

Для успешного внедрения автоэнроллмента требуются следующие компоненты:

• домен Active Directory;
• объект групповой политики;
• клиент под управлением Windows 2000 и выше. Клиент должен быть членом домена;
• Enterprise Certification Authority под управлением Windows Server 2003 и выше.

Примечание: не для всех операционных систем требуется жёсткое удовлетворение этим требованиям. Для более точных требований к ОС для каждого метода смотрите в таблице ниже.

Автоэнроллмент различает 2 метода автоматического распространения сертификатов:

• Automatic Certificate Request (ACR) — поддерживает автоматическое распространение сертификатов для компьютеров на основе шаблонов версии 1.
• Autoenrollment — поддерживает автоматическое распространение сертификатов для компьютеров и пользователей на основе шаблонов версии 2 и 3.
• XCEP Autoenrollment — поддерживает автоматическое распространение сертификатов для недоменных пользователей и компьютеров на основе шаблонов версии 2 и 3 с использованием HTTP в качестве транспорта.

В последующих статьях мы весьма подробно ознакомимся с каждым из них. На данном этапе вам достаточно знать об их существовании.

Таблица 1: возможности использования автоэнроллмента для клиентов.

* Out of domain показывает возможность использование автоэнроллмента без членства клиента в домене Active Directory.
** Home редакции Windows XP и Windows Vista не поддерживают функции автоэнроллмента.

Данная таблица показывает, что клиенты под управлением Windows 2000 могут автоматически запрашивать сертификаты только на основе шаблонов версии 1 и только для компьютеров (ACR). Windows XP/2003 могут автоматически запрашивать сертификаты на основе шаблонов версии 1 и только для компьютеров (ACR) и шаблонов версии 2 для пользователей и компьютеров. Windows Vista/2008 позволяют автоматически запрашивать сертификаты на основе шаблонов версий 1, 2 и 3 с учётом общих ограничений шаблонов версии 1. А Windows 7/2008 R2 плюс к предыдущему могут использовать автоматическую подачу заявок без членства в домене с использованием технологии XCEP Autoenrollment.

Таблица 2: возможности Enterprise CA для реализации возможностей автоэнроллмента.

* колонка XCEP показывает возможность установки компонента HTTP-enrollment. Данный компонент может работыть на сервере без установки роли Certification Authority.
** Веб служба, реализующая возможности использования HTTP-enrollment должна работыть под управлением Windows Server 2008 R2 EE/DC.
*** Std означает Standard Edition, EE — Enterprise Edition; DC — Datacenter Edition. Itanium-based системы не поддерживают роль CA.

Данная таблица демонстрирует возможности Certification Authority в зависимости от версии и редакции ОС на которой эта роль установлена. Например, Windows Server 2003 и 2008 Std могут использовать только ACR и распространять сертификаты на основе шаблонов версии 1 и только для компьютеров. Windows Server 2003 EE/DC могут использовать как ACR, так и классический автоэнроллмент, автоматически распространяя сертификаты на основе шаблонов версии 2 как компьютерам, так и пользователям. А Windows Server 2008 EE/DC и редакции Windows Server 2008 R2 Std/EE/DC могут автоматически распространять сертификаты для пользователей и компьютеров на основе шаблонов версии 1 (ACR), 2 и 3.

Для общего введения этого должно быть более, чем достаточно. В ближайших частях мы кратко посмотрим на шаблоны сертификатов и более детально разберём работу ACR (Automatic Certificate Request).

продолжение следует…

Этим постом я начинаю серию небольших заметок по не всегда очевидным фактам в PKI. И сегодня начну с первого факта — OCSP или CRL? OCSP и CRL — это 2 модели, которые могут использоваться для проверки сертификата на предмет его отзыва.

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

Модель CRL используется с самого начала существования PKI и выглядит следующим образом. Сервер CA отзывает некоторый сертификат и помещает о нём запись в специальный файл CRL. При этом туда помещается серийный номер сертификата, дата фактического отзыва (не обязательно совпадает со временем когда администратор отозвал сертификат) и причина отзыва. Клиенты при проверки сертификатов скачивают эти CRL и проверяют есть ли серийный номер этого сертификата в CRL. Логично, что чем больше сертификатов отозвано, тем больше файл, тем более нагружается сеть при частом скачивании относительно большого файла CRL.

В OCSP используется немного иной принцип. Клиент OCSP отправляет на сервер OCSP Responder специальный запрос, в котором содержится серийный номер проверяемого сертификата. OCSP Responder «пробивает номер по своей базе» и отвечает клиенту откликом. Этот отклик содержит однозначный ответ на вопрос: отозван или не отозван.

Казалось бы, если у вас и серверы и клиенты работают под управлением Windows Vista/2008 и выше, то ответ однозначный: OCSP — наше всё! Ну и вообще даже при наличии небольшого количества этих систем (а преимущественно используются устаревшие клиенты Windows XP/2003), то OCSP нам никак не помешает! Но на самом деле это не всегда так и в ряде ситуаций использование OCSP будет даже нежелательным. Давайте посмотрим почему. Сначала сделаем сравнительные характеристики обеих моделей проверки отзыва

• CRL

Исходный размер пустого CRL составляет порядка 600 байт (но это значение может отличаться в зависимости от длины полей и длины ключа подписи). На каждую запись отозванного сертификата в CRL отводится 80 байт. Это, как я уже говорил, серийный номер отозванного сертификата, дата фактического отзыва и числовое обозначение причины отзыва. Т.е. если у вас отозвано 10 сертификатов, то размер CRL будет 600 + 80 * 10 = 1400 байт. Если отозвано 100 сертификатов, то размер CRL будет порядка 9кб и т.д.

• OCSP

Каждая проверка статуса сертификата потребляет определённый размер трафика — 2кб. При этом неважно какого размера сам CRL. Даже если отозвано 100 000 сертификатов, то CRL будет размером примерно 8мб. И каждый устаревший клиент будет скачивать этот файл на 8 мегабайт. А с OCSP любой запрос и ответ на него займёт всего 2кб. Удобно? Безусловно.

Однако, в ряде случаев я бы не рекомендовал использовать OCSP для сертификатов, которые аутентифицируют клиентов. К ним относятся следующие типы сертификатов:

• сертификаты смарт-карт;
• сертификаты аутентификации в IIS;
• клиентские сертификаты компьютеров для VPN/L2TP и IPsec;
• сертификаты аутентификации пользователей в VPN (EAP-TLS).

Почему? Дело в том, что аутентифицирующий сервер кеширует все данные об отзыве. Сначала в памяти, потом на диске (когда происходит свопинг). И давайте посмотрим на типичный сценарий:

У вас на предприятии используется корпоративный веб-сайт с аутентификацией пользователей по сертификату. У вас 1000 пользователей и они все утром подключаются к веб-сайту. Веб-сервер при проверке подлинности каждого пользователя будет посылать OCSP запрос на OCSP Responder запросы с серийным номером каждого сертификата. Мы знаем, что размер каждого ответа составляет 2кб, следовательно сервер отправит 1000 HTTP запросов и закеширует у себя в памяти 2 мегабайта памяти.

А теперь представьте, что у вас не используется OCSP, а только CRL и на сервере CA отозвано 100 сертификатов. Как мы знаем сам контейнер CRL занимает 600 байт и каждая запись по 80 байт. В итоге файл CRL будет занимать 9 килобайт! И в этом случае сервер сделает только одну «ходку» за CRL файлом и уже всех клиентов будет проверять именно по скачанному CRL. Как видите, профит от использования CRL здесь очевиден. Серверу надо меньше тратить сетевого трафика и меньше данных кешируется в памяти. При этом OCSP целесообразно включать для серверных сертификатов, потому что клиентов обычно много и им выгодней использовать небольшии порции трафика OCSP.

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

• для серверных сертификатов рационально использовать OCSP;
• для клиентских сертификатов, которые используются для аутентификации часто рациональней будет использовать классические CRL, вместо OCSP.

Поэтому при рассмотрении вопроса внедрения OCSP вы должны учитывать эти моменты, чтобы ваша PKI была более эффективной.

Ссылки по теме:

OCSP (часть 1)
OCSP (часть 2)
http://en.wikipedia.org/wiki/Certificate_revocation_list