Share via

了解「適用於 MySQL 的 Azure 資料庫」單一伺服器的根 CA 變更中的變更

  • 發行項

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

重要

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

「適用於 MySQL 的 Azure 資料庫」單一伺服器做為標準維護和安全性最佳做法的一部分，將會從 2022 年 10 月開始完成根憑證變更。 本文提供更多詳細資訊，包括變更、受影響的資源，以及確保應用程式持續連線至資料庫伺服器所需的步驟。

注意

本文僅適用於適用於 MySQL 的 Azure 資料庫 - 單一伺服器。 針對適用於 MySQL 的 Azure 資料庫 - 彈性伺服器，透過 SSL 通訊所需的憑證是 DigiCert 全域根 CA

本文包含「從屬」一詞的參考，Microsoft 已不再使用該字詞。 從軟體中移除該字詞時，我們也會將其從本文中移除。

為什麼需要根憑證更新？

適用於 MySQL 的 Azure 資料庫使用者只能使用預先定義的憑證來連線至其位在這裡的 MySQL 伺服器。 不過，憑證授權單位 (CA) 瀏覽器論壇最近發行的報表顯示，有多個由 CA 廠商發行的憑證不符合規範。

根據產業的合規性需求，CA 廠商會針對不符合規範的 CA，開始撤銷其 CA 憑證、要求伺服器使用符合規範的 CA 憑證，並由這些符合規範的 CA 憑證進行簽署。 因為「適用於 MySQL 的 Azure 資料庫」使用其中一個不合規的憑證，我們需要將憑證輪替為符合規範的版本，希望將 MySQL 伺服器遭受的潛在威脅降到最低。

我的用戶端是否需要任何變更以維持連線能力？

如果您已遵循以下建立合併 CA 憑證所述的步驟，則只要從合併的 CA 憑證中「未移除 BaltimoreCyberTrustRoot 憑證」，就可以繼續連線。 若要維持連線能力，建議您除非進一步通知，否則會在合併的 CA 憑證中保留 BaltimoreCyberTrustRoot。

建立合併 CA 憑證

若要避免因意外撤銷憑證而中斷應用程式可用性，或更新已撤銷的憑證，請使用下列步驟。 此概念是建立新的 .pem 檔案，而這會合併目前憑證與新憑證，並會在 SSL 憑證驗證期間使用其中一個允許的值。 請參閱下列步驟:

  1. 從下列連結中下載 BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 根 CA：

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

    • 針對 Java (MySQL 連接器/J) 使用者，執行：

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

      keytool -importcert -alias MySQLServerCACert2 -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");

    • 針對 .NET (MySQL 連接器/NET，MySQLConnector) 使用者，請確定 BaltimoreCyberTrustRoot 和 DigiCertGlobalRootG2 都存在於 Windows 憑證存放區 (信任的根憑證授權單位) 中。 如果沒有任何憑證，則請匯入遺漏的憑證。

      Azure Database for MySQL .NET cert diagram

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

    • 針對其他 (MySQL 用戶端/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift) 使用者，您可以將兩個 CA 憑證檔案合併成下列格式：

      -----BEGIN CERTIFICATE-----
