Использование сертификатов PKCS#12 в кластере Pangolin

Описание

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

СУБД Pangolin поддерживает использование TLS-сертификатов в формате контейнеров PKCS#12.

Контейнер PKCS#12 – это стандартный криптографический формат (файл с расширением .p12 или .pfx), предназначенный для хранения в одном зашифрованном файле сертификата, соответствующего ему закрытого ключа и цепочки доверенных сертификатов (включая корневой). Доступ к содержимому контейнера защищается парольной фразой.

Внимание!

При использовании оригинальной библиотеки libpq поддержка контейнеров PKCS#12 может быть недоступна, так как корректная работа сторонних реализаций libpq не гарантируется.

В СУБД Pangolin контейнеры PKCS#12 используются как единый формат хранения ключевой информации для TLS/SSL-подключений компонентов кластера. Сертификаты в формате PKCS#12 могут использовать следующие компоненты кластера Pangolin: СУБД Pangolin, Pangolin Pooler и Pangolin Manager.

Контейнеры PKCS#12 могут использоваться двумя способами:

• при локальном хранении в файловой системе узла;
• при централизованном хранении в Secret Management System (SecMan).

При локальном хранении контейнер PKCS#12 размещается в файловой системе узла и используется компонентами кластера через конфигурационный файл *.p12.cfg.

При использовании Secret Management System (SecMan) сертификаты, закрытые ключи и цепочка доверенных сертификатов размещаются в централизованном хранилище секретов. Компоненты кластера получают контейнеры PKCS#12 через интеграционные плагины в соответствии с параметрами, заданными в конфигурационных файлах.

Использование PKCS#12 упрощает эксплуатацию защищенных соединений по сравнению со сценарием использования PEM-файлов (раздел «Генерация PEM-сертификатов»). Вместо раздельного управления файлами *.crt/*.key администратор использует контейнер PKCS#12 и конфигурационный файл *.p12.cfg.

Для централизованного хранения сертификатов и автоматической ротации в кластерной конфигурации может использоваться агент pangolin-certs-rotate, описание которого приведено в разделе «Настройка».

Использование контейнеров PKCS#12 обеспечивает:

• хранение сертификата, закрытого ключа и цепочки доверия в одном контейнере;
• использование единого формата хранения ключевой информации для TLS/SSL-подключений;
• возможность локального хранения контейнеров PKCS#12 в файловой системе узла;
• возможность централизованного хранения и автоматической ротации сертификатов через Secret Management System (SecMan).

примечание

Некоторые сертификаты компонентов инфраструктуры могут продолжать использоваться в PEM-формате. В частности, сертификаты компонентов etcd и соответствующие им ключи (etcd.crt, etcd.key, patronietcd.crt, patronietcd.key) не переводятся в контейнеры PKCS#12, поскольку данный компонент не относится к разрабатываемым компонентам СУБД Pangolin.

Также в PEM-формате может храниться корневой сертификат удостоверяющего центра (root.crt), используемый для проверки цепочки доверия.

Настройка

Для использования сертификатов PKCS#12 в СУБД Pangolin необходимо последовательно выполнить несколько шагов. В результате настройки компоненты кластера будут использовать контейнеры PKCS#12 для установления TLS/SSL-соединений.

СУБД Pangolin может быть развернут как в кластерной конфигурации (с использованием Pangolin Manager), так и в standalone-конфигурации.

Порядок и состав шагов настройки зависят от выбранного способа хранения контейнеров PKCS#12 и режима развертывания.

Настройка выполняется в следующей последовательности:

1. Подготовьте конфигурационные файлы сертификатов *.p12.cfg (раздел «Подготовка конфигурационных файлов сертификатов»).
2. Настройте компоненты кластера СУБД Pangolin на использование этих файлов и укажите пути pkcs12_config_path в их конфигурациях (раздел «Настройка компонентов кластера»).
3. При использовании Secret Management System (SecMan) настройте получение сертификатов из SecMan. В кластерной конфигурации также настройте агент ротации сертификатов pangolin-certs-rotate (раздел «Управление»).

Подготовка конфигурационных файлов сертификатов

Каждый контейнер PKCS#12, используемый компонентами кластера, описывается отдельным конфигурационным файлом в формате JSON (*.p12.cfg).

