在 Azure Database for PostgreSQL 中使用 TLS 保护连接

Azure Database for PostgreSQL 强制使用传输层安全性（TLS）将客户端应用程序连接到 Azure Database for PostgreSQL 灵活服务器实例。 TLS 是一种行业标准协议，可确保在数据库服务器与客户端应用程序之间实现加密网络连接。 TLS 是安全套接字层 (SSL) 的更新协议。 SSL 和 TLS 这两个术语仍可互换使用。

重要

从 2025 年 11 月 11 日起，以下列表中的 Azure 区域计划用于使用新的中间 CA 证书的 TLS/SSL 证书轮换。

• 美国中西部
• 东亚
• 英国南部

从 2026 年 1 月 19 日开始，此轮换计划扩展到所有剩余的 Azure 区域，包括 Azure 政府和其他所有区域。

有关故障排除的信息，请参阅 证书锁定问题。

证书链

证书链是包含 TLS/SSL 证书和 CA 证书的证书的有序列表。 它们使接收方能够验证发送方和所有 CA 是否可信。 链或路径以 TLS/SSL 证书开头。 链中的每个证书都由链中下一个证书标识的实体签名。

链以根 CA 证书结束。 此证书始终由 CA 本身签名。 必须验证链中所有证书的签名，直至根 CA 证书。

链中位于 TLS/SSL 证书和根 CA 证书之间的任何证书都称为中间证书。

TLS 版本

全球多个政府实体均制定了有关网络安全的 TLS 准则。 在美国，这些组织包括卫生与公众服务部以及国家标准与技术研究所。 TLS 提供的安全级别受 TLS 协议版本和受支持的密码套件的影响最大。

密码套件是一组算法，其中包含密码、密钥交换算法和哈希算法。 它们共同用于建立安全的 TLS 连接。 大多数 TLS 客户端和服务器都支持多种替代方法。 它们在建立安全连接时必须进行协商，以选择一个通用 TLS 版本和密码套件。

Azure Database for PostgreSQL 支持 TLS 1.2 版本和更高版本。 在 RFC 8996 中，Internet 工程任务组 (IETF) 明确指出不得使用 TLS 1.0 和 TLS 1.1。 这两种协议在 2019 年底被弃用。

默认情况下，使用早期版本的 TLS 协议（如 TLS 1.0 和 TLS 1.1）的所有传入连接均被拒绝。

IETF 于 2018 年 8 月在 RFC 8446 中发布了 TLS 1.3 规范，TLS 1.3 现在是最常用且推荐的 TLS 版本。 TLS 1.3 比 TLS 1.2 更快、更安全。

注释

SSL 和 TLS 证书将验证连接是否受到一流加密协议的保护。 在线加密连接可以防止对传输中的数据进行未经授权的访问。 强烈建议使用最新版本的 TLS 来加密与 Azure Database for PostgreSQL 灵活服务器实例的连接。

尽管我们不建议使用，但如果需要，可以禁用 TLS\SSL 以连接到 Azure Database for PostgreSQL 灵活服务器实例。 可以将 require_secure_transport 服务器参数更新为 OFF。 还可以通过设置 ssl_min_protocol_version 和 ssl_max_protocol_version 服务器参数来设置 TLS 版本。

证书身份验证使用 SSL 客户端证书进行身份验证。 在此方案中，PostgreSQL 服务器会将提供的客户端证书的公用名 (CN) 属性与请求的数据库用户进行比较。

目前，Azure Database for PostgreSQL 不支持：

• 基于 SSL 证书的身份验证。
• 自定义 SSL/TLS 证书。

注释

Microsoft对各种 Azure 服务（包括 Azure Database for PostgreSQL）进行了根 CA 更改。 有关详细信息，请参阅 Azure TLS 证书更改和在客户端上的配置 SSL 部分。

