在「適用於 PostgreSQL 的 Azure 資料庫」中使用 TLS 建立安全連線

適用於 PostgreSQL 的 Azure 資料庫會使用傳輸層安全性 （TLS） 強制將用戶端應用程式連線到適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體。 TLS 是業界標準通訊協定，可確保為資料庫伺服器與用戶端應用程式之間的網路連線加密。 TLS 是安全通訊端層 (SSL) 更新後的通訊協定。 SSL 和 TLS 這兩個術語仍可互換使用。

這很重要

從 2025 年 11 月 11 日開始，下列清單中的 Azure 區域會規劃使用新的中繼 CA 憑證的 TLS/SSL 憑證輪替。

• 美國中西部
• 東亞
• 英國南部

從 2026 年 1 月 19 日開始，此輪替計劃擴展到所有剩餘的 Azure 區域，包括 Azure Government 和所有其他區域。

如需疑難排解的相關資訊，請參閱 憑證固定問題。

憑證鏈結

憑證鏈是包含 TLS/SSL 憑證和 CA 憑證的憑證排序清單。 它們可讓接收者驗證寄件者和所有 CA 都值得信任。 鏈結或路徑的開頭會是 TLS/SSL 憑證。 鏈結中的每個憑證都會由鏈結中下一個憑證所識別的實體簽署。

鏈結會以根 CA 憑證終止。 此憑證一律會由 CA 本身簽署。 鏈結中所有憑證的簽署必須驗證至根 CA 憑證。

鏈結中位於 TLS/SSL 憑證與根 CA 憑證之間的任何憑證稱為中繼憑證。

TLS 版本

全球數個政府實體會維護 TLS 關於網路安全性的指導方針。 在美國，這些組織包括衛生及公共服務部和國家標準暨技術研究院。 TLS 提供的安全性層級受到 TLS 通訊協定版本和所支援的加密套件影響最大。

加密套件是一組演算法，包括加密、金鑰交換演算法和雜湊演算法。 將它們結合在一起以建立安全的 TLS 連線。 大部分的 TLS 用戶端和伺服器都支援多個替代方案。 當它們建立安全連線以選取通用的 TLS 版本和加密套件時，它們必須交涉。

