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

Также данный раздел определяет порядок развёртывания первоначальной инфраструктуры PKI на базе решений компании «Аладдин Р.Д.».

Порядок развёртывания определяется в зависимости от выбранной модели миграции ИТ-инфраструктуры и PKI-инфраструктуры. Подробные инструкции и описание возможный моделей миграции инфраструктур приведены в разделе 4 настоящего документа.

Более детальное (программное) описание действий – по работе с интерфейсом и настройкой программных продуктов Aladdin, приведённых в данном разделе, описано в эксплуатационной документации на программные продукты.

Развёртывание Центра валидации

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

Центр валидации поддерживает взаимодействие с администратором, работающим на удалённом сервере, только по протоколу HTTPS с аутентификацией удалённого администратора по клиентскому сертификату, и администратором, работающим локально на сервере Центра валидации по протоколам HTTP/HTTPS без дополнительной аутентификации.

  • На сервере Центра валидации установите вспомогательное ПО (СУБД, Java);
  • Произведите проверку портов необходимых для успешной работы Центра валидации, при необходимости
    произведите их настройку;
  • Произведите подготовку предустановочных конфигурационных файлов и выполните установку компонента
    «Центр валидации Aladdin eCA».

После завершения установки в терминале будут выведены учётные данные администратора инициализации, от имени которого необходимо будет выполнять дальнейшие действия по инициализации. Их следует сохранить в надёжном месте. Также сертификат данного пользователя можно получить в каталоге /opt/aecaCa/dist/certificates/account/INITIAL_ADMIN.p12.

  • Выполните настройку АРМ администратора Центра валидации:
    - импортируйте сертификат администратора инициализации superadmin.p12 в браузер;
    - подключитесь по IP-адресу Центра валидации, например, https://<ip-адрес>:8888/aecaVa/.
  • Все дальнейшие действия по работе с Центром валидации осуществляются через сервер Подчинённого Центра
    сертификации. 

Ввод в эксплуатацию корневого центра сертификации

Корневой ЦС (Root CA) позволяет выпускать сертификаты для пользователей, серверов или отдельных программ и служб в инфраструктуре.

К созданию центра сертификации необходимо отнестись с большой ответственностью, т. к. пересоздание корневого сертификата может повлечь за собой отзыв старых и выдачу новых сертификатов клиентам, или необходимость поддерживать несколько сертификатов доверенных центров в системах, что вызывает дополнительную нагрузку на администрирующий персонал. Желательно, как можно полнее отразить процессы жизненного цикла сертификатов в формальных документах. 

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

Для установки корневого ЦС:

  • На сервере корневого Центра сертификации установите вспомогательное ПО (СУБД, Java 17, JC-WebClient);
  • Произведите подготовку предустановочных конфигурационных файлов и выполните установку компонента «Центр сертификации Aladdin eCA».

В результате успешной установки программного компонента «Центр сертификации Aladdin Enterprise Certificate Authority» в установочном каталоге будет сформирован сертификат доступа администратора инициализации /opt/aecaCa/dist/certificates/account/INITIAL_ADMIN.p12 (установленное значение параметра certificates_account_path конфигурационного файла config.sh), PIN-код сертификата указан в параметре initial_server_password конфигурационного файла /opt/aecaCa/scripts/config.sh, по умолчанию – «INITIAL».

  • Выполните настройку АРМ администратора Центра сертификации:
    - импортируйте сертификат администратора инициализации INITIAL_ADMIN.p12 в доверенное хранилище браузер;
    - подключитесь по IP-адресу или полному доменному имени сервера, на котором развёрнуто ПО, например, https://<ip-адрес или hostname>.

Все дальнейшие действия по работе с Центром сертификации осуществляются через веб-браузер:

  • Зайдите на сервер ЦС как Администратор.
  • Выполните начальную инициализацию Центра сертификации:
    - Загрузите лицензию для корневого ЦС.
    - Имя ЦС будет задано автоматически, в зависимости от данных загруженной лицензии.
    - Задайте суффикс в формате Х.500. При задании суффикса следует руководствоваться несколькими рекомендациями:
    •  суффикс должен отражать название отдела или подразделения, которое отвечает за его управление в атрибуте OU (Organizational Unit);
    •  дублировать полное название организации (атрибут O, Organization);
    •  отражать юридическое место дислокации ЦС. Для этого достаточно использовать атрибуты L (Locality) и C (Country). Как правило, это название города и страны, где юридически зарегистрирована организация. Если необходимо, можно указать штат/область посредством атрибута S (State).

