Автоматическая подача заявки на сертификат локальная система

V2/V3 Templates

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

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

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

Вкладка General

Template display name — отображаемое имя шаблона. Используется для удобства распознавания шаблона пользователем.
Template name — это уже внутреннее имя шаблона по которому учётные записи и службы находят шаблоны.
Validity 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.
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 — позволяет экспортировать (например, для бэкапа) закрытый ключ данного сертификата из локального хранилища сертификатов.
CSP — позволяет выбрать Cryptographic Service Provider для генерации закрытого ключа. Для автоэнроллмента следует установить не более одного провайдера.

Вкладка Subject name

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

Вкладка Issuance Requirements

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

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

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

Вкладка Superseded templates

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

Вкладка Security

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

Read
Enroll
Autoenroll

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

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

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

Как проверить правильность установки SSL-сертификата

Проверка SSL-сертификата на корректность установки производится с помощью сервиса sslshopper.com.

Проверить SSL-сертификат сайта онлайн можно по инструкции ниже:

Введите имя вашего домена и нажмите Check SSL. Если у вас кириллический домен, то его надо ввести в формате Punycode.
При корректной установке SSL-сертификата вы увидите примерно такой результат:

Если сертификат установлен некорректно, свяжитесь со службой технической поддержки.

Подача заявления на сайте Госуслуги

Войдите в аккаунт вашей организации.
Затем нажмите Получить сертификат:
Укажите данные сотрудника, который отвечает за информационную безопасность. Список необходимых контактов:фамилия и имя,номер телефона,электронная почта.Затем нажмите Продолжить.
фамилия и имя,
номер телефона,
электронная почта.
файл запроса с расширением .csr,файл подписи с расширением .sig.
файл запроса с расширением .csr,
файл подписи с расширением .sig.
Затем нажмите Далее. Для подтверждения выпуска сертификата с вами свяжутся по контактным данным, которые вы указали на предыдущем шаге.

Готово, заявление будет обработано в течение 5 рабочих дней.

Что дальше?

После установки SSL-сертификата сайт становится доступным как по http://, так и по https://. Но по умолчанию сайт открывается по небезопасному протоколу http://. Чтобы сайт всегда открывался по защищённому протоколу, настройте переадресацию на https://. Следуйте инструкциям, чтобы узнать, как подключить HTTPS на сайте:

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 и отправляет этот запрос на сервер.
После отправки запроса на сервер, клиент через тот же интерфейс получает статус своего запроса.

Читать также: Многодетные семьи в Волгоградской области получили 300 000 рублей вместо участка земли

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

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

Group Policy configuration

После установки службы CEP у вас появляется адрес HTTP, который указывает на сервер CEP и этот адрес имеет вид:

где auth_protocol указывает на протокол аутентификации клиента на сервере CEP. Это может быть Kerberos (только для доменных клиентов), Password или Certificate. Вот этот адрес нужно добавить в настройки групповой политики. Для этого откройте редактор групповой политики (gpmc.msc или gpedit.msc для недоменных машин) и в секции: Computer ConfigurtionWindows SettingsSecurity SettingsPublic Key Policies настроить параметр Certificate Services Client — Certificate Enrollment Policy. В свойствах следует включить эту политику и вы увидите окно Certificate Enrollment Policy list и в котором уже одна политика будет определена. Предопределённую политику следует удалить совсем и кнопкой Add добавить новую. В открывшемся окне вставить эту ссылку, указать нужный тип аутентификации и нажать Validate. В результате вы должны получить нечто вроде такого:

Если вам это удалось сделать, значит клиент смог успешно пообщаться с сервером XCEP и CES. Причём, вы увидите, что клиент по этой ссылке смог найти название данной политики и вставить её в окошко:

И таким образом вы можете добавлять несколько различных адресов политик, которые могут относиться к различным организациям. Причём, организация может развернуть несколько серверов XCEP для обеспечения высокой доступности, тогда вы можете добавлять несколько адресов серверов CEP и они будут линковаться к одной политике.