適用於 PostgreSQL 的 Azure 資料庫支援 TLS 版本 1.2 和更新版本。 在 RFC 8996 中，網際網路工程任務推動小組 (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 來加密與「適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器」執行個體的連線。

雖然我們不建議這樣做，但如有需要，您可以停用 TLS\SSL 以連線至適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體。 您可以將 require_secure_transport 伺服器參數更新為 OFF。 您也可以藉由設定 ssl_min_protocol_version 和 ssl_max_protocol_version 伺服器參數來設定 TLS 版本。

憑證驗證是使用 SSL 用戶端憑證進行驗證來執行。 在此案例中，PostgreSQL 伺服器會比較所顯示用戶端憑證的一般名稱 (CN) 屬性與所要求的資料庫使用者。

目前，適用於 PostgreSQL 的 Azure 資料庫不支援：

• SSL 憑證式驗證。
• 自訂 SSL/TLS 憑證。

備註

Microsoft 對各種 Azure 服務進行了根 CA 更改，包括適用於 PostgreSQL 的 Azure 數據庫。 如需詳細資訊，請參閱 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 版本，以從用戶端連線到適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體，請設定 ssl_min_protocol_version 為 1.3。 該設定需要用戶端連線到「適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器」執行個體，才能僅使用此版本的通訊協定來進行安全通訊。 較舊的用戶端可能無法與伺服器通訊，因為它們不支援此版本。

在用戶端上設定 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	使用加密。 驗證伺服器憑證簽署和主機名稱是否與用戶端上儲存的憑證相符。

使用的預設 sslmode 模式在 libpq 型用戶端 (例如 psql) 和 JDBC 之間不同。 以 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。 所有作業系統和大部分的網頁瀏覽器都內建一組受信任的 CA。

使用 verify-ca 和 verify-fullsslmode 組態設定也稱為憑證關聯。 在此情況下，PostgreSQL 伺服器上的根 CA 憑證必須與用戶端上的憑證簽署，甚至是憑證主機名稱相符。

當 CA 在 PostgreSQL 伺服器憑證上變更或過期時，您可能需要定期更新用戶端儲存的憑證。 若要判斷您是否要關聯 CA，請參閱憑證關聯和 Azure 服務。

如需用戶端上 SSL/TLS 設定的詳細資訊，請參閱 PostgreSQL 文件。

針對使用 verify-ca 和 verify-fullsslmode 組態設定的用戶端 (也就是憑證關聯)，必須將三個根 CA 憑證部署到用戶端憑證存放區：

• DigiCert Global Root G2 and Microsoft RSA Root CA 2017 根 CA 憑證，因為服務正從 Digicert 移轉至 Microsoft CA。
• Digicert Global Root CA，以獲得舊版相容性。

在憑證關聯案例中下載根 CA 憑證和更新應用程式用戶端

若要在憑證關聯案例中更新用戶端應用程式，您可以下載憑證：

• Microsoft RSA 根憑證授權 2017
• DigiCert Global Root G2
• Digicert 全域根憑證授權

若要將憑證匯入用戶端憑證存放區，您可能必須在從前述 URI 下載憑證檔案後，將憑證 .crt 檔案轉換成 .pem 格式。 您可使用 OpenSSL 公用程式進行這些檔案轉換：

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

更新用戶端應用程式憑證存放區與新的根 CA 憑證的相關資訊記載於更新應用程式用戶端的用戶端 TLS 憑證。

這很重要

某些 Postgres 用戶端程式庫雖然使用 sslmode=verify-full 設定，但可能會因使用中繼憑證交叉簽署的根 CA 憑證而發生連線失敗。 結果是替代信任路徑。 在此情況下，建議您明確指定 sslrootcert 參數。 或者，將 PGSSLROOTCERT 環境變數設定從預設值的 %APPDATA%\postgresql\root.crt 設定為本機路徑，其中放置了 Microsoft RSA Root CA 2017 根 CA 憑證。

1. 體驗到用戶端應用程式與適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體之間的連線中斷 - 已開啟支援票證。
2. 如果您的中繼憑證已輪替，您可能需要使用新的中繼憑證來更新用戶端憑證存放區。
3. 如何檢查您是否要釘選中繼憑證 - 請參閱 憑證釘選和 Azure 服務。

閱讀具有憑證關聯複本的案例

將根 CA 移轉至 Microsoft RSA Root CA 2017 時，新建立的複本可能會使用相較於先前建立的主要伺服器更新的根 CA 憑證。 為了防止連線中斷，使用 verify-ca 和 verify-fullsslmode 組態設定 (也就是憑證關聯) 的用戶端必須接受三個根 CA 授權：

• Microsoft RSA 根憑證授權 2017
• DigiCert Global Root G2
• Digicert 全域根憑證授權

目前，適用於 PostgreSQL 的 Azure 資料庫不支援 憑證型驗證。

在憑證關聯案例中透過與 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 連線交涉，反之亦然。

目前，適用於 PostgreSQL 的 Azure 資料庫支援許多具有 TLS 1.2 通訊協定版本的密碼套件，這些版本屬於 HIGH：！aNULL 類別。

Troubleshoot

使用此疑難排解一節中的指引，快速識別並解決常見的 TLS/SSL 問題。 首先重現問題並收集診斷資料（用戶端錯誤訊息、psql 輸出、OpenSSL s_client輸出和伺服器日誌），然後驗證伺服器參數（require_secure_transport、ssl_min_protocol_version、ssl_max_protocol_version）、憑證鏈和用戶端 sslmode/sslrootcert 設定，以找出協定版本、密碼套件或遺失/輪換憑證中的不相符。

TLS/SSL 連線錯誤

1. 針對 TLS/SSL 通訊協定版本相容性進行疑難排解的第一個步驟，是識別您或您的使用者在嘗試從用戶端存取適用於 PostgreSQL 的 Azure 資料庫 TLS 加密下的彈性伺服器執行個體時看到的錯誤訊息。 視應用程式和平台而定，錯誤訊息可能會不同。 在許多情況下，它們會指向基礎問題。
2. 若要確定 TLS/SSL 通訊協定版本相容性，請檢查資料庫伺服器和應用程式用戶端的 TLS/SSL 組態，以確保其支援相容版本和加密套件。
3. 分析資料庫伺服器與用戶端 TLS/SSL 版本與加密套件之間的任何差異或差距。 嘗試藉由啟用或停用特定選項、升級或降級軟體，或變更憑證或金鑰來解決問題。 例如，您可能需要根據安全性和相容性需求，在伺服器或用戶端上啟用或停用特定的 TLS/SSL 版本。 例如，您可能需要停用 TLS 1.0 和 TLS 1.1，這被視為不安全且已被取代，並啟用 TLS 1.2 和 TLS 1.3，這些較安全且為現代。
4. 隨著 Microsoft RSA Root CA 2017 發行的最新憑證在由 Digicert Global Root G2 CA 交叉簽署的鏈結中包含中繼。 某些 Postgres 用戶端程式庫雖然使用 sslmode=verify-full 或 sslmode=verify-ca 設定，但可能會因使用中繼憑證交叉簽署的根 CA 憑證而發生連線失敗。 結果是替代信任路徑。

若要解決這些問題，請將這三個必要憑證新增至用戶端憑證存放區，或明確指定 sslrootcert 參數。 或者，將 PGSSLROOTCERT 環境變數設定從預設值的 %APPDATA%\postgresql\root.crt 設定為本機路徑，其中放置了 Microsoft RSA Root CA 2017 根 CA 憑證。

憑證釘選問題

備註

如果您未在 sslmode=verify-full 用戶端應用程式連接字串中使用 或 sslmode=verify-ca 設定，則憑證輪替不會影響您。 因此，您不需要遵循本節中的步驟。

1. 確認您是否在應用程式中使用 憑證鎖定（certificate pinning）。
2. 產生您的受信任根存放區中的憑證清單
   1. 例如，您可以 以程式設計方式取得 Java 金鑰儲存庫中的授信憑證清單。
   2. 例如，您可以 檢查 cacerts java 金鑰儲存庫，以查看它是否已包含必要的憑證。
3. 如果您有個別的中繼憑證或個別 PostgreSQL 伺服器憑證，表示您正在使用憑證綁定。
4. 若要移除憑證釘選，請從受信任的根存放區移除所有憑證，然後新增新的憑證。
   1. 您可以從 Microsoft 的官方存放庫下載更新的憑證： Azure 憑證授權單位詳細資料。
      1. 當前鏈：
         1. DigiCert Global Root G2
         2. Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      2. 新鏈：
         1. DigiCert Global Root G2
         2. 微軟 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