若要确定当前的 TLS/SSL 连接状态，可以加载 sslinfo 扩展，然后调用 ssl_is_used() 函数来确定是否正在使用 SSL。 如果连接使用 SSL，该函数会返回 t。 否则，将返回 f。 还可以使用以下查询按进程、客户端和应用程序来收集有关 Azure Database for PostgreSQL 灵活服务器实例的 SSL 使用情况的所有信息。

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

若要进行测试，还可以直接使用 openssl 命令：

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

此命令输出低级别协议信息，例如 TLS 版本和密码。 必须使用选项 -starttls postgres。 否则，此命令会报告未使用 SSL。 要使用此命令，至少需要具有 OpenSSL 1.1.1。

若要强制实施最新的、最安全的 TLS 版本，用于保护客户端到 Azure Database for PostgreSQL 灵活服务器实例的连接，请将 ssl_min_protocol_version 设置为 1.3。 此设置 要求 连接到 Azure Database for PostgreSQL 灵活服务器实例 的客户端才能使用此版本的协议 来安全通信。 旧客户端可能无法与服务器通信，因为它们不支持此版本。

在客户端上配置 SSL

默认情况下，PostgreSQL 不会对服务器证书执行任何验证。 因此，可在客户端不知情的情况下欺骗服务器标识（例如通过修改 DNS 记录或接管服务器 IP 地址）。 所有 SSL 选项都以加密和密钥交换的形式传输产生了开销，因此在性能和安全性之间进行权衡。

为了防止欺骗，必须在客户端上使用 SSL 证书验证。

有许多连接参数可用来配置用于 SSL 的客户端。 一些重要说明包括：

• ssl：使用 SSL 进行连接。 此属性不需要与之关联的值。 它的存在只是用于指定 SSL 连接。 为了与将来的版本兼容，首选值为 true。 在此模式下，建立 SSL 连接时，客户端驱动程序会验证服务器的标识，防止“中间人”攻击。 它会检查服务器证书是否由受信任的颁发机构签名，并且你正在连接到的主机是否与证书中的主机名相同。

• sslmode：如果需要加密，并且希望连接在无法加密的情况下失败，请设置 sslmode=require。 此设置可确保服务器配置为接受此主机 IP 地址的 SSL 连接，并且服务器能够识别客户端证书。 如果服务器不接受 SSL 连接，或者无法识别客户端证书，连接会失败。 下表列出了此设置的值：

  SSL 模式	Explanation
  disable	不使用加密。
  allow	如果服务器设置需要加密或强制执行加密，则使用加密。
  prefer	如果服务器设置允许加密，则使用加密。
  require	使用了加密。 它可确保服务器配置为接受此主机 IP 地址的 SSL 连接，并且服务器能够识别客户端证书。
  verify-ca	使用了加密。 根据客户端上存储的证书验证服务器证书签名。
  verify-full	使用了加密。 根据客户端上存储的证书验证服务器证书签名和主机名。

基于 libpq 的客户端（例如 psql）和 JDBC 所用的默认 sslmode 模式有所不同。 基于 libpq 的客户端默认为 prefer。 JDBC 客户端默认为 verify-full。

• sslcert、sslkey, 和 sslrootcert：这些参数可以替代客户端证书、PKCS-8 客户端密钥和根证书的默认位置。 它们默认分别位于 /defaultdir/postgresql.crt、/defaultdir/postgresql.pk8 和 /defaultdir/root.crt，其中在 Linux 系统中为 defaultdir，在 Windows 中为 ${user.home}/.postgresql/。

CA 是负责颁发证书的机构。 受信任的证书颁发机构是有权验证人员真实身份的实体。 为了使此模型正常工作，所有参与者都必须就一组受信任的 CA 达成一致。 所有操作系统和大多数 Web 浏览器都附带了一组受信任的 CA。

使用 verify-ca 和 verify-fullsslmode 配置设置也称为证书固定。 在这种情况下，PostgreSQL 服务器上的根 CA 证书必须与证书签名匹配，甚至与客户端上的证书匹配主机名。

