在適用於 PostgreSQL 的 Azure 資料庫彈性伺服器中，使用 TLS 與 SSL 來保護連線

2025-06-23

適用範圍：適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

適用於 PostgreSQL 的 Azure 資料庫彈性伺服器會使用傳輸層安全性 (TLS) 將您的用戶端應用程式強制連線到適用於 PostgreSQL 的 Azure 資料庫彈性服務。 TLS 是業界標準通訊協定，可確保為資料庫伺服器與用戶端應用程式之間的網路連線加密。 TLS 是安全通訊端層 (SSL) 更新後的通訊協定。

什麼是 TLS？

TLS 是自 Netscape 的 SSL 通訊協定製作，並已定期加以取代。 SSL 或 TLS/SSL 用詞有時仍會互換使用。 TLS 是由兩層組成：TLS 記錄顯示和 TLS 交握顯示。記錄顯示提供關聯安全性。交握顯示可讓伺服器和客戶互相確認，並在交易任何資訊之前協調加密評量和密碼編譯金鑰。

上圖顯示典型的 TLS 1.2 交握順序，其中包含下列步驟：

用戶端一開始會傳送名為 ClientHello 的訊息，其表示願意透過 TLS 1.2 與用戶端支援的一組加密套件通訊。
伺服器會接收訊息、使用 ServerHello 回答，並同意透過 TLS 1.2 使用特定加密套件與用戶端通訊。
伺服器也會傳送其金鑰共用。此金鑰共用的詳細資料會根據選取的加密套件而變更。若要讓用戶端和伺服器同意密碼編譯金鑰，它們必須接收或共用彼此的一部分。
伺服器會傳送憑證 (由憑證授權單位 [CA] 簽署) 與 ClientHello 和 ServerHello 的部分簽章。它也包含金鑰共用。如此一來，用戶端就會知道它們是真實的。
用戶端成功收到資料，然後產生自己的金鑰共用之後，會將其與伺服器金鑰共用混合，進而產生工作階段的加密金鑰。
用戶端會將其金鑰共用傳送給伺服器，啟用加密，並傳送 Finished 訊息。此訊息是到目前為止所發生狀況的文字記錄雜湊。伺服器會執行相同的動作。它會混合金鑰共用以取得金鑰，並傳送自己的 Finished 訊息。
現在應用程式資料可以在連線上傳送時加密。

憑證鏈結

憑證鏈結是包含 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。您也可使用下列查詢，依程序、用戶端和應用程式收集適用於 PostgreSQL 的 Azure 資料庫彈性伺服器的 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 模式	說明
`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，其中 defaultdir 於 nix 系統上為 ${user.home}/.postgresql/ 和 Windows 上為 %appdata%/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 憑證和更新應用程式用戶端

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

若要將憑證匯入用戶端憑證存放區，您可能必須在從前述 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 憑證。

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

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

目前，適用於 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 資料庫彈性伺服器支援許多加密套件，其中包含屬於 HIGH：！aNULL 類別的 TLS 1.2 通訊協定版本。

針對 TLS/SSL 連線錯誤進行疑難排解

針對 TLS/SSL 通訊協定版本相容性進行疑難排解的第一個步驟，是識別您或使用者嘗試從用戶端存取 TLS 加密適用於 PostgreSQL 的 Azure 資料庫彈性伺服器時所看到的錯誤訊息。視應用程式和平台而定，錯誤訊息可能會不同。在許多情況下，它們會指向基礎問題。
若要確定 TLS/SSL 通訊協定版本相容性，請檢查資料庫伺服器和應用程式用戶端的 TLS/SSL 組態，以確保其支援相容版本和加密套件。
分析資料庫伺服器與用戶端 TLS/SSL 版本與加密套件之間的任何差異或差距。嘗試藉由啟用或停用特定選項、升級或降級軟體，或變更憑證或金鑰來解決問題。例如，您可能需要根據安全性和相容性需求，在伺服器或用戶端上啟用或停用特定的 TLS/SSL 版本。例如，您可能需要停用 TLS 1.0 和 TLS 1.1，這被視為不安全且已被取代，並啟用 TLS 1.2 和 TLS 1.3，這些較安全且為現代。
隨著 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 憑證。

了解如何在 Azure 入口網站或 Azure CLI 中使用私人存取 (VNet 整合) 選項以建立適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。
了解如何在 Azure 入口網站或 Azure CLI 中使用公用存取 (允許的 IP 位址) 選項以建立適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。

共用方式為