- Установите срок действия сертификата. Обычно задают срок минимум в 2 – 5 раз больше, чем планируемый срок действия выданных сертификатов подчинённых ЦС. Максимальный срок жизни сертификата равен 25 лет, вы можете изменить его в соответствии с вашей политикой. Сертификаты уровня CA имеют более длительный срок действия, поскольку истечение срока действия сертификата CA автоматически означает прекращение действия всех выданных им сертификатов. Как ориентировочные значения можно принять 20-летний жизненный цикл для корневого сертификата.
- Определите параметры шифрования, выбрав алгоритм ключа, длину ключа и алгоритм хэш-суммы.
- Создается корневой сертификат в виде файла формата ***.pem.

***.pem — файл публичного сертификата ЦС. Серверы и клиенты будут использовать этот сертификат для подтверждения единой сети доверия. Копия этого файла должна иметься у всех серверов, использующих ваш ЦС. Все стороны будут использовать публичный сертификат для подтверждения подлинности системы.

Ввод в эксплуатацию подчиненного центра сертификации

После установки корневого центра сертификации необходимо установить подчиненный центр сертификации для реализации ограничений политики инфраструктуры открытого ключа и для выдачи сертификатов конечным клиентам. Использование хотя бы одного подчиненного центра сертификации способствует защите корневого центра сертификации от необязательного воздействия извне.

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

Для установки подчиненного ЦС:

  • На сервере подчинённого Центра сертификации установите вспомогательное ПО (СУБД, Java 17, JC-WebClient);
  • Произведите подготовку предустановочных конфигурационных файлов и выполните установку компонента «Центр сертификации Aladdin eCA».

В результате успешной установки программного компонента «Центр сертификации Aladdin Enterprise Certificate Authority» в установочном каталоге будет сформирован сертификат доступа администратора инициализации /opt/aecaCa/dist/certificates/account/INITIAL_ADMIN.p12 (установленное значение параметра certificates_account_path конфигурационного файла config.sh), PIN-код сертификата указан в параметре initial_server_password конфигурационного файла /opt/aecaCa/scripts/config.sh , по умолчанию – «INITIAL».

  • Выполните настройку АРМ администратора Центра сертификации:
    - импортируйте сертификат администратора инициализации INITIAL_ADMIN.p12 в доверенное хранилище браузер;
    - подключитесь по IP-адресу или полному доменному имени сервера, на котором развёрнуто ПО, например, https://<ip-адрес или hostname>.

Все дальнейшие действия по работе с Центром сертификации осуществляются через веб-браузер.

  • Зайдите на сервер Центра Сертификации как Администратор.
  • Выполните начальную инициализацию ЦС в соответствии с разделом3 «Центр сертификатов Aladdin Enterprise Certificate Authority» Руководства администратора RU.АЛДЕ.03.01.020-01 32 01-2, для этого:
    - Загрузите лицензию для подчинённого ЦС.
    - Имя ЦС будет задано автоматически, в зависимости от данных загруженной лицензии.
    - Задайте суффикс в формате Х.500. При задании суффикса следует руководствоваться несколькими рекомендациями:
    •  суффикс должен отражать название отдела или подразделения, которое отвечает за его управление в атрибуте OU (Organizational Unit);
    •  дублировать полное название организации (атрибут O, Organization);
    •  отражать юридическое место дислокации ЦС. Для этого достаточно использовать атрибуты L (Locality) и C (Country). Как правило, это название города и страны, где юридически зарегистрирована организация. Если необходимо, можно указать штат/область посредством атрибута S (State).

- Определите параметры шифрования, выбрав алгоритм ключа, длину ключа и алгоритм хэш-суммы.
- Создается подчиненный центр сертификации в состоянии «Запрос». 
- Скачайте файл запроса .csv созданного подчиненного ЦС.
- Перенесите файл запроса .csv созданного подчиненного ЦС на АРМ корневого ЦС любым удобным способом.
- Загрузите файл-запрос на Корневом Центре сертификации.
- Выполните процедуру подписания запроса на сертификат подчиненного ЦС, предварительно создав (при необходимости) или выбрав предустановленный шаблон сертификата подчинённого ЦС (по умолчанию установлен шаблон SubCA с периодом действия сертификата 10 лет).