Следует чётко понимать, что на предыдущей картинке вы видите коллекцию серверов CEP (Policy collection). Каждое имя уникально идентифицирует политику, которая может поддерживаться несколькими серверами CEP. Чтобы посмотреть сколько серверов CEP обслуживают ту или иную политику, выделите нужную политику и нажмите Properties. В результате вы увидите нечто похожее на это:

Уникальность политики определяется по её GUID’у. В этом окне может формироваться список всех серверов CEP, которые обслуживают одну и ту же политику (с одинаковым GUID’ом). По умолчанию для всех политик включается разрешение автоэнроллмента.

галочка Enable for automatic enrollment and renewal не является самодостаточной и зависит от классической политики автоэнроллмента. Если автоэнроллмент отключен, то соответственно, автоматическая подача заявок на сертификаты производиться не будет.

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

для успешного энроллмента сертификатов на основе новых шаблонов (для которых у клиента ещё нет ни одного сертификата) галочка Update certificates that use certificate templates обязательна!

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

Client behavior

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

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

Данные ключи будут содержать подключи политик. Каждому подключу политики присваивается уникальный GUID и внутри него будет содержаться необходимая информация о каждой политике, как URI, метод аутентификации, «стоимость» политики и флаги автоэнроллмента. После этого происходит сортировка политик по следующим правилам:

сортируются по «стоимости» политики. Политика с меньшей стоимостью будет более приоритетной и политика с большей стоимостью будет менее приоритетной, соответственно. Если 2 и более политик имеют одинаковую стоимость, то идёт второй уровень сортировок по методу аутентификации (в порядке приоритета):
используется аутентификация Kerberos;
используется анонимная аутентификация;
остальные политики используются в том порядке, в каком они записаны в реестре.
используется аутентификация 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

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

Автоматическая установка в ЛК

Если вы заказывали бесплатный SSL-сертификат, то можете автоматически установить его через карточку услуги SSL. Если у вас другой SSL-сертификат и ваш хостинг находится в REG.RU, установите SSL через карточку хостинга. В других случаях вам подойдет ручная установка сертификата.

В личном кабинете перейдите в карточку нужного SSL-сертификата:
Нажмите Установить на вкладке «Управление»:

В личном кабинете перейдите в карточку нужного хостинга:
На вкладке «Операции» нажмите Установить SSL-сертификат:

Group Policy settings

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

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

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

Client bahavior

Данные разделы реестра содержат настройки автоэнроллмента для конфигурации компьютера и пользователя, соответственно (более подробней о содержимом этих разделов реестра читайте во второй части). Следующим шагом клиент считывает данные из 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 содержит устаревшие и неиспользуемые более шаблоны, то они так же исключаются из списка. Следующим этапом исключаются шаблоны, в настройках которых содержится:

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

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

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

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

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

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

Читать также: Сертификат соответствия или декларации о соответствии лекарственных средств это

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

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

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.

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

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

Preamble

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

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

При каких условиях выдаётся SSL-сертификат

Чтобы получить российский SSL-сертификат, направьте заявление на сайте Госуслуги.

Чтобы инициировать выпуск SSL-сертификата, понадобится усиленная квалифицированная электронная подпись.

Подача заявки на выпуск сертификата состоит из трёх этапов:

создание запроса и приватного ключа,
подписание запроса УКЭП,
подача заявления на сайте Госуслуги.

Ручная установка в панели хостинга

Чтобы установить SSL-сертификат, войдите в вашу панель управления (ISPmanager, cPanel или Plesk) и следуйте соответствующей инструкции ниже:

Обратите внимание! Если внешний вид вашей панели управления отличается от представленного в инструкции, кликните в левом нижнем углу «Попробовать новый интерфейс».