当 CA 在 PostgreSQL 服务器证书上更改或过期时，可能需要定期更新客户端存储的证书。 若要确定是否固定 CA，请参阅证书固定和 Azure 服务。

若要详细了解客户端上的 SSL\TLS 配置，请参阅 PostgreSQL 文档。

对于使用 verify-ca 和 verify-fullsslmode 配置设置（即证书固定）的客户端，必须将以下三个根 CA 证书部署到客户端证书存储：

• DigiCert 全局根 G2 和 Microsoft RSA 根 CA 2017 根 CA 证书，因为服务将从 Digicert 迁移到 Microsoft CA。
• Digicert 全局根 CA，为了确保兼容旧版。

在证书固定方案中，下载根 CA 证书并更新应用程序客户端

若要在证书固定方案中更新客户端应用程序，可以下载证书：

• Microsoft RSA 根 CA 2017
• DigiCert 全局根 G2
• Digicert 全局根 CA

要将证书导入客户端证书存储，可能需要在从上述 URI 下载证书文件后，将证书 .crt 文件转换为 .pem 格式。 可以使用 OpenSSL 实用工具执行这些文件转换：

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

若要了解如何使用新的根 CA 证书更新客户端应用程序证书存储，可查看更新应用程序客户端的客户端 TLS 证书。

重要

使用 sslmode=verify-full 设置时，在某些 Postgres 客户端库中，与使用中间证书交叉签名的根 CA 证书的连接可能会失败。 这会形成备用信任路径。 在这种情况下，建议显式指定 sslrootcert 参数。 或者，将 PGSSLROOTCERT 环境变量从默认值 %APPDATA%\postgresql\root.crt 修改为存储 Microsoft RSA 根 CA 2017 根 CA 证书的本地路径。

1. 客户端应用程序与 Azure Database for PostgreSQL 灵活服务器实例之间出现连接中断问题 - 已提交支持工单。
2. 如果中间证书已轮换，则可能需要使用新的中间证书更新客户端证书存储。
3. 如何检查是否要固定中间证书 - 请参阅证书固定和 Azure 服务。

具有证书固定方案的只读副本

将根 CA 迁移到 Microsoft RSA 根 CA 2017 时，新创建的副本在较新的根 CA 证书上比之前创建的主服务器可行。 对于使用 verify-ca 和 verify-fullsslmode 配置设置（即证书固定）的客户端，必须中断连接才能接受这三个根 CA 证书：

• Microsoft RSA 根 CA 2017
• DigiCert 全局根 G2
• Digicert 全局根 CA

目前，Azure Database for PostgreSQL 不支持 基于证书的身份验证。

在证书固定方案中通过连接 psql 来测试客户端证书

在证书固定方案中，可以从客户端使用 psql 命令行测试与服务器的连接：

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

有关 SSL 和证书参数的详细信息，请参阅 psql 文档。

测试 TLS/SSL 连接

在尝试从客户端应用程序访问已启用 SSL 的服务器之前，请确保可以通过 psql 访问它。 如果建立了 SSL 连接，应该会看到如下例所示的输出：

psql (14.5)SSL 连接（协议：TLSv1.2，密码：ECDHE-RSA-AES256-GCM-SHA384，位：256，压缩：关闭）键入“help”以获取帮助。

还可以加载 sslinfo 扩展，然后调用 ssl_is_used() 函数来确定是否正在使用 SSL。 如果连接使用 SSL，该函数会返回 t。 否则，将返回 f。

密码套件

密码套件是一组加密算法。 TLS/SSL 协议使用密码套件中的算法来创建密钥并对信息加密。

密码套件显示为看似随机信息的长字符串，但该字符串的每个段都包含重要信息。 通常，此数据字符串包含几个关键组件：

• 协议（即 TLS 1.2 或 TLS 1.3）
• 密钥交换或协议算法
• 数字签名（身份验证）算法
• 批量加密算法
• 消息验证码算法 (MAC)

