فهم التغييرات في تغيير المرجع المصدق الجذر لقاعدة بيانات Azure لخادم MySQL الفردي

تُطبق على: قاعدة بيانات Azure للخادم الوحيد الخاص بـ MySQL

هام

قاعدة بيانات Azure لخادم MySQL الفردي على مسار الإيقاف. نوصي بشدة بالترقية إلى قاعدة بيانات Azure لخادم MySQL المرن. لمزيد من المعلومات حول الترحيل إلى خادم Azure Database for MySQL المرن، راجع ما الذي يحدث لقاعدة بيانات Azure لخادم MySQL الفردي؟

ستكمل قاعدة بيانات Azure لخادم MySQL الفردي كجزء من أفضل ممارسات الصيانة والأمان القياسية تغيير شهادة الجذر بدءا من أكتوبر 2022. توفر لك هذه المقالة مزيدًا من التفاصيل حول التغييرات والموارد المتأثرة والخطوات اللازمة للتأكد من أن التطبيق الخاص بك يحافظ على الاتصال بخادم قاعدة البيانات الخاصة بك.

إشعار

تنطبق هذه المقالة على:Azure Database for MySQL Single Server فقط. بالنسبة لـAzure Database for MySQL Single Server، فإن الشهادة اللازمة للاتصال عبر طبقة مآخذ التوصيل الآمنة هي DigiCert Global Root CA

تحتوي هذه المقالة على مراجع لمصطلح slave، وهو مصطلح لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، بالتالي سنزيله من هذه المقالة.

لماذا يجب تحديث شهادة الجذر؟

يُمكن لمستخدمي Azure Database for MySQL استخدام الشهادة المعرفة مسبقًا فقط للاتصال بخادم MySQL الخاص بهم، الموجود هنا. ومع ذلك، نشر منتدي مستعرض المرجع المصدق مؤخرًا تقارير من شهادات متعددة صادرة عن الموردين CA لتكون غير متوافقة.

وفقاً لمتطلبات الامتثال للصناعة، بدأ موردو CA في إبطال شهادات CA للمراجع المصدقة غير المتوافقة، مما يتطلب من الخوادم استخدام الشهادات الصادرة عن CA المتوافقة والموقعة من شهادات CA من تلك CAs المتوافقة. ونظرا لأن Azure Database for MySQL استخدمت إحدى هذه الشهادات غير المتوافقة، فقد احتجنا إلى تدوير الشهادة إلى الإصدار المتوافق لتقليل التهديد المحتمل لخوادم MySQL.

هل أنا بحاجة إلى إجراء أي تغييرات على العميل للحفاظ على الاتصال؟

إذا اتبعت الخطوات المذكورة ضمن Create a combined CA certificate أدناه، فيمكنك متابعة الاتصال ما دام لم تتم إزالة شهادة BaltimoreCyberTrustRoot من شهادة CA المدمجة. للحفاظ على الاتصال، نوصي بالاحتفاظ بـ BaltimoreCyberTrustRoot في شهادة المرجع المصدق المدمجة حتى إشعار آخر.

إنشاء شهادة CA مجمعة

