Генерация PEM-сертификатов

Описание

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

В данном разделе описан сценарий подготовки сертификатов в формате PEM (*.crt и *.key). Такой способ используется при ручном управлении сертификатами и не предполагает централизованного хранения контейнеров PKCS#12 в Secret Management System (SecMan).

Подготовку сертификатов в формате PEM администратор выполняет вручную с использованием внешних инструментов генерации сертификатов (например, OpenSSL). При процессе автоматизированной установки СУБД Pangolin генерация сертификатов не реализуется автоматически.

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

Для работы кластера используются сертификаты:

Назначение	Наименование сертификата	Наименование ключа
Сертификат сервера Pangolin	server.crt	server.key
Сертификат пользователя postgres	postgres.crt	postgres.key
Сертификат Pangolin Pooler	pgbouncer.crt	pgbouncer.key
Сертификат Pangolin Manager	patroni.crt	patroni.key
Сертификат подключения к etcd	patronietcd.crt	patronietcd.key

Все сертификаты должны быть подписаны доверенным удостоверяющим центром (CA).

Альтернативный способ управления сертификатами с использованием контейнеров PKCS#12 описан в разделе «Управление сертификатами Secret Management System (SecMan, PKCS#12)».

Настройка

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

Серверный сертификат необходимо создать для каждого узла кластера:

1. Сгенерируйте приватный ключ:

openssl genrsa -out server.key 2048

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

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[req_distinguished_name]

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = <hostname>
IP.1  = <IP-address>

3. Сформируйте запрос на подпись сертификата, для этого укажите в поле CN полное доменное имя узла:

openssl req -new -key server.key -out server.csr -subj "/CN=<hostname>" -config server.conf

4. Передайте файл server.csr в удостоверяющий центр для подписи.

Генерация клиентского сертификата

Клиентские сертификаты используются компонентами кластера для аутентификации при подключении.

1. Сгенерируйте ключ:

openssl genrsa -out postgres.key 2048

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

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[req_distinguished_name]

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

3. Сформируйте запрос сертификата, для этого укажите в поле CN имя компонента, для которого создается сертификат (postgres, patroni, patronietcd, pgbouncer):

Пример:

openssl req -new -key postgres.key -out postgres.csr -subj "/CN=postgres" -config client.conf

Подготовка сертификатов

После подписи сертификатов удостоверяющим центром:

1. Конвертируйте сертификаты в формат PEM (если требуется):

openssl x509 -inform DER -outform PEM -in certificate.cer -out certificate.crt

2. Разместите сертификаты и ключи в одинаковых директориях на каждом узле кластера.

3. Установите права доступа:

Тип файла	Права
приватные ключи	600
сертификаты	644

4. Установите владельцем файлов пользователя postgres.

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

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

cat root.crt intermediate.crt > rootCA.crt

2. Добавьте корневой сертификат в системное хранилище доверенных сертификатов:

sudo cp rootCA.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Управление

Если сертификат был отозван или срок его действия истек, выполните:

• выпустите новый сертификат;
• замените файлы сертификатов на узлах кластера;
• перезапустите или перечитайте конфигурацию соответствующих компонентов.

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

Диагностика

1. Проверьте корректность сертификата:

openssl x509 -in server.crt -text -noout

2. Проверьте цепочку доверия:

openssl verify -CAfile rootCA.crt server.crt