瞭解 適用於 PostgreSQL 的 Azure 資料庫 單一伺服器根 CA 變更中的變更

適用於：適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器

重要

適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器位於淘汰路徑上。 強烈建議您升級至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。 如需移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器的詳細資訊，請參閱單一伺服器 適用於 PostgreSQL 的 Azure 資料庫 發生什麼事？。

適用於 PostgreSQL 的 Azure 資料庫 單一伺服器開始規劃跟證書變更2022 年 12 月 （12/2022） 作為標準維護和安全性最佳做法的一部分。 本文提供變更、受影響的資源，以及確保應用程式維持與資料庫伺服器連線所需的步驟的詳細數據。

為什麼需要跟證書更新？

在過去，適用於 PostgreSQL 的 Azure 資料庫使用者只能使用預先定義的憑證來連線到其 PostgreSQL 伺服器，其位於 此處。 不過， 證書頒發機構單位 （CA） 瀏覽器論壇 最近發佈了 CA 廠商發行的多個憑證報告，以不符合規範。

根據產業的合規性需求，CA 廠商已開始撤銷不合規 CA 的 CA 憑證，要求伺服器使用合規 CA 所發行的憑證，並以這些合規 CA 的憑證來簽署。 由於 適用於 PostgreSQL 的 Azure 資料庫 使用了其中一個不符合規範的憑證，因此我們需要將憑證輪替為相容版本，以將Postgres伺服器的潛在威脅降到最低。

新的憑證會在 2022 年 12 月 （2022 年 12 月 12 日） 開始推出並生效。

從 2022 年 12 月 （2022 年 12 月 12 日） 開始執行哪些變更？

從 2022 年 12 月開始，BaltimoreCyberTrustRoot 跟證書會取代為名為 DigiCertGlobalRootG2 跟證書的相容版本。 如果您的應用程式利用 verify-ca 或 verify-full 作為資料庫用戶端連線中 sslmode 參數的值，則必須遵循指示，將新的憑證新增至證書存儲，以維持連線能力。

我需要對客戶端進行任何變更，才能維持連線能力嗎？

用戶端上不需要變更程式碼或應用程式。 如果您遵循下面的憑證更新建議，只要 BaltimoreCyberTrustRoot 憑證未從合併的 CA 憑證中移除，您仍然可以繼續連線。 建議您不要從合併的 CA 憑證中移除 BaltimoreCyberTrustRoot，直到進一步通知維持連線為止。

我需要對客戶端憑證進行任何變更嗎

根據預設，PostgreSQL 不會執行伺服器證書的任何驗證。 這表示，在理論上，在沒有用戶端知道的情況下，仍然可以詐騙伺服器身分識別（例如修改 DNS 記錄或接管伺服器 IP 位址）。 若要防止任何可能的詐騙，必須使用用戶端上的 SSL 憑證驗證。 這類驗證可以透過應用程式用戶端設定 連接字串 ssl 模式值 - verify-ca 或 verify-full。 如果選擇這些ssl模式值，您應該遵循下一節中的指示。

用戶端憑證更新建議

• 從下列鏈接下載 BaltimoreCyberTrustRoot 和 DigiCertGlobalRootG2 根 CA：

  • https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
  • https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem

• 或者，若要防止未來的中斷，建議將下列根目錄新增至信任的存放區：

  • DigiCert Global Root G3 （指紋：7e04de896a3e666d00e687d33ffad93be83d349e）
  • Microsoft RSA 跟證書授權單位 2017 （指紋：73a5e64a3bff8316ff0edccc618a906e4eae4d74）
  • Microsoft ECC 跟證書授權單位 2017 （指紋：999a64c37ff47d9fab95f14769891460eec4c3c5）