Сертификаты подчиненного ЦС подписывается корневым ЦС, который надежно хранится в автономном режиме и используется для подписи сертификатов конечных объектов. Корневой ЦС подтверждает достоверность промежуточных CA, которые, в свою очередь, подтверждают полномочия ЦС самого нижнего уровня. Выдающие сертификаты ЦС подтверждают достоверность сертификатов индивидуальных пользователей, которым были выданы сертификаты. На каждом уровне выдается сертификат для нижестоящего уровня и определяются политики и правила, управляющие использованием и временем жизни сертификатов. Иерархическая система взаимосвязей сертификатов формирует цепочку сертификации.

- Скачайте цепочку сертификатов корневого ЦС в формате *.pem на последнем этапе подписания запроса на сертификат ЦС и перенесите её любым удобным способом на АРМ подчиненного ЦС.
- Импортируйте цепочку сертификатов в подчиненный ЦС в состоянии «Запрос» в соответствии с пунктом 4.3.1.3 «Центр сертификатов Aladdin Enterprise Certificate Authority» Руководства администратора RU.АЛДЕ.03.01.020-01 32 01-2.
- Подчиненный ЦС из состояния «Запрос» переходит в состоянии «Активирован».

Регистрация нового центра валидации

После того, как корневой ЦС установлен и сконфигурирован, необходимо приступать к регистрации Центра валидации на подчинённом Центре сертификации для:

1) Создания и настройки сервиса распространения списков отзыва CRL DP. Каждый издающий (подчиненный) ЦС будет публиковать свой список отзыва, используя HTTP-протокол и web-сервер Центра валидации.

  • Для настройки этого сервиса необходимо задать:

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

    •  все ЦС, которые выдают сертификаты только другим ЦС (не конечным потребителям), должны публиковать CRL сроком действия от 3-х до 12 месяцев с запасом в один месяц;
    • все ЦС, которые выдают сертификаты конечным потребителям (пользователям и устройствам), должны публиковать базовые CRL не реже одного раза в неделю.

- период обновления DeltaCRL – время между публикациями Delta CRL. Период публикации DeltaCRL должен быть меньше периода публикации CRL. Период публикации DeltaCRL может быть не задан, тогда DeltaCRL не публикуется;
- срок действия перекрытия – задается период действия текущего списка CRL до публикации нового списка CRL, согласно настроенному периоду.

После изменения значений «Автообновления CRL» необходимо сохранить изменения и опубликовать CRL.

  • Точка распространения списков отзыва, которая будет регистрироваться в издаваемых сертификатах с указанием пути, по которому клиенты могут скачать список отзыва. Этот путь публикуется в сервисе CRL для каждого ЦС.

2) Создания и настройки сервиса AIA для определения места хранения актуальных сертификатов издающих ЦС.

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

  • Для доступа к хранилищу сертификатов используются те же точки распространения развернутого web-сервера, что для распространения CRL.
  • Обе эти точки содержатся во всех выданных удостоверяющим центром сертификатах и, соответственно, должны быть доступны всем потребителям. Клиенты должны обладать возможностью проверять цепочку сертификатов и список отзыва, обращаясь по тем данным, которые указаны в сертификате, то есть определены в AIA и CRL при настройке.

3) Развертывания OCSP-сервера, работающего по протоколу HTTP. OCSP-сервер обрабатывает запросы на проверку сертификатов субъектов, так что здесь следует применять аппаратное обеспечение сервера с возможностью масштабирования, соответствующей прогнозируемой потребности в подключениях.

4) Внесения сведений об OCSP-сервере (url-адрес OCSP) в удостоверяющий центр для добавления местонахождения сервера OCSP в подписываемые им сертификаты

Когда удостоверяющий центр подписывает сертификат, обычно он добавляет в сертификат адрес сервера OCSP. Например, когда пользователь встречает сертификат сервера, он отправляет запрос серверу OCSP, указанному в сертификате. На этом адресе OCSP-ответчик ожидает запросы и сообщает о статусе сертификата - отозван он или нет. Ответчику OCSP необходима криптографическая пара для подписания ответа, который он отправляет запрашивающей стороне. Криптографическая пара OCSP должна быть подписана тем же удостоверяющим центром, которым подписан проверяемый сертификат.