В зависимости от выбранного сценария конфигурационный файл может:

• описывать параметры получения контейнера PKCS#12 из Secret Management System (SecMan);
• содержать путь к локальному контейнеру PKCS#12 в файловой системе;
• содержать одновременно путь к локальному контейнеру и параметры доступа к SecMan для последующей ротации сертификата.

Общий формат конфигурационного файла с описанием параметров сертификата:

{
  "pkcs12": {
    "name": "",                // Имя роли в SecMan
    "common_name": "",         // Значение поля CN сертификата
    "email": "",               // Адрес электронной почты владельца сертификата
    "alt_names": "",           // Список DNS-имен через запятую
    "ip_sans": "",             // Список IP-адресов через запятую
    "other_sans": "",          // SAN с OID/UTF8 в формате, поддерживаемом SecMan
    "exclude_cn_from_sans": "" // Управляет включением CN в SAN
  }
}

Примеры конфигурационных файлов для стандартных компонентов и ролей SecMan:

Компонент СУБД Pangolin (серверный сертификат):

{
  "pkcs12": {
    "name": "server",
    "common_name": "server",
    "email": "dba@example.org",
    "alt_names": "",
    "ip_sans": "",
    "other_sans": "",
    "exclude_cn_from_sans": ""
  }
}

Компонент Pangolin Pooler (клиентский сертификат пользователя pgbouncer):

{
  "pkcs12": {
    "name": "pgbouncer",
    "common_name": "pgbouncer",
    "email": "dba@example.org",
    "alt_names": "",
    "ip_sans": "",
    "other_sans": "",
    "exclude_cn_from_sans": ""
  }
}

Для TLS-подключений клиентов Pangolin Pooler использует тот же серверный сертификат, что и СУБД Pangolin (роль server).

Компонент Pangolin Manager (клиентский сертификат пользователя patroni):

{
  "pkcs12": {
    "name": "patroni",
    "common_name": "patroni",
    "email": "dba@example.org",
    "alt_names": "",
    "ip_sans": "",
    "other_sans": "",
    "exclude_cn_from_sans": ""
  }
}

Конфигурационные файлы для локальных контейнеров

Если кластер использует локальный контейнер PKCS#12, путь до контейнера указывается в том же конфигурационном файле *.p12.cfg, который описывает параметры соответствующего сертификата.

В этом случае в блоке pkcs12 указывают путь к локальному контейнеру PKCS#12, а параметры доступа к SecMan для последующей ротации сертификата добавляют в отдельный блок secman.

Пример конфигурационного файла для серверного сертификата СУБД Pangolin (роль server) при использовании локального контейнера:

{
  "pkcs12": {
    "pkcs12": "/home/postgres/ssl/server.p12"
  },
  "secman": {
    "name": "server",
    "common_name": "server",
    "email": "dba@example.org",
    "alt_names": "",
    "ip_sans": "",
    "other_sans": "",
    "exclude_cn_from_sans": ""
  }
}

Блок secman используется для того, чтобы агент ротации pangolin-certs-rotate мог получить новый сертификат из SecMan и обновить локальный контейнер PKCS#12.

Настройка компонентов кластера

Для всех компонентов кластера Pangolin (СУБД Pangolin, Pangolin Manager и Pangolin Pooler) изменение значений параметров, указывающих пути к конфигурационным файлам сертификатов PKCS#12, не требует полного перезапуска кластера. Для применения изменений достаточно выполнить перечитывание конфигурации соответствующих компонентов.

Pangolin Manager

В конфигурационном файле postgres.yml путь к конфигурационным файлам сертификатов задается в параметре pkcs12_config_path в соответствующих секциях:

restapi:
  pkcs12_config_path: "/home/postgres/ssl/restapi.p12.cfg"

postgresql:
  authentication:
    replication:
      pkcs12_config_path: "/home/postgres/ssl/patroni.p12.cfg"
    superuser:
      pkcs12_config_path: "/home/postgres/ssl/patroni.p12.cfg"
    rewind:
      pkcs12_config_path: "/home/postgres/ssl/patroni.p12.cfg"

  parameters:
    serverssl.pkcs12_config_path: "/home/postgres/ssl/server.p12.cfg"