• 產生合併的 CA 憑證存放區，其中同時包含 BaltimoreCyberTrustRoot 和 DigiCertGlobalRootG2 憑證。

  • 針對使用 DefaultJavaSSLFactory 的 Java （PostgreSQL JDBC） 使用者，請執行：

    keytool -importcert -alias PostgreSQLServerCACert  -file D:\BaltimoreCyberTrustRoot.crt.pem  -keystore truststore -storepass password -noprompt
    

    keytool -importcert -alias PostgreSQLServerCACert2  -file D:\DigiCertGlobalRootG2.crt.pem -keystore truststore -storepass password  -noprompt
    

    然後將原始金鑰存放區檔案取代為新產生的金鑰存放區檔案：

    • System.setProperty（“javax.net.ssl.trustStore”，“path_to_truststore_file”] ：
    • System.setProperty（“javax.net.ssl.trustStorePassword”，“password”）：

  • 針對 Windows 上的 .NET （Npgsql） 使用者，請確定 Baltimore CyberTrust Root 和 DigiCert Global Root G2 都存在於 Windows 證書存儲中，信任的跟證書授權單位。 如果有任何憑證不存在，請匯入遺漏的憑證。

    

  • 針對 Linux 上使用 SSL_CERT_DIR 的 .NET （Npgsql） 使用者，請確定 BaltimoreCyberTrustRoot 和 DigiCertGlobalRootG2 都存在於 SSL_CERT_DIR 所指示的目錄中。 如果有任何憑證不存在，請建立遺漏的憑證檔案。

  • 對於其他 PostgreSQL 用戶端使用者，您可以合併兩個 CA 憑證檔案，如下所示

    
    -----BEGIN CERTIFICATE-----
    （Root CA1： BaltimoreCyberTrustRoot.crt.pem）
    -----END CERTIFICATE----- -----BEGIN CERTIFICATE-----
    
    （Root CA2： DigiCertGlobalRootG2.crt.pem）
    -----END CERTIFICATE-----

• 將原始根 CA pem 檔案取代為合併的根 CA 檔案，然後重新啟動您的應用程式/用戶端。

• 未來，在伺服器端部署新的憑證之後，您可以將 CA pem 檔案變更為 DigiCertGlobalRootG2.crt.pem。

注意

在憑證變更之前，請勿卸除或變更 Baltimore 憑證 。 完成變更之後，我們會傳送通訊，之後他們就能放心地卸除巴爾的摩憑證。

如果我們移除 BaltimoreCyberTrustRoot 憑證，該怎麼辦？

連線到 適用於 PostgreSQL 的 Azure 資料庫 伺服器時，您可能會開始收到連線錯誤。 您必須再次使用 BaltimoreCyberTrustRoot 憑證設定 SSL，以維持連線能力。

常見問題集

1.如果我未使用 SSL/TLS，我是否需要更新根 CA？

如果您未使用 SSL/TLS，則不需要採取任何動作。

2.如果我使用 SSL/TLS，是否需要重新啟動資料庫伺服器來更新根 CA？

否，您不需要重新啟動資料庫伺服器，即可開始使用新的憑證。 這是客戶端變更，而連入用戶端連線需要使用新的憑證，以確保它們可以連線到資料庫伺服器。

3. 如何? 知道我是否使用 SSL/TLS 搭配跟證書驗證？

您可以檢閱您的 連接字串，以識別您的連線是否驗證跟證書。

• 如果您的 連接字串 包含 sslmode=verify-ca 或 sslmode=verify-full，您必須更新憑證。
• 如果您的 連接字串 包含 sslmode=disable、sslmode=allow、 sslmode=prefer或 sslmode=require，則不需要更新憑證。
• 如果您的 連接字串 未指定 sslmode，則不需要更新憑證。

如果您使用將 連接字串 抽象化的用戶端，請檢閱用戶端的檔，以瞭解它是否驗證憑證。 若要瞭解 PostgreSQL sslmode，請檢閱 PostgreSQL 檔中的 SSL 模式描述。

4.搭配使用 App Service 與 適用於 PostgreSQL 的 Azure 資料庫 有何影響？

針對連線到 適用於 PostgreSQL 的 Azure 資料庫的 Azure 應用程式服務，我們可以有兩個可能的情況，這取決於您搭配應用程式使用 SSL 的方式。