Перед регистрацией Центра валидации необходимо выполнить настройку автообновления периода обновления CRL, при необходимости, настроить публикацию DeltaCrl, и выпустить первый CRL.

  • Основные этапы регистрации Центра валидации:
    - скопируйте и перенесите на текущий подчинённый ЦС сертификат администратора Центра валидации /opt/aeca/p12/superadmin.p12 и пароль из файла generated_passwords.txt;
    - запустите Мастер регистрации центра валидации, нажав кнопку <Зарегистрировать +> на вкладке «Центры валидации» сервера Подчинённого Центра сертификации;
    - в открывшемся окне Мастера регистрации укажите ip-адрес или имя хост-сервера с указанием доменной зоны, на котором развёрнут компонент «Центр валидации» Aladdin eCA;
    - загрузите предварительно скачанный сертификат superadmin.p12 сервера Центр валидации;
    - далее выполните подписание запроса OCSP нажав одноимённую кнопку в окне Мастера регистрации центра валидации.
  • В результате:
    - активированы службы AIA и CRL DP;
    - активирована служба OCSP.

Подключение существующей точки распространения CRL DP

По умолчанию службы сертификатов Active Directory (AD CS) настраивают точки распространения списка отзыва сертификатов (CRL), которые включают имя компьютера ЦС в пути. Это означает, что все сертификаты, выданные ЦС, могут содержать пути проверки сертификатов со старым именем узла. Эти пути могут быть недопустимыми после миграции. Чтобы избежать ошибок при проверке отзыва, необходимо сохранить доступность списков отзыва по старым путям также необходимо настроить точки распространения на новом ЦВ.

  • Для этого произведите регистрацию на Центре сертификации Aladdin eCA существующих точек распространения CRL, DeltaCRL и/или AIA в разделе «Центра валидации» на вкладке «Точки распространения».

Подключение ресурсной системы

Для загрузки субъектов доменной структуры и дальнейшего выпуска для них сертификатов необходимо выполнить подключение к ресурсной системе контроллера домена на сервере подчинённого Центра сертификации.

  • Aladdin Enterprise CA поддерживает следующие типы ресурсных систем:
    - Samba DC;
    - РЕД АДМ;
    - ALD PRO;
    - MS AD;
    - FreeIPA.
  • Выполните подключение контроллера домена к ресурсной системе подчиненного ЦС для загрузки всех субъектов доменной сети в Центр Сертификации.

Экспорт шаблонов

  • Шаблоны, используемые для выпуска сертификатовЦентромсертификацииMS CA, могут быть экспортированы при помощи скрипта mscs2aeca.ps1, входящего в дистрибутив программного компонента «Центр Сертификации Aladdin eCA».
  • Для успешного выполнения скрипта необходимо интернет-соединение. Для успешного выполнения скрипта в оффлайн режиме требуется предварительно скачать и установить пакет NuGet.
  • Cкрипт запускается как консольное приложение и работает в режиме командной строки, графический интерфейс не предусмотрен. Запуск скрипта произвести под учётной записью с доступом ко всем шаблонам на чтение.
  • Результатом работы скрипта является сохранение CSV с данными всех шаблонов сертификатов из MSCS в папку C:\temp\ на хосте.
  • Импортируйте сохранённые шаблоны MS CA в Подчинённый Центр сертификации Aladdin Enterprise Certificate Authority в разделе «Шаблоны».
  • Также произведите настройку необходимых вам шаблонов, предварительно клонировав предустановленный шаблон.

Создание учётных записей

  • Учетная запись пользователя однозначно идентифицирует пользователя, который использует компьютерную систему. Учетная запись сообщает системе, что необходимо применить соответствующую авторизацию, чтобы разрешить или запретить доступ пользователей к ресурсам. В Центре сертификации Aladdin eCA реализованы роли с правами администратора и оператора:
    - оператор. Пользователь с ролью «Оператор» обладает правами на работу с субъектами группы, над которой он может осуществлять свои ролевые права, и принадлежащими им сертификатами (выпуск, отзыв, приостановка и возобновление сертификата), имеет полномочия запуска обновления списка субъектов из настроенного источника. Для конкретного «Оператора» можно определить перечень субъектов, над которыми он может осуществлять свои ролевые права, а также перечень групп субъектов, над элементами которых он может осуществлять свои ролевые права.

- администратор. Пользователь с ролью «Администратор» имеет полные права доступа к программному средству «Центр сертификатов доступа Aladdin Enterprise Certificate Authority Certified Edition», и программному интерфейсу API, к функциональным задачам, к функциям управления учетными записями Центра сертификации. Все учётные записи могут быть созданы, отредактированы, удалены или заблокированы администратором.

  • Создайте учётные записи для субъектов подключенной или локальной ресурсной системы для авторизации на сервере Центра сертификации Aladdin Enterprise Certificate Authority с правами администратора и оператора с целью дальнейшего выпуска сертификата доступа.
  • Для учётной записи с правами оператора назначьте права на доступ к субъектам ресурсных систем.

