Перейти к основному содержимому

Использование сертификатов 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

Получение сертификатов из Secret Management System (SecMan)​

СУБД Pangolin использует общий механизм взаимодействия с Secret Management System (SecMan) для получения сертификатов и секретов. В рамках настоящего раздела рассматривается его применение при получении сертификатов, используемых для TLS/SSL-соединений.

Для каждого извлекаемого из SecMan артефакта СУБД Pangolin формирует отдельный запрос. Отдельный запрос выполняется для каждого сертификата или параметра.

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

  • /etc/pangolin-security-utilities/enc_connection_settings.cfg – для получения секретов;
  • /etc/pangolin-security-utilities/enc_connection_settings_cert.cfg – для получения сертификатов.

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

  • vault_connection_timeout — максимально допустимое время для фазы подключения к хранилищу, задается в мс. Значение по умолчанию — 1000, допустимый интервал — [1 : 10000];
  • vault_timeout — максимально допустимое время для одного запроса к хранилищу, включая период установки сетевого соединения (vault_connection_timeout), задается в мс. Значение по умолчанию — 3000, допустимый интервал — [1 : 1000000].

Значение 0 для параметра vault_timeout не допускается, чтобы исключить отключение таймаута и возможное зависание запроса.

Изменение значений параметров vault_connection_timeout и vault_timeout требует перезапуска сервера.

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

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

Для определения доступного SecMan при отсутствии ранее установленного актуального соединения СУБД Pangolin последовательно перебирает известные SecMan. Для каждого из них выполняются вспомогательные запросы:

  • запрос проверки доступности SecMan;
  • запрос получения токена аутентификации и установки сетевого соединения с SecMan.

Таймауты vault_connection_timeout и vault_timeout применяются к каждому запросу отдельно, независимо от продолжительности и результатов предыдущих запросов.

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

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

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

  • enable_vault_params_cache – для секретов;
  • enable_vault_certificates_cache – для сертификатов.

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

  • при запуске СУБД — к невозможности завершить запуск;
  • при перечитывании конфигурации — к отсутствию обновления сертификатов при продолжении работы с ранее полученными данными.
Внимание!

При обращении к недоступному SecMan процессы postmaster и authproc могут не обрабатывать запросы на новые подключения к СУБД Pangolin до переключения на локальный кеш. При этом уже существующие пользовательские и системные процессы продолжают работу без влияния.

Значения параметров vault_connection_timeout и vault_timeout следует выбирать с учетом требований SLA бизнес-приложений.

Агент 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 – количество повторных попыток при ошибке;
  • vault_connection_timeout – максимальное время в миллисекундах, отведенное на этап подключения к хранилищу сертификатов. Значение по умолчанию — 10000, допустимый интервал — [1 : 10000];
  • vault_timeout – максимальное время в миллисекундах, отведенное на один запрос к ханилищу сертификатов (включая vault_connection_timeout). Значение по умолчанию — 10000, допустимый интервал — [1 : 1000000].

Контролируемые сертификаты задаются в списке 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
    vault_connection_timeout: 10000
    vault_timeout: 10000

    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 средствами пакетного менеджера операционной системы.
sudo dnf install pangolin-certs-rotate-{version_component}-{OS}.x86_64.rpm
  1. Создайте конфигурационный файл:
/etc/pangolin-certs-rotate/pangolin-certs-rotate.yml
  1. Настройте службу pangolin-certs-rotate.service, указав путь к конфигурационному файлу:
ExecStart=/opt/pangolin-common/bin/pangolin-certs-rotate --config=/etc/pangolin-certs-rotate/pangolin-certs-rotate.yml
  1. Запустите службу:
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
  vault_connection_timeout: 10000
  vault_timeout: 10000

  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.

Особенности выбора доступного Secret Management System (SecMan), применения таймаутов запросов и использования локального кеша описаны в разделе «Получение сертификатов из Secret Management System (SecMan)».

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

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

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

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

Сам пароль агенту ротации отдает хранилище сертификатов вместе с контейнером 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;
  • значения параметров vault_connection_timeout и vault_timeout;
  • состояние параметра enable_vault_certificates_cache;
  • наличие прав на выполнение команд, указанных в параметре 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-6.7/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.