Параметр serverssl.pkcs12_config_path задает путь к конфигурационному файлу, который описывает серверный сертификат для TLS-подключений к СУБД.

СУБД Pangolin (standalone-конфигурация)

Данный вариант используется, если СУБД Pangolin развернут без Pangolin Manager и без Patroni. В этом режиме серверный сертификат для TLS-подключений к СУБД Pangolin настраивается напрямую в конфигурационном файле postgresql.conf.

В конфигурационном файле postgresql.conf (standalone-конфигурация) указывают путь к файлу с описанием серверного сертификата:

serverssl.pkcs12_config_path = '/home/postgres/ssl/server.p12.cfg'

В standalone-конфигурации агент pangolin-certs-rotate не используется. Обновление и замена сертификатов в этом режиме выполняются администратором вручную либо внешними средствами автоматизации.

Внимание!

При включенной защите параметров конфигурации (secure_config = on) параметр serverssl.pkcs12_config_path должен быть под защитой и управляться через хранилище секретов.

Pangolin Pooler

В конфигурационном файле pangolin-pooler.ini задаются пути к конфигурационным файлам для клиентского и серверного сертификатов:

client_tls_pkcs12_config_path = /home/postgres/ssl/pgbouncer.p12.cfg
server_tls_pkcs12_config_path = /home/postgres/ssl/server.p12.cfg

Агент pangolin-certs-rotate

Описание

При использовании Secret Management System (SecMan) в кластерной конфигурации для контроля срока действия и автоматической ротации сертификатов используется агент pangolin-certs-rotate.

Агент ротации сертификатов представляет собой исполняемый файл pangolin-certs-rotate, который взаимодействует с системой хранения сертификатов через систему плагинов и конфигурационный файл агента.

Цель агента – обеспечить непрерывную и безопасную работу TLS-соединений компонентов кластера за счет автоматического контроля и обновления сертификатов.

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

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

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

Для взаимодействия с Secret Management System применяется плагин remote_secman_pki_plugin, который использует протокол http/https и параметры подключения кластера. Параметры подключения хранятся в засекреченном файле /etc/pangolin-security-utilities/enc_connection_settings_cert.cfg. Для рассекречивания файла агент использует плагин кодирования.

На схеме приведены этапы работы агента:

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

Установка

Автоматизированная установка

При автоматизированной установке СУБД Pangolin при помощи Ansible-скриптов параметры агента ротации сертификатов задаются в пользовательском конфигурационном файле custom_file_template.yml в словаре pangolin-certs-rotate.

На схеме показан общий порядок включения агента ротации сертификатов при установке:

Основные параметры агента:

• enable – включает или отключает запуск агента ротации сертификатов;
• agent_config – путь к конфигурационному файлу агента (по умолчанию /etc/pangolin-certs-rotate/pangolin-certs-rotate.yml);
• log_directory – директория для лог-файлов агента (по умолчанию /var/log/pangolin-certs-rotate);
• log_filename – имя лог-файла;
• log_level – уровень логирования (debug / info / warning / error / fatal);
• log_destination – способы записи логов (console, file).

Параметры контроля сертификатов задаются в словаре certs:

• enable_update – включает или отключает автоматическую ротацию сертификатов;
• poll_period_in_min – период проверки сертификатов в минутах;
• retry_interval_in_sec – интервал ожидания перед повторной попыткой при ошибке;
• retry_attempts_num – количество повторных попыток при ошибке.

Контролируемые сертификаты задаются в списке watch, где для каждой группы указываются:

• paths – список конфигурационных файлов сертификатов *.p12.cfg;
• on_update – команды, выполняемые после обновления сертификата.

Пример конфигурации агента в custom_file_template.yml:

pangolin-certs-rotate:
  enable: true
  agent_config: "/etc/pangolin-certs-rotate/pangolin-certs-rotate.yml"
  log_directory: "/var/log/pangolin-certs-rotate"
  log_filename: "pangolin-certs-rotate"
  log_level: "info"
  log_destination: "console"

  certs:
    enable_update: true
    poll_period_in_min: 60
    retry_interval_in_sec: 30
    retry_attempts_num: 1

    watch:
      - locations:
          paths:
            - "/home/postgres/ssl/server.p12.cfg"
            - "/home/postgres/ssl/patroni.p12.cfg"
          on_update:
            - "sudo systemctl reload pangolin-manager"

      - locations:
          paths:
            - "/home/postgres/ssl/server.p12.cfg"
            - "/home/postgres/ssl/pgbouncer.p12.cfg"
          on_update:
            - "sudo systemctl reload pangolin-pooler"