لكي تتجنب انقطاع توفر التطبيق الخاص بك نتيجة لإبطال الشهادات بشكل غير متوقع، أو لتحديث شهادة تم إبطالها، استخدم الخطوات التالية. الفكرة هي إنشاء ملف .pem جديد، والذي يجمع بين الشهادة الحالية والجديدة وأثناء التحقق من صحة شهادة SSL، سوف يتم استخدام إحدى القيم المسموح بها. الرجوع إلى الخطوات التالية:

  1. تنزيل BaltimoreCyberTrustRoot و DigiCertGlobalRootG2 Root CA من الروابط التالية:

  2. أنشئ متجراً مدمجاً لشهادات CA مع تضمين شهادتي BaltimoreCyberTrustRoot وDigiCertGlobalRootG2.

    • وبالنسبة لمستخدمي Java (MySQL Connector/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
      

      ثم استبدل ملف keystore الأصلي بالملف الجديد الذي تم إنشاؤه:

      • System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");
      • System.setProperty("javax.net.ssl.trustStorePassword","password");
    • بالنسبة لمستخدمي.NET (MySQL Connector/NET، MySQLConnector)، تأكد من وجود كل من BaltimoreCyberTrustRoot و DigiCertGlobalRootG2 في مخزن الشهادات Windows، المراجع المصدقة الجذر الموثوق بها. في حال لم تكن هناك أي شهادات، قم باستيراد الشهادة المفقودة.

      Azure Database for MySQL .NET cert diagram

    • بالنسبة لمستخدمي .NET على Linux الذين يستخدمون SSL_CERT_DIR، تأكد من وجود كل من BaltimoreCyberTrustRoot و DigiCertGlobalRootG2 في الدليل المشار إليه بواسطة SSL_CERT_DIR. في حال لم تكن هناك أي شهادات، قم باستيراد الشهادة المفقودة.

    • وبالنسبة للمستخدمين الآخرين (MySQL Client/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. استبدل ملف «pem» المرجع المصدق الجذر الأصلي بملف المرجع المصدق الجذر المدمج ثم أعد تشغيل التطبيق/العميل.

    وفي المستقبل، بعد نشر الشهادة الجديدة على جانب الخادم، يمكنك تغيير ملف CA pem إلى DigiCertGlobalRootG2.crt.pem.

إشعار

يُرجى عدم إسقاط Baltimore certificate أو تغييرها حتى يتم إجراء تغيير الشهادة. سنرسل اتصالا بعد إجراء التغيير ومن ثم سيكون من الآمن إسقاط شهادة بالتيمور.

ماذا يحدث لو قمنا بإزالة شهادة BaltimoreCyberTrustRoot؟

ستبدأ في مواجهة أخطاء الاتصال أثناء الاتصال بـAzure Database for MySQL server الخاص بك. ستحتاج إلى تكوين SSL مع شهادة BaltimoreCyberTrustRoot مرةً أخرى للحفاظ على الاتصال.

الأسئلة الشائعة

إذا كنت لا أستخدم SSL/TLS، فهل ما زلتُ بحاجة إلى تحديث المرجع المصدق الجذر؟

لا يتطلب اتخاذ أي إجراءات إذا كنت لا تستخدم SSL/TLS.

متى سيخضع مثيل الخادم الفردي لتغيير شهادة الجذر؟

سيتم تنفيذ الترحيل من BaltimoreCyberTrustRoot إلى DigiCertGlobalRootG2 عبر جميع مناطق Azure بدءا من أكتوبر 2022 على مراحل. للتأكد من عدم فقدان الاتصال بالخادم، اتبع الخطوات المذكورة ضمن إنشاء شهادة CA مدمجة. ستسمح شهادة CA المجمعة بالاتصال عبر SSL بمثيل الخادم الفردي الخاص بك مع أي من هاتين الشهادتين.

متى يمكنني إزالة شهادة BaltimoreCyberTrustRoot تماما؟

بمجرد اكتمال الترحيل بنجاح عبر جميع مناطق Azure، سنرسل منشور اتصال أنك آمن لتغيير شهادة CA DigiCertGlobalRootG2 واحدة.

لا أحدد أي شهادة CA أثناء الاتصال بمثيل الخادم الفردي عبر SSL، هل لا زلت بحاجة إلى تنفيذ الخطوات المذكورة أعلاه؟

إذا كان لديك كل من شهادة جذر المرجع المصدق في مخزن الجذر الموثوق به، فلن تكون هناك حاجة إلى مزيد من الإجراءات. ينطبق هذا أيضا على برامج تشغيل العميل التي تستخدم المتجر المحلي للوصول إلى شهادة المرجع المصدق الجذر.

إذا كنت أستخدم SSL/TLS، فهل انا بحاجة إلى إعادة تشغيل خادم قاعدة البيانات لتحديث المرجع المصدق الجذر؟

لا، لست بحاجة إلى إعادة تشغيل خادم قاعدة البيانات لبدء استخدام الشهادة الجديدة. تعد هذه الشهادة الجذر تغييرًا من جانب العميل وتحتاج اتصالات العميل الواردة إلى استخدام الشهادة الجديدة للتأكد من أنها يمكن الاتصال بخادم قاعدة البيانات.

كيف أعرف ما إذا كنت أستخدم SSL/TLS مع التحقق من شهادة الجذر؟

بإمكانك تحديد ما إذا كانت اتصالاتك تتحقق من شهادة الجذر من خلال مراجعة سلسلة الاتصال الخاصة بك.

  • إن كانت سلسلة الاتصال الخاصة بك تتضمن sslmode=verify-ca أو sslmode=verify-identity، فأنت بحاجة إلى تحديث الشهادة.
  • إذا كانت سلسلة الاتصال تتضمن sslmode=disable أو sslmode=allow أو sslmode=prefer أو sslmode=require, فأنت تحتاج إلى تحديث الشهادات.
  • إذا لم تحدد سلسلة الاتصال «sslmode»، فلن تحتاج إلى تحديث الشهادات.

إذا كنت تستخدم عميلًا يقوم بتجريد سلسلة الاتصال بعيدًا، فراجع وثائق العميل لفهم ما إذا كان يتحقق من الشهادات أم لا.

ما تأثير استخدام App Service مع Azure Database for MySQL؟

بالنسبة لخدمات تطبيقات Azure المتصلة بـAzure Database for MySQL، هناك سيناريوهان محتملان اعتمادًا على كيفية استخدام SSL مع التطبيق الخاص بك.

  • أضيفت هذه الشهادة الجديدة إلى App Service على مستوى النظام الأساسي. إذا كنت تستخدم شهادات SSL المُضمنة في النظام الأساسي لخدمة التطبيقات في التطبيق الخاص بك، فلا تحتاج إلي اتخاذ أي إجراء. هذا هو السيناريو المعروف.
  • إذا كنت تقوم بتضمين المسار إلى ملف شهادة SSL بشكل صريح في التعليمات البرمجية الخاصة بك، فسوف تحتاج إلى تنزيل الشهادة الجديدة وإنتاج شهادة مجمعة كما هو مذكور أعلاه واستخدام ملف الشهادة. مثال جيد على هذا السيناريو هو عند استخدام حاوياتٍ مخصصة في App Service كما هو مشترك في وثائق App Service. هذا سيناريو غير شائع لكننا رأينا بعض المستخدمين يستخدمونه.

ما تأثير استخدام Azure Kubernetes Services مع Azure Database for MySQL؟

إذا كنت تحاول الاتصال بـAzure Database for MySQL باستخدام خدمات Azure Kubernetes، فهي مشابهة للوصول من بيئة مضيفة مخصصة للعملاء. راجع الخطوات هنا.

ما تأثير استخدام Azure Data Factory للاتصال بـAzure Database for MySQL؟

بالنسبة إلى المُوصل الذي يستخدم Azure Integration Runtime، يستخدم الموصل الشهادات في مخزن الشهادات Windows في بيئة Azure المستضافة. هذه الشهادات مُتوافقة بالفعل مع الشهادات المطبقة حديثًا، وبالتالي لا يلزم اتخاذ أي إجراء.

بالنسبة إلى مُوصل يستخدم Integration Runtime المستضاف ذاتيا حيث تقوم بتضمين المسار صراحة إلى ملف شهادة SSL في سلسلة الاتصال، ستحتاج إلى تنزيل الشهادة الجديدة وتحديث سلسلة الاتصال لاستخدامها.

هل انا بحاجة إلى التخطيط لفترة تعطل للصيانة من أجل هذا التغيير؟

‏‏لا. منذ التغيير فقط على جانب العميل للاتصال بملقم قاعدة البيانات، ليس هناك أي وقت توقف للصيانة لازم لخادم قاعدة البيانات لهذا التغيير.

كم مرة تقوم Microsoft بتحديث شهاداتها أو ما هي نُهج انتهاء الصلاحية؟

تُستخدم هذه الشهادات المستخدمة من قِبل Azure Database for MySQL ويتم توفيرها من قِبل المراجع المصدقة الموثوق بها. لذلك يرتبط دعم هذه الشهادات بدعم هذه الشهادات من قبل المرجع المصدق. من المُقرر أن تنتهي صلاحية شهادة BaltimoreCyberTrustRoot في عام 2025، لذلك تحتاج Microsoft إلى إجراء تغيير الشهادة قبل انتهاء الصلاحية. أيضًا في حالة وجود أخطاء غير متوقعة في هذه الشهادات المحددة مسبقًا، تحتاج Microsoft أيضًا إلى إجراء تدوير الشهادة في أقرب وقت مماثل للتغيير الذي أُجرى في 15 فبراير 2021 لضمان أن الخدمة آمنة ومتوافقة في جميع الأوقات.

إذا كنت أستخدم نسخًا متماثلة للقراءة، فهل أحتاج إلى إجراء هذا التحديث على الخادم الأساسي فقط أم على جميع النسخ المتماثلة المقروءة؟

نظرًا لأن هذا التحديث هو تغيير من جانب العميل، إذا استخدم العميل قراءة البيانات من خادم النسخة المتماثلة، فسنحتاج إلى تطبيق التغييرات على هؤلاء العملاء أيضاً.

إذا كنت أستخدم النسخ المتماثل للبيانات، فهل أنا بحاجة إلى تنفيذ أي إجراء؟

في حال كنت تستخدم النسخ المتماثل للبيانات للاتصال بـAzure Database for MySQL، فهناك أمران يجب مراعاتهما:

  • إذا كان النسخ المتماثل للبيانات من جهاز ظاهري (المحلي أو جهاز Azure الظاهري) إلى Azure Database for MySQL، تحتاج إلى التحقق مما إذا كان يتم استخدام 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، فستحتاج إلى تحديث الملف عن طريق إضافة الشهادة الجديدة وإنشاء ملف شهادة مدمج.

  • إذا كان النسخ المتماثل للبيانات بين خادمي Azure Database for MySQL، فسوف تحتاج إلى إعادة تعيين النسخة المتماثلة عن طريق تنفيذ CALL mysql.az_replication_change_master وتوفير شهادة الجذر المزدوج الجديدة كمعلمة أخيرة master_ssl_ca.

هل ليدك استعلام من جانب الخادم لتحديد ما إذا كان يتم استخدام SSL؟

وللتحقق مما إذا كنت تستخدم اتصال SSL للاتصال بالخادم، راجع التحقق من SSL.

هل هناك إجراءٌ مطلوب إذا كان لدي بالفعل DigiCertGlobalRootG2 في ملف الشهادة الخاص بي؟

‏‏لا. لا يتطلب اتخاذ أي إجراء إذا كان ملف الشهادة يحتوي بالفعل على DigiCertGlobalRootG2.

لماذا أحتاج إلى تحديث شهادة الجذر الخاصة بي إذا كنت أستخدم برنامج تشغيل PHP مع enableRedirect؟

لتلبية متطلبات الامتثال، تم تغيير شهادات CA للخادم المضيف من BaltimoreCyberTrustRoot إلى DigiCertGlobalRootG2. مع هذا التحديث، لم يعد بإمكان اتصالات قاعدة البيانات التي تستخدم برنامج تشغيل PHP Client مع enableRedirect الاتصال بالخادم، لأن أجهزة العميل ليست على دراية بتغيير الشهادة وتفاصيل المرجع المصدق الجذر الجديد. تتصل أجهزة العميل التي تستخدم برامج تشغيل إعادة توجيه PHP مباشرة بالخادم المضيف، متجاوزة البوابة. راجع هذا الارتباط لمزيد من التفاصيل حول بنية قاعدة بيانات Azure لخادم MySQL الفردي.

ماذا لو كان لدي العديد من الأسئلة؟

للحصول على أسئلة، احصل على إجابات من خبراء المجتمع في Microsoft Q&A. في حال امتلاكك خطة دعم وحاجتك إلى مساعدة فنية، تواصل معنا: