默认情况下，PostgreSQL 不会对服务器证书执行任何验证。这意味着可以在客户端不知情的情况下伪造服务器身份，例如修改 DNS 记录或接管服务器的 IP 地址。要防止身份伪造，客户端必须能够通过信任链验证服务器身份。建立信任链的方法是：在一台计算机上放置根证书机构（CA）的自签名证书，在另一台计算机上放置由根证书签发的叶证书。也可以使用由根证书签发、又用于签发叶证书的“中间”证书。

要让客户端验证服务器的身份，请在客户端放置根证书，并在服务器上放置由该根证书签发的叶证书。要让服务器验证客户端的身份，请在服务器上放置根证书，并在客户端放置由该根证书签发的叶证书。也可以使用一个或多个中间证书（通常与叶证书存储在一起），将叶证书链接到根证书。

建立信任链后，客户端可以通过两种方式验证服务器发送的叶证书。如果参数 sslmode 设为 verify-ca，libpq 会沿证书链检查到存储在客户端上的根证书，以验证服务器是否可信。如果 sslmode 设为 verify-full，libpq 还会验证服务器主机名是否与服务器证书中存储的名称匹配。如果无法验证服务器证书，SSL 连接将失败。在大多数对安全敏感的环境中，建议使用 verify-full。

在 verify-full 模式下，会将主机名与证书的主体替代名称属性匹配；如果不存在类型为 dNSName 的主体替代名称，则与通用名称属性匹配。如果证书的名称属性以星号（*）开头，该星号会被视为通配符，匹配除点（.）以外的所有字符。这意味着该证书不会匹配子域。如果使用 IP 地址而不是主机名建立连接，则会匹配该 IP 地址（不执行任何 DNS 查询）。

要允许服务器证书验证，必须将一个或者更多个根证书放置在用户主目录下的 ~/.postgresql/root.crt 文件中（在 Microsoft Windows 上该文件名为 %APPDATA%\postgresql\root.crt）。如果需要把服务器发来的证书链链接到存储在客户端的根证书，还应该将中间证书加到该文件中。

如果文件 ~/.postgresql/root.crl 存在（微软 Windows 上的 %APPDATA%\postgresql\root.crl），证书撤销列表（CRL）项也会被检查。

可以通过设置连接参数 sslrootcert 和 sslcrl，或环境变量 PGSSLROOTCERT 和 PGSSLCRL，更改根证书文件与 CRL 的位置。

如果服务器请求客户端的叶证书以验证客户端身份，libpq 将发送用户主目录下 ~/.postgresql/postgresql.crt 文件中存储的证书。这些证书必须通过证书链连接到服务器信任的根证书。还必须存在匹配的私钥文件 ~/.postgresql/postgresql.key。在 Microsoft Windows 上，这两个文件分别名为 %APPDATA%\postgresql\postgresql.crt 和 %APPDATA%\postgresql\postgresql.key。可以通过连接参数 sslcert 和 sslkey，或环境变量 PGSSLCERT 和 PGSSLKEY，覆盖证书和密钥文件的位置。

在 Unix 系统上，私钥文件的权限必须禁止所属组及其他用户的任何访问；可以用 chmod 0600 ~/.postgresql/postgresql.key 这样的命令实现。另一种做法是使文件归 root 所有，并允许组用户读取（即 0640 权限）。这种设置适用于由操作系统管理证书和密钥文件的安装环境。此时，应将 libpq 用户加入有权访问这些证书和密钥文件的组。（在 Microsoft Windows 上，不检查文件权限，因为假定 %APPDATA%\postgresql 目录是安全的。）

postgresql.crt 中的第一个证书必须是客户端的证书，因为它必须匹配客户端的私钥。可以选择将“中间”证书追加到该文件 — 这样做避免了在服务器上存放中间证书的要求（ssl_ca_file）。

有关创建证书的说明，请参见第 18.9.5 节。

sslmode 参数的不同值提供不同级别的保护。SSL 可以防范三类攻击：

要确保连接受到 SSL 保护，必须在建立连接之前，在客户端和服务器两端配置 SSL。如果仅在服务器上配置，客户端可能在得知服务器要求高安全性之前就已发送敏感信息（例如密码）。在 libpq 中，可以将 sslmode 参数设为 verify-full 或 verify-ca，并向系统提供用于验证的根证书，以确保连接安全。这类似于使用 https URL 进行加密的网页浏览。

服务器通过身份认证后，客户端便可以传送敏感数据。这意味着，在此之前，客户端无需知道是否会使用证书进行认证，因此可以安全地仅在服务器配置中指定这一点。

所有 SSL 选项都会产生加密和密钥交换的开销，因此必须在性能与安全性之间作出权衡。表 33.1 说明了不同 sslmode 值所能防范的风险，以及它们所表达的对安全性和开销的取舍。

verify-ca 和 verify-full 之间的区别取决于根 CA 的策略。如果使用了一个公共 CA，verify-ca 允许连接到那些可能已经被其他人注册到该 CA 的服务器。在这种情况下，总是应该使用 verify-full。如果使用了一个本地 CA 或者甚至是一个自签名的证书，使用 verify-ca 常常就可以提供足够的保护。

sslmode 的默认值是 prefer。如表所示，从安全角度看，这一设置没有意义；它只会在可能时带来性能开销。将其作为默认值仅出于向后兼容的考虑，不建议在有安全要求的部署中使用。

表 33.2 总结了与客户端 SSL 设置相关的文件。

如果你的应用程序初始化 libssl 和/或 libcrypto 库，并且 libpq 构建时带有 SSL 支持，你应该调用 PQinitOpenSSL 告诉 libpq libssl 和/或 libcrypto 库已被你的应用程序初始化，以便 libpq 不会再初始化这些库。但是，当使用 OpenSSL 版本 1.1.0 或更高版本时，无需这样做，因为重复初始化不再成问题。