Ручная установка

При ручной установке:

1. Установите пакет pangolin-certs-rotate средствами пакетного менеджера операционной системы.

SberLinux, РЕД ОС, CentOS

sudo dnf install pangolin-certs-rotate-{version_component}-{OS}.x86_64.rpm

Astra Linux

sudo apt install pangolin-certs-rotate-{version_component}_amd64.deb

Альт СП

sudo apt-get install pangolin-certs-rotate-{version_component}-{OS}.x86_64.rpm

2. Создайте конфигурационный файл:

/etc/pangolin-certs-rotate/pangolin-certs-rotate.yml

3. Настройте службу pangolin-certs-rotate.service, указав путь к конфигурационному файлу:

ExecStart=/opt/pangolin-common/bin/pangolin-certs-rotate --config=/etc/pangolin-certs-rotate/pangolin-certs-rotate.yml

4. Запустите службу:

sudo systemctl enable pangolin-certs-rotate.service
sudo systemctl start pangolin-certs-rotate.service

Настройка

Параметры работы агента задаются в конфигурационном файле:

/etc/pangolin-certs-rotate/pangolin-certs-rotate.yml

На схеме показан общий порядок изменения параметров работающего агента:

Основные параметры:

log:
  directory: "/var/log/pangolin-certs-rotate"
  filename: "pangolin-certs-rotate"
  level: "info"
  destination: "console,file"

certs:
  enable_update: true
  poll_period_in_min: 1440
  retry_interval_in_sec: 60
  retry_attempts_num: 1

  watch:
    - locations:
        paths:
          - "/home/postgres/ssl/server.p12.cfg"
          - "/home/postgres/ssl/patroni.p12.cfg"
        on_update:
          - "sudo systemctl reload pangolin-manager"

Список сертификатов для контроля задается через watch.locations.paths. Для каждой группы сертификатов указывается команда on_update, выполняемая после их обновления.

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

sudo systemctl restart pangolin-certs-rotate.service

Использование цепочки доверенных сертификатов

По умолчанию для проверки сертификатов используется полная цепочка сертификатов, содержащаяся в контейнере PKCS#12.

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

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

• в конфигурационном файле postgresql.conf:

  • ssl_ca_file
  • ssl_ca_path

• в конфигурационном файле postgres.yml (Pangolin Manager):

  • cafile
  • capath
  • sslrootcert
  • sslrootpath

• в конфигурационном файле pangolin-pooler.ini:

  • client_tls_ca_file
  • server_tls_ca_file
  • client_tls_ca_path
  • server_tls_ca_path

Если данные параметры не указаны, поиск доверенных сертификатов выполняется в следующем порядке:

1. в цепочке сертификатов контейнера PKCS#12;
2. в указанных файлах или директориях с доверенными сертификатами;
3. в системных хранилищах доверенных сертификатов операционной системы.

Управление

Контейнеры PKCS#12 могут храниться как локально в файловой системе узла, так и централизованно в Secret Management System (SecMan).

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

При использовании Secret Management System (SecMan) сертификаты, закрытые ключи и цепочка доверия хранятся в хранилище секретов, а компоненты кластера получают контейнеры PKCS#12 через интеграционные плагины. В кластерной конфигурации автоматическое обновление сертификатов выполняется агентом ротации pangolin-certs-rotate.

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

Управление агентом ротации сертификатов

Основные операции управления выполняются через systemd:

sudo systemctl status pangolin-certs-rotate.service
sudo systemctl restart pangolin-certs-rotate.service
sudo systemctl reload pangolin-certs-rotate.service

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

certs:
  enable_update: false

Процесс обновления сертификатов в SecMan и на узлах кластера

При подключении к SecMan агент запрашивает каждый контролируемый сертификат отдельно с использованием метода read.

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

Если интервал между датой выпуска и датой истечения сертификата достигает 80 % срока его действия (или если сертификат попадает в список отозванных), агент инициирует его перевыпуск через метод generate.

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

