С поддержкой SSL компилированный сервер Tantor SE-1C можно запустить с поддержкой шифрованных соединений, используя протоколы TLS, включенные путем установки параметра ssl в on в файле postgresql.conf. Сервер будет прослушивать как обычные, так и SSL соединения на одном и том же TCP-порту и будет вести переговоры с любым подключающимся клиентом о том, использовать ли SSL. По умолчанию это на выбор клиента; см. Раздел 19.1 о том, как настроить сервер для требования использования SSL для некоторых или всех соединений.

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

На Unix-системах разрешения на файл server.key должны запрещать доступ миру или группе; для этого используйте команду chmod 0600 server.key. В качестве альтернативы, файл может принадлежать пользователю root и иметь доступ на чтение для группы (то есть разрешения 0640). Эта настройка предназначена для установок, где сертификаты и ключевые файлы управляются операционной системой. Затем пользователь, от имени которого работает сервер Tantor SE-1C, должен быть добавлен в группу, которая имеет доступ к этим сертификатам и ключевым файлам.

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

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

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

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

Tantor SE-1C читает системный файл конфигурации OpenSSL. По умолчанию этот файл называется openssl.cnf и находится в каталоге, указанном в выводе команды openssl version -d. Это значение по умолчанию можно изменить, установив переменную среды OPENSSL_CONF на имя желаемого файла конфигурации.

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

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

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

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

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

Существует два подхода для обеспечения того, чтобы пользователи предоставляли сертификат при входе.

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

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

Таблица 17.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 должны быть сохранены в офлайн-режиме для использования при создании будущих сертификатов.