База знаний » БД PostgreSQL

h1. Подключение к postgres с обязательным использованием SSL и клиентского сертификата

h1. Дано

Cервера postgresql с адресами:

* *myserver1.example.com*

* *myserver2.example.com*

h1. Задача

Предоставить клиентам доступ к серверам через публичную сеть (Интернет).

- Включить шифрование канала между клиентом и сервером

- Требовать от клиента клиентский сертификат

- Требовать от клиента пароль

- Проверять, что сервер действительно то, за кого он себя выдает

h1. Решение

Данное решение реализовывалось на серверах postgresql-9.2+ и было актуально на 2016 год.

h2. 1. Генерация сертификатов

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

Я рассмотрю вариант, когда CA отличаются

h3. 1.1. Генерация сертификатов серверов

Одним из вариантов решения могла бы быть покупка серверного сертификата

Но здесь это нецелесообразно, потому что клиенты не всегда используют системные ca-bundle, и раз уж нам все равно нужно передавать пользователям клиентские сертификаты, то передадим и CA сервера.

h4. 1.1.1. CA сертификат для подписания серверных сертификатов

Не буду вдаваться в подробности создания CA

*openssl genrsa -out server-ca.key -camellia256 2048*

*chmod 400 server-ca.key*

*openssl req -new -x509 -days 3650 -key server-ca.key -out server-ca.crt -subj '/C=RU/O=EKB-Info/CN=server-CA' -extensions v3_ca -sha256*

ШИфр для ключа *-camellia256* - дело вкуса.

Можно выбрать и что-то другое из:

 * -aes128

 * -aes192

 * -aes256

 * -camellia128

 * -camellia192

 * -camellia256

 * -des

 * -des3

 * -idea

Тип ЭЦП для сертификата *-sha256* - тоже дело вкуса.

По большому счету здесь можно использовать другой тип ЭЦП, т.к. на корневом сертификате ЭЦП не проверяется.

Значение параметра *-subj* нужно поправить под себя.

h4. 1.1.2 Создаем серверные сертификаты

h5. Создаем файл настроек для генерации серверного сертификата:

*cat > openssl.cnf*

<pre>

[ server ]

basicConstraints = CA:FALSE

extendedKeyUsage = serverAuth

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid,issuer:always

keyUsage = digitalSignature, keyEncipherment

</pre>

h5. Генерируем запросы на серверные сертификаты:

*openssl req -new -nodes -newkey rsa:2048 -keyout myserver1.example.com.key -out myserver1.example.com.csr -subj '/C=RU/O=EKB-Info/CN=myserver1.example.com/' -sha256*

*openssl req -new -nodes -newkey rsa:2048 -keyout myserver2.example.com.key -out myserver1.example.com.csr -subj '/C=RU/O=EKB-Info/CN=myserver2.example.com/' -sha256*

Здесь важно указать CN= в виде реального имени, по которому клиенты будут соединяться к серверу. Иначе не будет работать verify-full

https://www.postgresql.org/docs/9.5/static/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS

Тип ЭЦП *-sha256* здесь не очень важен, потому что используется только для подписи запроса, а не самого сертификата.

h5. Подписываем сертификаты:

*openssl x509 -req -days 3650 -in myserver1.example.com.csr -CA server-ca.crt -CAkey server-ca.key -CAserial server-ca.srl -CAcreateserial -out myserver1.example.com.crt -extfile openssl.cnf -extensions server -sha256*

*openssl x509 -req -days 3650 -in myserver2.example.com.csr -CA server-ca.crt -CAkey server-ca.key -CAserial server-ca.srl -out myserver1.example.com.crt -extfile openssl.cnf -extensions server -sha256*

Тип ЭЦП *-sha256* здесь важен с точки зрения надежности. В 2016 году некоторые распространенные ранее типы ЭЦП типа sha1 не считается надежными.

Параметр *-CAcreateserial* Используется только первый раз.

h4. 1.2.1 CA сертификат для подписания клиентских сертификатов

Тут все по аналогии с пунктом 1.1.1.

Приведу только команды

*openssl genrsa -out client-ca.key -camellia256 2048*

*chmod 400 client-ca.key*

*openssl req -new -x509 -days 3650 -key client-ca.key -out client-ca.crt -subj '/C=RU/O=EKB-Info/CN=client-CA' -extensions v3_ca -sha256*