Процесс обновления сертификатов на узлах кластера выполняется через команды перечитывания конфигурации компонентов, например:

sudo systemctl reload postgresql
sudo systemctl reload pangolin-manager
sudo systemctl reload pangolin-pooler

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

Автоматизированное обновление локальных сертификатов PKCS12 при помощи агента ротации сертификатов

Чтобы агент ротации мог обновлять сертификаты, которые хранятся локально (в файлах с расширением p12) необходимо в файле p12.cfg добавить секцию secman (чтобы агент ротации мог подключиться к хранилищу секретов и получить оттуда по заданным параметрам сертификат). Набор полей в данной секции определяется хранилищем секретов, поэтому, если некоторые поля не нужны, в качестве значения для них можно указать пустую строку, но они обязательно должны присутствовать в конфигурационном файле. В противном случае при загрузке конфигурации p12 будет ошибка указывающая на отсутствие данного поля. Пример конфигурационного файла p12.cfg для локально хранимого контейнера p12 и автоматического перевыпуска агентом ротации:

{
  "passphrase" : "<passphrase>",
  "pkcs12" : "/certs/server.p12",
  "secman" : {
    "alt_names" : "",
    "common_name" : "<server_name>",
    "email" : "test@test.ru",
    "exclude_cn_from_sans" : false,
    "ip_sans" : "<IP-address>",
    "name" : "<server_name>",
    "other_sans" : ""
  }
}

При первом запуске, при перезапуске, а также при проверке сертификатов по расписанию сервис ротации, как и в случае с хранением сертификатов в SecMan проверяет наличие дампа серийных номеров (/var/run/pangolin-certs-rotate/pangolin-certs-rotate.dump). В случае, если серийный номер сертификата в SecMan изменился, либо если по каким-то причинам отсутствует дамп (например, первый запуск агента ротации или неправильно сконфигурированные права на директорию с дампом) сертификат будет скачан с хранилища секретов и обновлен на диске, пароль контейнера PKCS12 будет зашифрован утилитой pg_auth_password и обновлен в конфигурационном файле p12.cfg. Тем не менее, если сертификат не отозван и не просрочен, перевыпускаться он не будет, будет лишь повторно скачан контейнер PKCS12 из хранилища сертификатов и повторно зашифрован пароль.

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

Поле passphrase в конфигурационном файле p12.cfg при обновлении сертификатов на диске всегда рассчитывается заново и обновляется в конфигурационном файле. Оно появится там даже в том случае, если изначально его не было и для ввода парольной фразы использовалась переменная окружения или параметр в строке подключения (для клиентских сертфикатов).

Утилита не следит за состоянием контейнера на диске, она ориентируется на хранилище секретов. Таким образом, если файл дампа /var/run/pangolin-certs-rotate/pangolin-certs-rotate.dump содержит для данного сертификата отличающийся от хранящегося в хранилище сертификатов серийный номер, либо не содержит его вовсе (например данный файл отсутствует или к нему нет доступа) – контейнер p12 будет обновлен, но если в дампе есть серийный номер и он совпадает с тем, что хранится в хранилище сертификатов – файл не проверяется и не обновляется, даже если файл контейнера p12 поврежден или удален.

Диагностика

Для диагностики работы механизма использования сертификатов PKCS#12 используются системные журналы и состояние службы агента ротации сертификатов pangolin-certs-rotate (если используется сценарий с SecMan).

Проверка состояния агента ротации сертификатов

Проверьте состояние службы:

sudo systemctl status pangolin-certs-rotate.service

Если служба запущена корректно, в выводе команды будет указано состояние active (running).

Просмотр журналов работы агента

Для анализа работы агента используйте системный журнал:

sudo journalctl -u pangolin-certs-rotate.service

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

/var/log/pangolin-certs-rotate

Проверка конфигурации сертификатов

При возникновении ошибок получения или обновления сертификатов рекомендуется проверить:

• корректность конфигурационных файлов *.p12.cfg;
• доступность Secret Management System (SecMan);
• корректность параметров подключения к SecMan в файле /etc/pangolin-security-utilities/enc_connection_settings_cert.cfg;
• наличие прав на выполнение команд, указанных в параметре on_update.

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