不同版本的 TLS/SSL 支持不同的密码套件。 TLS 1.2 密码套件无法与 TLS 1.3 连接协商，反之亦然。

目前，Azure Database for PostgreSQL 支持许多密码套件，其中包含属于 HIGH：！aNULL 类别的 TLS 1.2 协议版本。

故障排除

使用本“故障排除”部分中的指南快速识别和解决常见的 TLS/SSL 问题。 首先重现问题并收集诊断数据（客户端错误消息、psql 输出、OpenSSL s_client输出和服务器日志），然后验证服务器参数（require_secure_transport、ssl_min_protocol_version、ssl_max_protocol_version）、证书链和客户端 sslmode/sslrootcert 设置，以查明协议版本、密码套件或缺失/轮换证书中的不匹配情况。

TLS/SSL 连接错误

1. 排查和解决 TLS/SSL 协议版本兼容性问题的第一步，是识别你或用户在尝试通过客户端以 TLS 加密方式访问 Azure Database for PostgreSQL 灵活服务器实例时遇到的错误消息。 错误消息可能因应用程序和平台而异。 在许多情况下，它们指向根本问题。
2. 若要确定 TLS/SSL 协议版本兼容性，请检查数据库服务器和应用程序客户端的 TLS/SSL 配置，确保它们支持兼容的版本和密码套件。
3. 分析数据库服务器与客户端 TLS/SSL 版本和密码套件之间的任何差异或差距。 尝试通过启用或禁用某些选项、升级或降级软件或更改证书或密钥来解决它们。 例如，可能需要根据安全性和兼容性要求，在服务器或客户端上启用或禁用特定的 TLS/SSL 版本。 例如，可能需要禁用 TLS 1.0 和 TLS 1.1（这些 TLS 被视为不安全且已被弃用），并启用 TLS 1.2 和 TLS 1.3（它们更安全且更新式）。
4. 由 Microsoft RSA 根 CA 2017 颁发的最新证书在链中具有由 Digicert 全局根 G2 CA 交叉签名的中间证书。 使用 sslmode=verify-full 或 sslmode=verify-ca 设置时，在某些 Postgres 客户端库中，与使用中间证书交叉签名的根 CA 证书的连接可能会失败。 这会形成备用信任路径。

若要解决这些问题，请将所有三个必需的证书添加到客户端证书存储或显式指定 sslrootcert 参数。 或者，将 PGSSLROOTCERT 环境变量从默认值 %APPDATA%\postgresql\root.crt 修改为存储 Microsoft RSA 根 CA 2017 根 CA 证书的本地路径。

证书锁定问题

注释

如果未在客户端应用程序连接字符串中使用 sslmode=verify-full 或 sslmode=verify-ca 设置，则证书轮换不会影响你。 因此，无需执行本部分中的步骤。

1. 验证是否正在应用程序中使用证书固定。
2. 生成受信任的根存储中的证书列表
   1. 例如，可以在 Java 密钥存储中以编程方式获取受信任的证书列表。
   2. 例如，可以 检查 cacerts java 密钥存储，以查看它是否已包含所需的证书。
3. 如果你具有单个中间证书或单个 PostgreSQL 服务器证书，那么你正在使用证书固定。
4. 若要删除证书绑定，请从受信任的根存储中删除所有证书并添加新证书。
   1. 可以从Microsoft的官方存储库下载更新的证书： Azure 证书颁发机构详细信息。
      1. 当前链：
         1. DigiCert 全局根 G2
         2. Microsoft Azure RSA TLS 签发 CA 03 / 04 / 07 / 08
      2. 新链：
         1. DigiCert 全局根 G2
         2. Microsoft TLS RSA 根证书 G2
         3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

如果在执行这些步骤后遇到问题，请联系 Microsoft支持人员。 在标题中包含“ICA Rotation 2026”。

相关内容

• Azure 门户
• Azure CLI
• Azure 门户
• Azure CLI