(Root CA1: BaltimoreCyberTrustRoot.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----

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

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

注意

除非進行憑證變更，否則請不要卸除或改變「Baltimore 憑證」。 我們將會在進行變更之後傳送通訊，然後安全地卸除「Baltimore 憑證」。

如果移除 BaltimoreCyberTrustRoot 憑證會怎麼樣？

連線至適用於 MySQL 的 Azure 資料庫伺服器時，您將會開始遇到連線錯誤。 您需要再次使用 BaltimoreCyberTrustRoot 憑證來設定 SSL，才能維持連線能力。

常見問題集

如果我未使用 SSL/TLS，則是否仍然需要更新根 CA？

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

我的單一伺服器執行個體何時會進行根憑證變更？

從 BaltimoreCyberTrustRoot 移轉至 DigiCertGlobalRootG2 將會在 2022 年 10 月 分階段開始，對 Azure 的所有區域執行。 若要確定您不會失去與伺服器的連線，請遵循建立合併 CA 憑證底下所述的步驟。 合併 CA 憑證將允許透過 SSL 連線到單一伺服器執行個體，並包含這兩個憑證的其中一個。

何時可以完全移除 BaltimoreCyberTrustRoot 憑證？

移轉在所有 Azure 區域成功完成之後，我們會傳送通訊貼文，以便您能夠安全地變更單一 CA DigiCertGlobalRootG2 憑證。

我在透過 SSL 連線到單一伺服器執行個體時未指定任何 CA 憑證，我是否需要執行上述 步驟？

如果您在受信任的根存放區中同時擁有 CA 根憑證，則不需要採取任何進一步的動作。 這也適用於使用本機存放區來存取根 CA 憑證的用戶端驅動程式。

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

否，您不需要重新啟動資料庫伺服器，即可開始使用新的憑證。 此根憑證是一項用戶端變更，而且連入用戶端連線需要使用新的憑證，以確保這些連線可以連線至資料庫伺服器。

如何知道我是否搭配使用 SSL/TLS 與根憑證驗證？

您可以檢閱連接字串來識別您的連線是否驗證根憑證。

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

如果您使用可將連接字串抽象化的用戶端，則請檢閱用戶端的文件，以了解用戶端是否驗證憑證。

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

針對連線至適用於 MySQL 的 Azure 資料庫的 Azure 應用程式服務，有兩種可能的情況，視您搭配使用 SSL 與應用程式的方式而定。

  • 這個新的憑證已新增至平台層級的 App Service。 如果您要在應用程式中使用 App Service 平台上所含的 SSL 憑證，則不需要採取任何動作。 這是最常見的案例。
  • 如果您在程式碼中明確包括 SSL 憑證檔案的路徑，則需要下載新的憑證，並產生上面所提及的合併憑證，並使用憑證檔案。 此案例的不錯範例是當您在 App Service 中使用 App Service 文件中所共用的自訂容器時。 這是罕見案例，但我們已看到有些使用者使用此案例。

搭配使用 Azure Kubernetes Services (AKS) 與適用於 MySQL 的 Azure 資料庫有何影響？

如果您嘗試使用 Azure Kubernetes Services (AKS) 連線至適用於 MySQL 的 Azure 資料庫，則這會與從專用客戶主機環境進行存取類似。 請參閱這裡的步驟。

使用 Azure Data Factory 連線至適用於 MySQL 的 Azure 資料庫有何影響？

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

針對使用自我裝載整合執行階段的連接器，而在此執行階段中，您已明確在連接字串中包括 SSL 憑證檔案的路徑，您需要下載新的憑證，並更新連接字串以使用該憑證。

我是否需要規劃此變更的資料庫伺服器維護停機時間？

否。 因為變更只針對用戶端以連線至資料庫伺服器，所以此變更沒有資料庫伺服器所需的維護停機時間。

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

適用於 MySQL 的 Azure 資料庫所使用的憑證是由信任的憑證授權單位 (CA) 所提供。 因此，這些憑證的支援會繫結至 CA 對這些憑證的支援。 BaltimoreCyberTrustRoot 憑證預定於 2025 年到期，因此 Microsoft 需要在到期前完成憑證變更。 此外，如果這些預先定義的憑證中有未預期的錯誤 (bug)，則 Microsoft 需要在最早就讓憑證輪替 (類似 2021 年 2 月 15 日執行的變更)，以確保服務隨時都安全且符合規範。

如果我使用讀取複本，則是否只需要在來源伺服器或讀取複本上執行此更新？

因為這項更新是一項用戶端變更，所以如果使用用戶端來讀取複本伺服器中的資料，則也需要套用這些用戶端的變更。

如果我使用資料輸入複寫，則是否需要執行任何動作？

如果您使用資料輸入複寫來連線至適用於 MySQL 的 Azure 資料庫，則需要考慮兩件事：

  • 如果資料複寫是從虛擬機器 (內部部署或 Azure 虛擬機器) 到適用於 MySQL 的 Azure 資料庫，則您需要檢查是否使用 SSL 來建立複本。 執行 SHOW SLAVE STATUS，並檢查下列設定。

    Master_SSL_Allowed            : Yes
Master_SSL_CA_File            : ~\azure_mysqlservice.pem
Master_SSL_CA_Path            :
Master_SSL_Cert               : ~\azure_mysqlclient_cert.pem
Master_SSL_Cipher             :
Master_SSL_Key                : ~\azure_mysqlclient_key.pem

    如果您看到已針對 CA_file、SSL_Cert 和 SSL_Key 提供憑證，則需要新增新的憑證來更新檔案，以及建立合併的憑證檔案。

  • 如果資料複寫介於兩部適用於 MySQL 的 Azure 資料庫伺服器之間，則您需要執行 CALL mysql.az_replication_change_master 來重設複本，並提供新的雙重根憑證作為最後一個參數 master_ssl_ca。

是否有伺服器端查詢可判斷是否使用 SSL？

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

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

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

如果我是使用 PHP 驅動程式搭配 enableRedirect，為什麼需要更新根憑證？

為了解決合規性需求，主機伺服器的 CA 憑證已從 BaltimoreCyberTrustRoot 變更為 DigiCertGlobalRootG2。 透過此更新，使用 PHP 用戶端驅動程式搭配 enableRedirect 的資料庫連線無法再連線到伺服器，因為用戶端裝置不知道憑證變更和新的根 CA 詳細資料。 使用 PHP 重新導向驅動程式的用戶端裝置會略過閘道，直接連線到主機伺服器。 如需深入了解「適用於 MySQL 的 Azure 資料庫」單一伺服器的結構，請參閱此連結。

如果我有其他問題，該怎麼辦？

如需問題，請從 Microsoft Q&A 中的社群專家取得解答。 如果您有支援方案，且需要技術協助，則請與我們連絡。