База знаний » БД 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 Создаем серверные сертификаты

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

*cat > openssl.cnf*

<pre>

[ server ]

basicConstraints = CA:FALSE

extendedKeyUsage = serverAuth

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid,issuer:always

keyUsage = digitalSignature

</pre>

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

*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*

*chmod 400 myserver1.example.com.key*

*chmod 400 myserver2.example.com.key*

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

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

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

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

*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*

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

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

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

*cat >> openssl.cnf*

<pre>

[ client ]

basicConstraints = CA:FALSE

extendedKeyUsage = clientAuth

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid,issuer:always

keyUsage = digitalSignature

</pre>

+Генерируем запросы на клиентские сертификаты:+

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

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

*chmod 400 ivanov_ii.key*

*chmod 400 petrov_pp.key*

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

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

*openssl x509 -req -days 3650 -in ivanov_ii.csr -CA client-ca.crt -CAkey client-ca.key -CAserial client-ca.srl -CAcreateserial -out ivanov_ii.crt -extfile openssl.cnf -extensions client -sha256*

*openssl x509 -req -days 3650 -in petrov_pp.csr -CA client-ca.crt -CAkey client-ca.key -CAserial client-ca.srl -out petrov_pp.crt -extfile openssl.cnf -extensions client -sha256*

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