تغييرات شهادة Azure TLS
هام
تم نشر هذه المقالة بشكل متزامن مع تغيير شهادة TLS، ولا يتم تحديثها. للحصول على معلومات محدثة حول المراجع المصدقة، راجع تفاصيل مرجع شهادات Azure.
تستخدم Microsoft شهادات TLS من مجموعة المراجع المصدقة الجذر (CAs) التي تلتزم بمتطلبات خط الأساس لمنتدى CA/Browser Forum. تحتوي جميع نقاط نهاية Azure TLS/SSL على شهادات تتسلسل حتى المراجع المصدقة الجذر (CAs) الواردة في هذه المقالة. بدأت التغييرات التي تم إجراؤها على نقاط نهاية Azure في الانتقال في أغسطس 2020، مع استكمال بعض الخدمات لتحديثاتها في عام 2022. تحتوي جميع نقاط نهاية Azure TLS/SSL التي تم إنشاؤها حديثًا على شهادات محدثة تصل إلى المراجع المصدقة الجذر (CAs) الجديدة.
تتأثر جميع خدمات Azure بهذا التغيير. يتم سرد تفاصيل بعض الخدمات أدناه:
- بدأت خدمات Microsoft Entra ID (Microsoft Entra ID) هذا الانتقال في 7 يوليو 2020.
- للحصول على أحدث المعلومات حول تغييرات شهادة TLS لخدمات Azure IoT، راجع منشور مدونة Azure IoT هذا.
- بدأ Azure IoT Hub هذا الانتقال في فبراير 2023 مع اكتمال متوقع في أكتوبر 2023.
- سيبدأ Azure IoT Central هذا الانتقال في يوليو 2023.
- ستبدأ خدمة توفير جهاز Azure IoT Hub في هذا الانتقال في يناير 2024.
- بدأ Azure Cosmos DB هذا الانتقال في يوليو 2022 مع اكتمال متوقع في أكتوبر 2022.
- يمكن العثور على تفاصيل حول لـ Azure Storage تغييرات شهادة TLS في منشور مدونة Azure Storage.
- تنتقل ذاكرة التخزين المؤقت Azure لـ Redis بعيدًا عن شهادات TLS الصادرة عن Baltimore CyberTrust Root بدءًا من مايو 2022، كما هو موضح في مقالة Azure Cache for Redis هذه
- لدى Azure Instance Metadata Service إكمال متوقع في مايو 2022، كما هو موضح في منشور مدونة Azure Governance and Management هذا.
ما التغير الذي حدث؟
قبل التغيير، كانت معظم شهادات TLS المستخدمة من قبل خدمات Azure متسلسلة حتى المرجع المصدق الجذر التالي:
الاسم الشائع لـ CA | بصمة الإبهام (لوغاريتم التجزئة الآمن 1) |
---|---|
جذر بالتيمور CyberTrust | d4de20d05e66fc53fe1a50882c78db2852cae474 |
بعد التغيير، ستربط شهادات TLS المستخدمة من قبل خدمات Azure ما يصل إلى أحد المراجع المصدقة الجذر التالية:
الاسم الشائع لـ CA | بصمة الإبهام (لوغاريتم التجزئة الآمن 1) |
---|---|
DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
DigiCert Global Root CA | a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 |
جذر بالتيمور CyberTrust | d4de20d05e66fc53fe1a50882c78db2852cae474 |
D-TRUST Root Class 3 CA 2 2009 | 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0 |
المرجع المصدق الجذر Microsoft RSA 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
المرجع المصدق الجذر لـ Microsoft ECC 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
هل تأثر تطبيقي؟
إذا كان التطبيق الخاص بك يحدد بوضوح قائمة المرجع المصدق المقبولة، فمن المحتمل أن يكون تطبيقك قد تأثر. تُعرف هذه الممارسة باسم تثبيت الشهادة. راجع مقالة Microsoft Tech Community حول تغييرات Azure Storage TLS للحصول على مزيد من المعلومات عن كيفية تحديد ما إذا كانت خدماتك قد تأثرت والخطوات التالية.
فيما يلي بعض الطرق لاكتشاف ما إذا كان التطبيق الخاص بك قد تأثر أم لا على النحو التالي:
ابحث في التعليمات البرمجية المصدر عن بصمة الإبهام والاسم الشائع وخصائص الشهادة الأخرى لأي من Microsoft IT TLS CAs في مستودع Microsoft PKI. إذا كان هناك تطابق، فسيتأثر طلبك. لحل هذه المشكلة، قم بتحديث التعليمات البرمجية المصدر التي تتضمن CAs الجديدة. كأفضل ممارسة، تأكد من أنه يمكن إضافة المراجع المصدقة أو تحريرها في غضون مهلة قصيرة. تتطلب لوائح الصناعة استبدال شهادات المرجع المصدق في غضون سبعة أيام من التغيير، ومن ثمّ يحتاج العملاء الذين يعتمدون على التثبيت إلى التفاعل بسرعة.
إذا كان لديك تطبيق يتكامل مع Azure APIs أو خدمات Azure الأخرى ولم تكن متأكدًا مما إذا كان يستخدم تثبيت الشهادة أم لا، فتحقق من بائع التطبيق.
قد تتطلب أنظمة التشغيل المختلفة وأوقات تشغيل اللغة التي تتصل بخدمات Azure المزيد من الخطوات لبناء سلسلة الشهادات بشكل صحيح بهذه الجذور الجديدة:
- Linux: تتطلب منك العديد من التوزيعات إضافة المراجع المصدقة إلى /etc/ssl/certs. للحصول على تعليمات محددة، راجع وثائق التوزيع.
- Java: تأكد من أن مخزن مفاتيح Java يحتوي على المراجع المصدقة المذكورة أعلاه.
- Windows الموجود قيد التشغيل في بيئات غير متصلة: ستحتاج الأنظمة التي تعمل في بيئات غير متصلة إلى إضافة الجذور الجديدة إلى مخزن الشهادات الجذر الموثوقة، والمتوسطات المضافة إلى مخزن المراجع المصدقة المتوسطة.
- Android: تحقق من وثائق جهازك وإصدار Android.
- الأجهزة الأخرى، وخاصة إنترنت الأشياء: اتصل بالشركة المصنعة للجهاز.
إذا كانت لديك بيئة يتم فيها تعيين قواعد جدار الحماية للسماح للمكالمات الصادرة بتنزيل قائمة إبطال الشهادات (CRL) المحددة فقط و/أو مواقع التحقق من بروتوكول حالة الشهادة عبر الإنترنت (OCSP)، فستحتاج إلى السماح بعناوين URL التالية ل CRL وOCSP. للحصول على قائمة كاملة بعناوين URL ل CRL وOCSP المستخدمة في Azure، راجع مقالة تفاصيل AZURE CA.
- http://crl3.digicert.com
- http://crl4.digicert.com
- http://ocsp.digicert.com
- http://crl.microsoft.com
- http://oneocsp.microsoft.com
- http://ocsp.msocsp.com
الخطوات التالية
إذا كانت لديك أسئلة، فاتصل بنا من خلال الدعم.