Перейдите в раздел «SSL-сертификаты» и нажмите Добавить сертификат:
Выберите тип сертификата «Существующий» и нажмите Далее:
Заполните поля на открывшейся странице. Данные для установки сертификата высылаются на почту после активации услуги: Где взять данные для установки SSL-сертификата.— Имя SSL-сертификата — введите любое имя, под которым сертификат будет отображаться в панели управления (можно использовать только латиницу);— SSL-сертификат — вставьте данные SSL-сертификата (в информационном письме он находится после слов «Ваш сертификат предоставлен ниже»);— Ключ SSL-сертификата — вставьте приватный ключ сертификата;— Цепочка SSL-сертификатов — вставьте сначала промежуточный сертификат, а затем с новой строки без пробела — корневой.
Нажмите Завершить:
После завершения установки перейдите в раздел «Сайты», дважды кликните по домену, для которого выпускался сертификат:
Поставьте галочку напротив Защищенное соединение (SSL). В раскрывающемся списке напротив SSL-сертификат выберите имя SSL-сертификата, установленного в 4 шаге. Затем нажмите Оk внизу страницы:Готово, SSL-сертификат установлен. Проверка сертификата (HTTPS) на корректность установки осуществляется по инструкции ниже.

Обратите внимание: если вид вашей панели управления отличается от представленного в статье, в разделе «Основная информация» переключите тему с paper_lantern на jupiter.

В блоке «Безопасность» нажмите SSL/TLS:
Нажмите Управление SSL-сайтами:
Пролистайте до блока «Установить SSL-сайт». В раскрывающемся списке выберите домен, для которого устанавливаете SSL-сертификат:
Заполните поля. Данные для установки сертификата высылаются на почту после активации услуги: Где взять данные для установки SSL-сертификата.— Сертификат: (CRT) — вставьте SSL-сертификат (в информационном письме он находится после слов «Ваш сертификат предоставлен ниже»);— Закрытый ключ (KEY) — вставьте приватный ключ сертификата;— Пакет центра сертификации: (CABUNDLE) — вставьте сначала промежуточный сертификат, а затем с новой строки без пробела — корневойНажмите кнопку Установить сертификат:
Чтобы завершить установку, нажмите OК в появившемся окне:Готово, SSL-сертификат установлен. Как проверить сертификат сайта онлайн?

Обратите внимание! Если внешний вид вашей панели управления отличается от представленного в инструкции, перейдите в раздел «Сайты и домены» и в правом верхнем углу измените вид на «Активный».

В разделе «Сайты и домены» выберите блок того домена, для которого выпускался SSL-сертификат, и нажмите SSL/TLS-сертификаты:
Нажмите Добавить SSL/TLS-сертификат:
Заполните поля на открывшейся странице. Данные для установки сертификата высылаются на почту после активации услуги: Где взять данные для установки SSL-сертификата?— Имя сертификата — введите любое имя, под которым сертификат будет отображаться в панели управления (можно использовать только латиницу);— Закрытый ключ (.key) — вставьте приватный ключ сертификата;— Сертификат (.crt) — вставьте сам SSL-сертификат (в информационном письме он находится после слов «Ваш сертификат предоставлен ниже»);— Корневой сертификат (-ca.crt) — вставьте сначала промежуточный сертификат, а затем с новой строки без пробела — корневой.Нажмите Загрузить сертификат:
После установки сертификата в панели появится уведомление о том, что нужно привязать SSL-сертификат к домену. Чтобы сделать это, вернитесь в раздел «Сайты и домены» и нажмите Настройки хостинга:
В блоке «Безопасность» поставьте галочку напротив Поддержка SSL/TLS. Выберите в выпадающем списке имя сертификата, установленного в 4 шаге. Нажмите Применить внизу страницы:Готово, SSL-сертификат установлен. Проверить наличие SSL-сертификата на сайте можно по инструкции.

Подписание запроса УКЭП

Файл с запросом нужно подписать УКЭП. Для этого используйте КриптоПро или другую программу, с которой работает ваша организация. Сохраните подпись в формате .sig.