Перейти к содержимому
Аладдин Р.Д.Аладдин Р.Д.Аладдин Р.Д.

6.4.2. eCA-RA

Aladdin Enterprise CAИнтеграцииAladdin Enterprise CA

Для настройки TLS-соединения Центра регистрации Aladdin Enterprise Registration Authority c СУБД необходимо в предварительно развёрнутом и инициализированном eCA-CA создать сертификат с закрытым ключом (PKCS#12) для сервера СУБД. При этом в сертификате сервера СУБД в атрибуте Common Name или в атрибуте Subject Alternative Name типа dNSName обязательно должно быть указано доменное сервера СУБД (или IP-адрес)[1], так как eCA-RA аутентифицирует сервер СУБД в режиме “verify-full”, который предполагает проверку соответствия имени узла сервера имени, записанному в сертификате. Для создания сертификата может быть использован шаблон “WEB-Server” (необходимо предварительно создать локальный субъект в eCA-CA, указав ему необходимые атрибуты CN и DNS Name).

Во избежание ошибок в работе eCA-RA перед началом настройки TLS-соединения с СУБД рекомендуется остановить работу eCA-RA путём выполнения с правами суперпользователя команды systemctl stop aeca-ra.service.

Для настройки TLS-соединения eCA-RA c СУБД необходимо:

  • выполнить настройку СУБД в соответствии с разделом Настройка на хосте СУБД настоящего приложения, представленным ниже;

  • выполнить настройку eCA-RA в соответствии с разделом Настройка на хосте eCA-RA настоящего приложения, представленным ниже.

Настройка на хосте СУБД

Заголовок раздела «Настройка на хосте СУБД»

На хосте с установленной и настроенной СУБД отредактировать файл /var/lib/pgsql/15/data/postgresql.conf (или var/lib/jatoba/4/data/postgresql.conf, если используется СУБД Jatoba)[2], указав:

  • в параметре ssl значение on;

  • в параметре ssl_cert_file абсолютный путь к файлу сертификата сервера СУБД[3];

  • в параметре ssl_key_file абсолютный путь к файлу закрытого ключа сервера СУБД[4];

  • в параметре ssl_ca_file абсолютный путь к файлу цепочки сертификатов издателя сертификата СУБД [5].

При этом указанные выше файлы должны иметь метку доступа “600”, установить которую можно с помощью команды с правами суперпользователя chmod 600 путь_к_файлу для каждого файла.

Владельцем всех указанных выше файлов необходимо назначить пользователя “postgres”, выполнив команду с правами суперпользователя chown postgres:postgres путь_к_файлу для всех перечисленных файлов.

Указанные файлы должны располагаться в каталоге, к которому имеет доступ пользователь postgres (например, /tmp). В случае использования ОС РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server на хосте СУБД указанные выше файлы должны располагаться в каталоге /var/lib/pgsql (или /var/lib/jatoba, если используется СУБД Jatoba). При этом указанные выше файлы должны быть скопированы в нужный каталог, а не перемещены.

Пример значений отредактированных параметров конфигурационного файла СУБД postgresql.conf:

## - SSL -


ssl = on


ssl_cert_file = '/tmp/cert.pem'


ssl_key_file` = '/tmp/key.key'


ssl_ca_file` = '/tmp/chain.pem'

На хосте СУБД перезапустить СУБД выполнив с правами суперпользователя команду systemctl restart postgresql (или systemctl restart jatoba-4 если используется СУБД Jatoba).

Настройка на хосте eCA-RA

Заголовок раздела «Настройка на хосте eCA-RA»

На хосте eCA-RA отредактировать конфигурационный файл /opt/aecaRа/scripts/config.sh, указав в нём в параметре конфигурации БД use_tls значение true, а в параметре root_cert_path абсолютный путь к файлу сертификата корневого издателя из цепочки сертификатов сервера СУБД[6].

При этом указанный выше файл сертификата корневого издателя из цепочки сертификатов сервера СУБД должен иметь метку доступа “600”, установить которую можно с помощью команды с правами суперпользователя chmod 600 путь_к_файлу.

Владельцем файла сертификата корневого издателя из цепочки сертификатов сервера СУБД необходимо назначить пользователя “aeca”, выполнив с правами суперпользователя команду chown aeca:aeca путь_к_файлу.

Указанный файл должен располагаться в каталоге, к которому имеет доступ пользователь aeca (например, /tmp). В случае использования РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server на хосте eCA-RA файл сертификата корневого издателя из цепочки сертификатов сервера СУБД должен располагаться в каталоге /opt/aecaRа (или в его подкаталогах).

Кроме того, в случае использования РЕД ОС, РОСА “ХРОМ” 12 Сервер и SberLinux OS Server на хосте eCA-RA необходимо дополнительно выполнить команду restorecon -Rv "путь к файлу сертификата корневого издателя из цепочки сертификатов сервера СУБД".

На хосте eCA-RA применить изменения конфигурационного файла:

  1. Запустите скрипт install.sh с параметрами согласно таблице или введите параметры в диалоге при необходимости.

    Пример запуска скрипта без параметров:

    Окно терминала
    sudo bash /opt/aecaRa/scripts/install.sh

  2. Выберите действие “[Update]”.

По завершению выполнения указанной команды дальнейший обмен данными eCA-RA c СУБД будет осуществляться только по протоколу TLS. Если в СУБД, к которой выполняется подключение, отключён TLS, то eCA-RA не будет выполнять обмен данными с такой СУБД. При этом eCA-RA сможет установить соединение с СУБД только в случае, если её сертификат издан издателем, путь к сертификату которого указан в конфигурационном файле eCA-RA и только в случае, если имя хоста сервера СУБД соответствует указанному в сертификате.

[1]. Указанное в сертификате доменное сервера СУБД (или IP-адрес) должно соответствовать значению параметра “database_host” конфигурационного файла eCA-RA. ↑

[2]. Путь к файлу может отличаться в зависимости от версии PostgreSQL или Jatoba. ↑

[3]. Файл сертификата сервера СУБД может быть скачан из пользовательского интерфейса eCA-CA. Например, в карточке локального субъекта сервера СУБД. ↑

[4]. Файл закрытого ключа сервера СУБД может быть получен из контейнера закрытого ключа сервера СУБД путём выполнения команды openssl pkcs12 -in container.p12 -out key.key -nocerts -nodes, где container.p12 - путь к контейнеру закрытого ключа сервера СУБД, а “key.key” - путь к файлу для сохранения закрытого ключа. ↑

[5]. Файл цепочки сертификатов издателя сертификата СУБД может быть скачан в карточке ЦС, выпустившего сертификат сервера СУБД. ↑

[6]. Если сертификат сервера СУБД выпущен подчинённым ЦС, необходимо указать путь до сертификата корневого ЦС. ↑