Настройка издателей

Для успешной аутентификации администратора/оператора на серверной части программы необходимо, чтобы издатель был активен. Перейдите в раздел «Настройки» в поле «Разрешенные издатели» выберите издателя – Подчинённый удостоверяющий центр, от имени которого был выпущен сертификат учетной записи, и проверьте, что издатель активен. Если издатель не активен, то активируйте его.

Настройка АРМ администратора

  • Перед началом работы с Центром сертификации на АРМ администратора необходимо произвести двустороннюю HTTPS-аутентификацию администратора для входа в учётную запись.
  • Для настройки аутентификации произведите следующие действия на АРМе администратора:

- скопируйте и перенесите созданный сертификат администратора на АРМ администратора;

- откройте браузер. Для браузера Firefox в меню выберите Настройки – Приватность и Защита – Сертификаты. Нажмите кнопку <Просмотр сертификатов>;

- выберите вкладку «Ваши сертификаты», в открывшейся вкладке нажмите кнопку <Импортировать>;

- выберите файл перенесённого сертификата учетной записи на локальном диске. Нажмите кнопку <Открыть>;

- введите пароль контейнера pkcs#12, указанный при создании сертификата учетной записи администратора в открывшемся окне, и нажмите кнопку <Ок>;

- для входа в Центр сертификации по учетной записи введите в адресную строку: https://<ipадрес_хоста_развертывания_продукта или hostname>; 

- в появившемся окне «Запрос идентификации пользователя» выберите установленный сертификат учетной записи;

- в случае успешной установки сертификата откроется страница с предупреждением системы безопасности. Нажмите кнопку <Advanced>; 

- по нажатию кнопки <Advanced> на странице предупреждения системы безопасности осуществляется переход на страницу ошибки распознавания сертификата. Нужно принять риски, нажав кнопку <Accept the Risk and Continue> на текущей странице; 

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

Выпуск сертификатов

Строгая аутентификация пользователей в домене производится по протоколу PKINIT (RFC 4556), механизму предварительной проверки подлинности для Kerberos, используя сертификаты X.509.

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

Выпуск сертификата контроллера домена

  • После загрузки субъектов доменной сети необходимо выпустить сертификат доступа контроллеру домена, используя автоматически подставленные данные контроллера домена, выбрав шаблон сертификата «Domain Controller», соответствующий типу контроллера домена MS AD.
  • Установка сертификата контроллера домена производится согласно выбранной доменной модели в разделе 4 настоящего документа.

Выпуск сертификата пользователя на подчинённом Центре сертификации Aladdin Enterprise
Certificate Authority

На Подчинённом Центре сертификации Aladdin Enterprise Certificate Authority выпустите сертификат
доменного пользователя на электронном носителе JaCarta PKI.

  • Выпустите сертификат для субъекта «пользователь» подключенной ресурсной системы:
    - в разделе Центра сертификации «Субъекты» выберите субъект;
    - создайте сертификат на ключевом носителе;
    - в окне создания сертификата выберите шаблон «SmartcardLogon», соответствующий типу контроллера домена MS AD;
    - в окне создания сертификата обязательно проставьте флаг в чек-боксе «Публиковать в ресурсную систему».
  • После генерации и записи сертификата на ключевом носителе извлеките электронный ключ из USB-разъема.
  • Продление срока действия сертификата возможно через выпуск нового сертификата в центре сертификации.
    Если данные владельца не изменяются, то изменениям подвергается только криптографическая составляющая электронного сертификата.

Настройка рассылки уведомлений об истечении срока действия сертификата

  • Для мониторинга сроков окончания действия сертификатов пользователей удобно использовать инструментарий Aladdin eCA CA для настройки уведомлений об истечении срока действий сертификата. Сервис автоматически определит окончания сроков действия сертификатов и оповестит вовремя владельцев сертификатов по электронной почте.
  • Должен быть отредактирован конфигурационный файл email.env, в котором редактируется список элементов данных, содержащих информацию для мониторинга, а также список соответствующих триггеров.
  • По умолчанию владелец сертификата будет уведомлён за 30, 7, 1 день до окончания срока действия сертификата.
  • Для выполнения сценария должна быть указана электронная почта в учётных доменных записях пользователей.