在编译时启用了SSL支持的情况下，可以通过在 postgresql.conf 中将参数 ssl 设置为 on 来启动支持使用TLS协议的加密连接的 PostgreSQL 服务器。服务器将侦听同一 TCP 端口上的普通连接和SSL连接，并与任何连接的客户端协商是否使用SSL。默认情况下，这由客户端选择；有关如何设置服务器以要求使用SSL进行某些或所有连接，请参见第 20.1 节。

要在SSL模式下启动，必须存在包含服务器证书和私钥的文件。默认情况下，这些文件预计分别在服务器的数据目录中命名为 server.crt 和 server.key，但可以使用配置参数 ssl_cert_file 和 ssl_key_file 指定其他名称和位置。

在 Unix 系统上，server.key 的权限必须禁止任何对世界或组的访问；通过命令 chmod 0600 server.key 实现此目的。或者，该文件可以归 root 所有并具有组读取访问权限（即 0640 权限）。该设置适用于由操作系统管理证书和密钥文件的安装。然后，运行 PostgreSQL 服务器的用户应成为可以访问这些证书和密钥文件的组成员。

如果数据目录允许组读取访问权限，则证书文件可能需要位于数据目录之外，以便符合上述安全要求。通常，启用组访问权限是为了允许非特权用户备份数据库，在这种情况下，备份软件将无法读取证书文件并且可能会出错。

如果私钥受密码保护，服务器将提示输入密码，并且在输入密码之前不会启动。默认情况下使用密码会禁用在不重启服务器的情况下更改服务器 SSL 配置的能力，但请参阅 ssl_passphrase_command_supports_reload。此外，受密码保护的私钥根本无法在 Windows 上使用。

server.crt 中的第一个证书必须是服务器的证书，因为它必须与服务器的私钥匹配。也可以将“中间”证书颁发机构的证书附加到该文件中。这样做可以避免在客户端上存储中间证书的必要性，前提是根证书和中间证书是使用 v3_ca 扩展创建的。（这将证书的基本约束 CA 设置为 true。）这允许更容易地使中间证书过期。

无需将根证书添加到 server.crt。相反，客户端必须具有服务器证书链的根证书。

PostgreSQL 读取系统范围的 OpenSSL 配置文件。默认情况下，此文件名为 openssl.cnf，并且位于 openssl version -d 报告的目录中。可以通过将环境变量 OPENSSL_CONF 设置为所需的配置文件的名称来覆盖此默认设置。

OpenSSL 支持范围广泛的密码和身份验证算法，这些算法的强度各不相同。虽然可以在 OpenSSL 配置文件中指定密码列表，但可以通过修改 postgresql.conf 中的 ssl_ciphers 来专门指定数据库服务器使用的密码。

要要求客户端提供受信任的证书，请将您信任的根证书颁发机构（CA）的证书放置在数据目录中的文件中，将 postgresql.conf 中的参数 ssl_ca_file 设置为新文件名，并将身份验证选项 clientcert=verify-ca 或 clientcert=verify-full 添加到 pg_hba.conf 中相应的 hostssl 行。然后，将在 SSL 连接启动期间从客户端请求证书。（有关如何在客户端上设置证书的说明，请参见第 32.19 节。）

对于带有 clientcert=verify-ca 的 hostssl 条目，服务器将验证客户端的证书是否由受信任的证书颁发机构之一签名。如果指定了 clientcert=verify-full，则服务器不仅会验证证书链，还会检查用户名或其映射是否与提供的证书的 cn（通用名称）匹配。请注意，当使用 cert 身份验证方法时，始终确保证书链验证（请参见第 20.12 节）。

如果您希望避免将中间证书存储在客户端上（假设根证书和中间证书是使用 v3_ca 扩展创建的），则链接到现有根证书的中间证书也可以出现在 ssl_ca_file 文件中。如果设置了参数 ssl_crl_file 或 ssl_crl_dir，还会检查证书吊销列表 (CRL) 条目。

clientcert 身份验证选项适用于所有身份验证方法，但仅适用于指定为 hostssl 的 pg_hba.conf 行。如果未指定 clientcert，则仅当存在客户端证书并且配置了 CA 时，服务器才会根据其 CA 文件验证客户端证书。

有两种方法可以强制用户在登录期间提供证书。

第一种方法利用 pg_hba.conf 中 hostssl 条目的 cert 身份验证方法，这样证书本身用于身份验证，同时还提供 ssl 连接安全性。有关详细信息，请参见第 20.12 节。（使用 cert 身份验证方法时，无需显式指定任何 clientcert 选项。）在这种情况下，将检查证书中提供的 cn（通用名称）与用户名或适用的映射。

第二种方法将 hostssl 条目的任何身份验证方法与通过将 clientcert 身份验证选项设置为 verify-ca 或 verify-full 来验证客户端证书相结合。前一个选项仅强制证书有效，而后者还确保证书中的 cn（通用名称）与用户名或适用的映射匹配。

表 18.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

然后，使用该密钥签署请求以创建根证书颁发机构（使用 Linux 上的默认 OpenSSL 配置文件位置）

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 应脱机存储，以用于创建未来的证书。