• 這個新的憑證已新增至平台層級的App Service。 如果您使用應用程式 App Service 平臺中包含的 SSL 憑證，則不需要採取任何動作。
• 如果您明確在程式代碼中包含 SSL 憑證檔案的路徑，則必須下載新的憑證，並更新程式代碼以使用新的憑證。此案例的一個很好的範例是當您在App Service中使用自定義容器，如App Service檔中的 共用

5.如果使用 Azure Kubernetes Services （AKS） 搭配 適用於 PostgreSQL 的 Azure 資料庫，有何影響？

如果您嘗試使用 Azure Kubernetes Services （AKS） 連線到 適用於 PostgreSQL 的 Azure 資料庫，則類似於從專用客戶主機環境存取。 請參閱這裡的步驟。

6.如果使用 Azure Data Factory 連線到 適用於 PostgreSQL 的 Azure 資料庫，有何影響？

針對使用 Azure Integration Runtime 的連接器，連接器會利用 Azure 裝載環境中的 Windows 證書存儲中的憑證。 這些憑證已經與新套用的憑證兼容，因此不需要採取任何動作。

對於使用自我裝載整合運行時間的連接器，您可以在其中明確在 連接字串 中包含 SSL 憑證檔案的路徑，您必須下載新的憑證，並更新 連接字串 以使用它。

7.我需要規劃資料庫伺服器維護停機以進行這項變更嗎？

否。 由於此處的變更只會在用戶端連線到資料庫伺服器，因此此變更不需要資料庫伺服器進行維護停機。

8.如果我在 2022 年 11 月 30 日之後建立新的伺服器，我將會受到影響嗎？

針對在 2022 年 11 月 30 日之後建立的伺服器，您將繼續使用 BaltimoreCyberTrustRoot 搭配新的 DigiCertGlobalRootG2 跟證書，讓您的應用程式使用 SSL 連線。

9.Microsoft 更新其憑證的頻率或到期原則為何？

適用於 PostgreSQL 的 Azure 資料庫 所使用的這些憑證是由受信任的證書頒發機構單位 （CA） 提供。 因此，這些憑證的支援會系結至 CA 對這些憑證的支援。 BaltimoreCyberTrustRoot 憑證已排定在 2025 年到期，因此 Microsoft 必須在到期前執行憑證變更。 此外，如果這些預先定義的憑證中有無法預見的錯誤，Microsoft 必須在最早類似於 2021 年 2 月 15 日執行的變更時輪替憑證，以確保服務一律安全且符合規範。

10.如果我使用讀取複本，我只需要在主伺服器 或讀取複本上執行此更新嗎？

由於此更新是客戶端變更，因此，如果用戶端用來從複本伺服器讀取數據，您也必須為這些用戶端套用變更。

11.我們有伺服器端查詢來確認是否使用 SSL？

若要確認您是否使用 SSL 連線來連線到伺服器，請參閱 SSL 驗證。

12.如果我在憑證檔案中已經有 DigiCertGlobalRootG2，是否需要採取動作？

否。 如果您的憑證檔案已經有 DigiCertGlobalRootG2，就不需要採取任何動作。

13.如何檢查伺服器所傳送的憑證？

您可以使用許多工具。 例如，DigiCert 有一個方便 的工具 ，可顯示任何伺服器名稱的憑證鏈結。 （此工具適用於可公開存取的伺服器;它無法連線到虛擬網路 （VNET） 中包含的伺服器。 您可以使用的另一個工具是命令行中的 OpenSSL，您可以使用此語法來檢查憑證：

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

14.如果我有進一步的問題，該怎麼辦？

如有疑問，請在 Microsoft Q&A 中尋求社群專家的解答。 如果您有支援方案，而且需要技術協助，請建立 支援要求：

• 針對 [問題類型]，選取 [技術]。
• 針對 [ 訂用帳戶]，選取您的訂用 帳戶。
• 針對 [服務]，選取 [我的服務]，然後選取 [適用於 PostgreSQL 的 Azure 資料庫 – 單一伺服器]。
• 針對 [問題類型]，選取 [ 安全性]。
• 針對 [問題] 子類型，選取 [Azure 加密] 和 [ 基礎結構雙重加密]