При SSL наличии скомпилированной поддержки Digital Q.DataBase сервер может быть запущен с поддержкой зашифрованных соединений с использованием TLS протоколов, включаемых с помощью параметра ssl в on в postgresql.conf. Сервер будет прослушивать как обычные, так и SSL соединения на одном и том же порту TCP и будет согласовывать с подключающимся клиентом использование SSL. По умолчанию это определяется выбором клиента; см. Раздел 3.5.1 информацию о настройке сервера для обязательного использования SSL для некоторых или всех соединений.

Для запуска в SSL режиме необходимо наличие файлов сертификата сервера и закрытого ключа. По умолчанию предполагается, что эти файлы имеют имена server.crt и server.key, соответственно, в каталоге данных сервера, однако другие имена и расположения можно задать с помощью параметров конфигурации ssl_cert_file и ssl_key_file.

В Unix-системах права доступа к server.key должны запрещать любой доступ для группы или всех остальных пользователей (world); этого можно достичь с помощью команды chmod 0600 server.key. Кроме того, владельцем файла может быть пользователь root, а группе предоставлен доступ на чтение (то есть 0640 права доступа). Такая конфигурация предназначена для систем, в которых файлы сертификатов и ключей управляются операционной системой. Пользователь, от имени которого Digital Q.DataBase запускается сервер, должен быть включен в группу, имеющую доступ к этим файлам сертификатов и ключей.

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

Если закрытый ключ защищен паролем, сервер запросит пароль и не запустится до тех пор, пока он не будет введен. Использование пароля по умолчанию отключает возможность изменения настройки SSL сервера без перезапуска, однако см. ssl_passphrase_command_supports_reload. Кроме того, в ОС Windows использование закрытых ключей, защищенных парольной фразой, невозможно.

Первым сертификатом в server.crt должен быть сертификат сервера, так как он должен соответствовать закрытому ключу сервера. Сертификаты «промежуточных» удостоверяющих центров также могут быть добавлены в файл. Это позволяет избежать необходимости хранения промежуточных сертификатов на клиентах при условии, что корневой и промежуточные сертификаты были созданы с использованием v3_ca расширений. (При этом для базового ограничения сертификата CA в true.) Это упрощает процедуру обновления промежуточных сертификатов при истечении их срока действия.

Добавлять корневой сертификат в server.crt. не требуется. Вместо этого клиенты должны иметь корневой сертификат цепочки сертификатов сервера.

Digital Q.DataBase считывает общесистемный OpenSSL конфигурационный файл. По умолчанию данный файл имеет имя openssl.cnf и расположен в директории, возвращаемой командой openssl version -d. Данное значение по умолчанию можно переопределить путем установки переменной окружения OPENSSL_CONF в значение имени требуемого конфигурационного файла.

OpenSSL поддерживает широкий спектр шифров и алгоритмов аутентификации различной стойкости. Несмотря на то, что список шифров может быть определен в OpenSSL конфигурационном файле, допускается указание шифров специально для сервера баз данных путем изменения ssl_ciphers в postgresql.conf.

Чтобы потребовать от клиента предоставления доверенного сертификата, поместите сертификаты корневых центров сертификации (CAs), которым вы доверяете, в файл в каталоге данных, установите параметр ssl_ca_file в postgresql.conf равным имени нового файла и добавьте параметр аутентификации clientcert=verify-ca или clientcert=verify-full в соответствующие hostssl строки в pg_hba.conf. В этом случае при установке SSL-соединения у клиента будет запрошен сертификат. (См. Раздел 4.1.19 для получения описания того, как настроить сертификаты на стороне клиента.)

Для hostssl записи с clientcert=verify-ca, сервер будет проверять, подписан ли сертификат клиента одним из доверенных центров сертификации. Если clientcert=verify-full указано, сервер не только проверит цепочку сертификатов, но и проверит, соответствует ли имя пользователя или его сопоставление значению cn (Common Name) предоставленного сертификата. Обратите внимание, что проверка цепочки сертификатов выполняется всегда при использовании метода cert аутентификации (см. Раздел 3.5.12).

Промежуточные сертификаты, которые связываются с существующими корневыми сертификатами, также могут быть указаны в ssl_ca_file файле, если требуется избежать их хранения на клиентских сторонах (при условии, что корневой и промежуточные сертификаты были созданы с v3_ca расширениями). Записи списка отзыва сертификатов (CRL) также проверяются, если установлен параметр ssl_crl_file или ssl_crl_dir is set.

Программа clientcert параметр аутентификации доступен для всех методов аутентификации, но только в pg_hba.conf строках, указанных как hostssl. Если параметр clientcert не задан, сервер проверяет клиентский сертификат по своему файлу CA только в том случае, если клиентский сертификат представлен и CA настроен.

Существует два подхода, позволяющих обязать пользователей предоставлять сертификат при входе в систему.

Первый подход использует метод cert аутентификации для hostssl записей в pg_hba.conf, при котором сам сертификат используется для аутентификации и одновременно обеспечивает безопасность SSL-соединения. См. Раздел 3.5.12 для получения подробных сведений. (Нет необходимости явно указывать какие-либо clientcert параметры в явном виде при использовании команды cert метода аутентификации.) В данном случае значение cn (Common Name), указанное в сертификате, проверяется на соответствие имени пользователя или соответствующему правилу сопоставления.

Второй подход сочетает любой метод аутентификации для hostssl записей с проверкой клиентских сертификатов путем установки clientcert параметра аутентификации в значение verify-ca или verify-full. Первый вариант только подтверждает действительность сертификата, в то время как второй также гарантирует, что cn (Common Name) в сертификате соответствует имени пользователя или соответствующему правилу сопоставления.

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

Сервер считывает эти файлы при запуске и при каждой перезагрузке конфигурации сервера. В Windows системах они также перечитываются при создании каждого нового фонового процесса для нового клиентского соединения.

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

Для создания простого самоподписанного сертификата сервера со сроком действия 365 дней используйте следующую OpenSSL команду, заменив dbhost.yourdomain.com на имя хоста сервера:

openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"

Затем выполните команду:

chmod og-rwx server.key

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

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

Для создания сертификата сервера, подлинность которого может быть проверена клиентами, сначала создайте запрос на подпись сертификата (CSR) и файл открытого/закрытого ключей:

openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key

Затем следует подписать запрос ключом для создания корневого удостоверяющего центра (используя стандартное OpenSSL расположение конфигурационного файла в Linux):

openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

В завершение необходимо создать сертификат сервера, подписанный новым корневым центром сертификации:

openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key

openssl x509 -req -in server.csr -text -days 365 \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out server.crt

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

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

# root
openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

# intermediate
openssl req -new -nodes -text -out intermediate.csr \
  -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com"
chmod og-rwx intermediate.key
openssl x509 -req -in intermediate.csr -text -days 1825 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out intermediate.crt

# leaf
openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
  -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
  -out server.crt

server.crt и intermediate.crt необходимо объединить в один файл цепочки сертификатов и сохранить на сервере. server.key также следует сохранить на сервере. root.crt следует сохранить на стороне клиента, чтобы клиент мог проверить, что конечный сертификат сервера подписан цепочкой сертификатов, связанной с доверенным корневым сертификатом. root.key и intermediate.key следует хранить в автономном режиме для использования при создании будущих сертификатов.