Проверка контейнеров PKCS#12 (pkcs12_cert_info)

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

Утилита pkcs12_cert_info принимает следующие аргументы командной строки:

• --pkcs12_config_path или -p: путь к конфигурационному файлу со стратегией получения контейнера PKCS#12 и парольной фразы;
• --verify или -v: включает проверку подписи сертификата контейнера;
• --CAfile или -f: путь к файлу корневого или промежуточного сертификата;
• --CApath или -d: путь к директории с корневыми или промежуточными сертификатами;
• --no-CApath или -n: отключает поиск корневых сертификатов в системных директориях;
• --help или -h: вывод справки и завершение работы.

Сведения

Утилитаpkcs12_cert_info доступна только для редакций Enterprise и Enterprise для ERP-систем.

Вывод команды pkcs12_cert_info --help

pkcs12_cert_info -h
Usage:
pkcs12_cert_info <option>...

Options:
--help                   [-h]     This help
--pkcs12_config_path     [-p]     Path to config file with info how to get PKCS#12 file
--verify                 [-v]     Check that PKCS#12 certificate trusted by anchor
--CAfile                 [-f]     Path to root/intermediate certificate file
--CApath                 [-d]     Path to root/intermediate certificate directory
--no-CApath              [-n]     Do not use the default directory of trusted certificates.

Pangolin product version information:
--product_version        prints product name and version
--product_build_info     prints product build number, date and hash
--product_component_hash prints component hash string

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

Пример запуска утилиты:

pkcs12_cert_info -p /pg_ssl/server.p12.cfg

Пример вывода утилиты:

Certificate:
Issuer: CN=Pangolin_intermediate_CA
Validity
Not Before: Nov  8 10:52:13 2022 GMT
Not After : Nov  5 10:52:13 2032 GMT
Subject: CN=srv-0-154

Private key exists

Certificate chain:
Certificate #1:
Issuer: CN=Pangolin_CA
Validity
Not Before: Nov  8 10:52:13 2022 GMT
Not After : Nov  5 10:52:13 2032 GMT
Subject: CN=Pangolin_intermediate_CA
Certificate #2:
Issuer: CN=Pangolin_CA
Validity
Not Before: Nov  8 10:52:12 2022 GMT
Not After : Nov  5 10:52:12 2032 GMT
Subject: CN=Pangolin_CA

Ошибка загрузки плагина для обработки PKCS#12-файла

В случае ошибки загрузки плагина, возникает следующее сообщение:

Could not load plugin to get PKCS#12 file specified in file "<file_path>"
Error: -18 (shared library is not loaded)

Установите переменную окружения PG_PLUGINS_PATH для загрузки библиотек поддержки PKCS#12:

export PG_PLUGINS_PATH=/usr/pangolin-7.3/lib

Использование

После настройки компонентов кластера СУБД Pangolin контейнеры PKCS#12 используются для установления TLS/SSL-соединений.

При локальном хранении контейнеры PKCS#12 читаются компонентами кластера напрямую из файловой системы на основании параметров, заданных в конфигурационных файлах *.p12.cfg.

При использовании Secret Management System (SecMan) контейнеры PKCS#12 хранятся в SecMan и передаются компонентам кластера через интеграционные плагины. В кластерной конфигурации агент ротации pangolin-certs-rotate периодически проверяет срок действия сертификатов и при необходимости инициирует их перевыпуск и применение на узлах кластера.

Использование контейнеров PKCS#12 позволяет применять единый формат хранения сертификатов и закрытых ключей как при локальном хранении, так и при централизованном управлении сертификатами через Secret Management System (SecMan).

Использование PKCS#12 при подключении через psql

Если для подключения к СУБД СУБД Pangolin используется клиентский сертификат, размещенный в контейнере PKCS#12, в строке подключения psql необходимо указать параметр pkcs12_config_path, содержащий путь к конфигурационному файлу .p12.cfg.

Пример подключения:

psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"

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

PKCS12_CONFIG_PATH=/pg_ssl/client.p12.cfg \
psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full"

Если парольная фраза не указана в файле .p12.cfg, ее можно передать через параметр подключения pkcs12_passphrase или через переменную окружения PKCS12_PASSPHRASE.