أستكشاف أخطاء التحقق من شهادة خادم حركة مرور Expressway Traffic Server لخدمات MRA وإصلاحها

المقدمة

يصف هذا المستند تغيير السلوك على إصدارات Expressway من X14.2.0 والإصدارات الأعلى المرتبطة بمعرف تصحيح الأخطاء من Cisco CSCwc69661 أو معرف تصحيح الأخطاء من Cisco CSCwa25108.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• التكوين الأساسي ل Expressway
• التكوين الأساسي MRA

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى Cisco Expressway على الإصدار X14.2 والإصدارات الأحدث.

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

معلومات أساسية

مع هذا التغيير في السلوك المميز بمعرف تصحيح الأخطاء من Cisco CSCwc69661 أو معرف تصحيح الأخطاء من Cisco CSCwa25108 ، يقوم خادم حركة المرور على منصة Expressway بإجراء التحقق من شهادة مدير الاتصالات الموحدة (CUCM) من Cisco والمراسلة الفورية الموحدة والتواجد (IM&P) من Cisco وعقد خادم Unity لخدمات الوصول المحمول والوصول عن بعد (MRA). قد يؤدي هذا التغيير إلى حدوث حالات فشل في تسجيل الدخول إلى MRA بعد إجراء ترقية على نظام Expressway الأساسي.  

بروتوكول نقل النص التشعبي الآمن (HTTPS) هو بروتوكول اتصال آمن يستخدم أمان طبقة النقل (TLS) لتشفير الاتصال. وهو يقوم بإنشاء هذه القناة الآمنة باستخدام شهادة TLS التي يتم تبادلها في مصافحة TLS. تخدم هذه الخدمة غرضين: المصادقة (لمعرفة الطرف البعيد الذي تتصل به) والخصوصية (التشفير). تحمي المصادقة هجمات الدخيل وتمنع الخصوصية المهاجمين من التنصت والعبث بالاتصالات.

يتم إجراء التحقق من TLS (الشهادة) في عين المصادقة ويسمح لك بالتأكد من إتصالك بالطرف البعيد الأيمن. ويتألف التحقق من عنصرين فرديين:

1. سلسلة مرجع التصديق الموثوق به (CA)

2. الاسم البديل للموضوع (SAN) أو الاسم الشائع (CN)

سلسلة المرجع المصدق الموثوق به

لكي تثق Expressway-C في الشهادة التي يرسلها CUCM / IM&P / Unity، يلزم أن تكون قادرة على إنشاء إرتباط من تلك الشهادة إلى المرجع المصدق (الجذر) الأعلى (CA) الذي تثق فيه. يسمى هذا الرابط، وهو تسلسل هرمي من الشهادات التي تربط شهادة كيانات بشهادة مرجع مصدق جذر، سلسلة ثقة. للتمكن من التحقق من سلسلة الثقة هذه، تحتوي كل شهادة على حقلين: المصدر (أو "الصادر بواسطة") والموضوع (أو "الصادر من أجل").

تتضمن شهادات الخادم، مثل واحد من CUCM الذي يرسل إلى Expressway-C، في حقل "الموضوع" بشكل خاص اسم المجال المؤهل بالكامل (FQDN) في CN:

        Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab

مثال على شهادة خادم ل CUCM CUCM.vngtp.lab. يحتوي على FQDN في سمة CN لحقل الموضوع مع سمات أخرى مثل الدولة (C)، الحالة (ST)، الموقع (L)، ... كما يمكننا أن نرى أن شهادة الخادم يتم تسليمها (إصدارها) من قبل مرجع مصدق يسمى vngtp-active-DIR-CA.

يمكن أيضا أن تقوم المراجع المصدقة عالية المستوى (المرجع المصدق الجذر) بإصدار شهادة لتعريف نفسها. في شهادة المرجع المصدق الجذر هذه، نرى أن المصدر والموضوع لهما نفس القيمة :

        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA

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

في الحالات النموذجية، لا تصدر تراخيص CA الجذر شهادات الخادم مباشرة. بدلا من ذلك، فإنها تصدر شهادات ل CAs أخرى. ويطلق على هذه الأنواع الأخرى من النوى الحادة بعد ذلك اسم النوى المرجعية المتوسطة. يمكن أن تقوم CAs الوسيطة بدورها بإصدار شهادات أو شهادات الخادم مباشرة ل CAs الوسيطة الأخرى. يمكن أن يكون لدينا حالة حيث يتم إصدار شهادة خادم من CA 1 متوسط، الذي بدوره يحصل على شهادة من CA 2 متوسط وهكذا. حتى يحصل المرجع المصدق الوسيط أخيرا على شهادته مباشرة من المرجع المصدق الجذر :

Server certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab
Intermediate CA 1 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1 
Intermediate CA 2 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-3 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
...
Intermediate CA n certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-n 
Root CA certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-C

الآن، من أجل أن تثق Expressway-C بشهادة الخادم التي يرسلها CUCM، يجب أن تكون قادرة على بناء سلسلة من الثقة من شهادة الخادم حتى شهادة مرجع مصدق رئيسي. ولتحقيق ذلك، نحتاج إلى تحميل شهادة المرجع المصدق الجذر وكذلك جميع شهادات المرجع المصدق الوسيطة (إذا كانت هناك أي شهادات، وهو ليس الحال إذا كان المرجع المصدق الجذر قد أصدر مباشرة شهادة خادم CUCM) في مخزن التوثيق الخاص ب Expressway-C.

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

هذه ليست حالة Expressway رغم ذلك وفقا لمعرف تصحيح الأخطاء من Cisco CSCwa12905 ومن غير الممكن تحميل شهادتين مختلفتين (موقعة ذاتيا على سبيل المثال) في مخزن الثقة ل Expressway التي لها نفس الاسم المشترك (CN). الطريقة للتصحيح على هذا، هي أن تقوم ب CA بتوقيع الشهادات أو أن تستخدم أسماء عامة مختلفة له أو أن ترى أنها تستخدم دائما نفس الشهادة (من المحتمل من خلال ميزة إعادة إستخدام شهادة في CUCM 14).

فحص SAN أو CN

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

نفس النوع من العمليات تحدث في متصفحك، لذا دعونا ننظر في هذا من خلال مثال. إذا قمت بالاستعراض إلى https://www.cisco.com سترى أيقونة قفل بجوار عنوان URL الذي أدخلته مما يعني أنه اتصال موثوق به. يستند هذا إلى كل من سلسلة ثقة CA (من القسم الأول) وكذلك إلى فحص SAN أو CN. إذا فتحنا الشهادة (عن طريق المستعرض بنقرة على أيقونة القفل)، سترى أن الاسم الشائع (يظهر في الحقل 'تم إصداره إلى:') مضبوط على www.cisco.com وهو يتوافق تماما مع العنوان الذي أردنا الاتصال به. بهذه الطريقة يمكن التأكد من إتصالنا بالخادم الصحيح (لأننا نثق في المرجع المصدق الذي قام بتوقيع الشهادة والذي يقوم بإجراء التحقق قبل تسليم الشهادة).

عند الاطلاع على تفاصيل الشهادة وعلى إدخالات شبكة منطقة التخزين (SAN) بشكل خاص، نلاحظ أن نفس الشيء يتكرر بالإضافة إلى بعض إدخالات شبكة منطقة التخزين (FQDN) الأخرى:

وهذا يعني أنه عندما نطلب الاتصال ب https://www1.cisco.com على سبيل المثال، سيظهر كاتصال آمن أيضا لأنه موجود في إدخالات شبكة التخزين (SAN).

ومع ذلك، عندما لا نقوم بالاستعراض إلى https://www.cisco.com ولكن مباشرة إلى عنوان IP (https://72.163.4.161)، فإنه لا يظهر اتصالا آمنا لأنه لا يثق في CA الذي قام بتوقيعه ولكن الشهادة المقدمة لنا، ولا يحتوي على العنوان (72.163.4.161) الذي أستخدمناه للاتصال بالخادم.

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

تغيير السلوك

تعتمد خدمات MRA بشكل كبير على العديد من إتصالات HTTPS عبر الطرق السريعة تجاه خوادم CUCM / IM&P / Unity للمصادقة بشكل صحيح ولجمع المعلومات الصحيحة الخاصة بالعميل الذي يقوم بتسجيل الدخول. يحدث هذا الاتصال عادة عبر المنافذ 8443 و 6972.

الإصدارات الأقل من X14.2.0

في الإصدارات الأقل من X14.2.0، لم يتحقق خادم حركة المرور الموجود على Expressway-C الذي يعالج إتصالات HTTPS الآمنة هذه من الشهادة التي تم تقديمها بواسطة الطرف البعيد. قد يؤدي هذا إلى هجمات الدخيل. في تكوين MRA، هناك خيار للتحقق من شهادة TLS من خلال تكوين "وضع التحقق من TLS" إلى "تشغيل" عندما تقوم بإضافة إما CUCM / IM&P / Unity servers تحت التكوين > الاتصالات الموحدة > خوادم CM الموحدة / IM وعقود خدمة التواجد / خوادم اتصال الوحدة. يتم عرض خيار التكوين ومربع المعلومات ذات الصلة كمثال، مما يشير إلى أنه يتحقق من FQDN أو IP في شبكة التخزين (SAN) بالإضافة إلى صلاحية الشهادة وما إذا كانت موقعة من قبل مرجع مصدق ثقة.

يتم التحقق من شهادة TLS هذا فقط من خلال اكتشاف خوادم CUCM / IM&P / Unity وليس في الوقت الذي يتم فيه الاستعلام عن مختلف الخوادم أثناء MRA. المأخذ الأول لهذا التكوين، هو أنه يتحقق منه فقط لعنوان الناشر الذي تقوم بإضافته. لا يتحقق من صحة إعداد الشهادة على عقد المشترك بشكل صحيح حيث أنها تسترجع معلومات عقدة المشترك (FQDN أو IP) من قاعدة بيانات عقدة الناشر. والعيب الثاني من هذا التكوين أيضا، هو أن ما يتم الإعلان عنه لعملاء MRA حيث يمكن أن تختلف معلومات الاتصال عن عنوان الناشر الذي تم وضعه في تكوين Expressway-C. على سبيل المثال، في CUCM، تحت نظام > خادم يمكنك الإعلان عن الخادم باستخدام عنوان IP (10.48.36.215 على سبيل المثال) ويتم إستخدام هذا بعد ذلك من قبل عملاء MRA (عبر اتصال Expressway الوكيل) ومع ذلك يمكنك إضافة CUCM على Expressway-C باستخدام FQDN من cucm.steven.lab. بافتراض أن شهادة tomcat من CUCM تحتوي على cucm.steven.lab كإدخال إلى SAN وليس كعنوان IP، بعد ذلك ينجح الاكتشاف مع 'TLS Verify Mode' على 'On' ولكن الاتصالات الفعلية من عملاء MRA يمكن أن تستهدف FQDN أو IP مختلف وبالتالي تفشل التحقق من TLS.

الإصدارات من X14.2.0 والإصدارات الأحدث

من إصدار X14.2.0 فصاعدا، يعمل خادم Expressway على التحقق من شهادة TLS لكل طلب HTTPS يتم إجراؤه من خلال خادم حركة مرور البيانات. وهذا يعني أنها تنفذ هذا أيضا عندما يتم تعيين "وضع التحقق من TLS" على "إيقاف" أثناء اكتشاف عقد CUCM / IM&P / Unity. عندما لا تنجح عملية التحقق من الصحة، لا يتم تأكيد اتصال TLS ويفشل الطلب الذي يمكن أن يؤدي إلى فقد الوظائف مثل مشاكل التكرار أو تجاوز الفشل أو فشل تسجيل الدخول الكامل على سبيل المثال. أيضا مع تعيين "وضع التحقق من TLS" على "تشغيل"، لا يضمن أن تعمل جميع الاتصالات بشكل صحيح كما هو منصوص عليه في المثال لاحقا.

ترد الشهادات الدقيقة التي يفحصها الطريق السريع من عقد CUCM / IM&P / Unity كما هو موضح في قسم دليل MRA.

بالإضافة إلى الإعداد الافتراضي على التحقق من TLS، هناك أيضا تغيير تم تقديمه في X14.2 والذي يمكن أن يعلن عن ترتيب تفضيل مختلف لقائمة التشفير، والذي يعتمد على مسار الترقية الخاص بك. قد يتسبب ذلك في حدوث إتصالات TLS غير متوقعة بعد ترقية البرنامج لأنه قد يحدث أنه قبل الترقية المطلوبة لشهادة Cisco Tomcat أو Cisco CallManager من CUCM (أو أي منتج آخر يحتوي على شهادة منفصلة لخوارزمية ECDSA) ولكن بعد الترقية فإنه يطلب متغير ECDSA (وهو متغير التشفير الأكثر أمانا فعليا من RSA). يمكن توقيع شهادات Cisco Tomcat-ECDSA أو Cisco CallManager-ECDSA من قبل CA مختلف أو شهادات ما زالت موقعة ذاتيا (الافتراضي).

لا يكون تغيير أمر تفضيل التشفير هذا ذا صلة بك دائما لأنه يعتمد على مسار الترقية كما هو موضح من ملاحظات إصدار Expressway X14.2.1. بإختصار، يمكنك أن ترى من الصيانة > الأمان > المشفرات لكل واحد من المشفيرات ما إذا كان يؤدي إلى إعداد "ECDHE-RSA-AES256-GCM-SHA384:" أم لا. وإذا لم يكن كذلك، فإنه يفضل تشفير ECDSA الأحدث على تشفير RSA. إذا كان كذلك، فسيكون لديك سلوك سابق مع RSA الذي لديه تفضيل أعلى عندئذ.

هناك طريقتان لفشل التحقق من TLS في هذا السيناريو، ويتم تغطيتهما بالتفصيل لاحقا:

1. المرجع المصدق الذي قام بتوقيع الشهادة البعيدة غير موثوق به

أ - شهادة موقعة ذاتيا

ب. الشهادة الموقعة من قبل مرجع مصدق غير معروف

2. لا يحتوي عنوان الاتصال (FQDN أو IP) في الشهادة

أستكشاف السيناريوهات وإصلاحها

تظهر السيناريوهات التالية سيناريو مشابها في بيئة معملية حيث فشل تسجيل الدخول إلى MRA بعد ترقية Expressway من X14.0.7 إلى X14.2. يتشابهون في السجلات، على الرغم من أن الدقة مختلفة. يتم تجميع السجلات فقط بواسطة التسجيل التشخيصي (من الصيانة > التشخيصات > التسجيل التشخيصي) الذي تم بدء تشغيله قبل تسجيل الدخول إلى MRA وتم إيقافه بعد فشل تسجيل الدخول إلى MRA. لم يتم تمكين أي تسجيل تصحيح أخطاء إضافي له.

1. المرجع المصدق الذي قام بتوقيع الشهادة البعيدة غير موثوق به

يمكن توقيع الشهادة عن بعد من قبل مرجع مصدق غير مضمن في المخزن الموثوق به للخادم Expressway-C أو يمكن أن تكون شهادة موقعة ذاتيا (في جوهرها مرجع مصدق أيضا) لا تتم إضافتها في مخزن التوثيق الخاص بخادم Expressway-C.

في المثال هنا، يمكنك ملاحظة أن الطلبات التي تنتقل إلى CUCM (10.48.36.215 - cucm.steven.lab) يتم التعامل معها بشكل صحيح على المنفذ 8443 (إستجابة 200 OK) ولكنها تتسبب في حدوث خطأ (إستجابة 502) على المنفذ 6972 لاتصال TFTP.

===Success connection on 8443===

2022-07-11T18:55:25.910+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,910" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Src-ip="127.0.0.1" Src-port="35764" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvODQ0Mw/cucm-uds/user/emusk/devices HTTP/1.1"

2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]:  Event="Request Allowed" Detail="Access allowed" Reason="In allow list" Username="emusk" Deployment="1" Method="GET" Request="https://cucm.steven.lab:8443/cucm-uds/user/emusk/devices" Rule="https://cucm.steven.lab:8443/cucm-uds/user/" Match="prefix" Type="Automatically generated rule for CUCM server" UTCTime="2022-07-11 16:55:25,916"
2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,916" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices HTTP/1.1"
2022-07-11T18:55:25.955+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Receive Response" Txn-id="189" TrackingID="" Src-ip="10.48.36.215" Src-port="8443" Msg="HTTP/1.1 200 "
2022-07-11T18:55:25.956+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="189" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35764" Msg="HTTP/1.1 200 "

===Failed connection on 6972===

2022-07-11T18:55:26.000+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,000" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Src-ip="127.0.0.1" Src-port="35766" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvNjk3Mg/CSFemusk.cnf.xml HTTP/1.1"

2022-07-11T18:55:26.006+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,006" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,016" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] WARNING: Core server certificate verification failed for (cucm.steven.lab). Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=0
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] ERROR: SSL connection failed for 'cucm.steven.lab': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2022-07-11T18:55:26.024+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,024" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="191" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35766" Msg="HTTP/1.1 502 connect failed"

يشير خطأ "التحقق من صحة الشهادة" إلى حقيقة عدم تمكن Expressway-C من التحقق من صحة مصافحة TLS. وسبب ذلك يظهر في سطر التحذير لأنه يشير إلى شهادة موقعة ذاتيا. إذا كان العمق موضح على هيئة 0، فإنها شهادة موقعة ذاتيا. عندما يكون العمق أعلى من 0، فهذا يعني أن له سلسلة شهادات وبالتالي يتم توقيعه من قبل مرجع مصدق غير معروف (من منظور Expressway-C).

عندما ننظر في ملف PCAP الذي تم تجميعه في الطوابع الزمنية المذكورة من سجلات النص، يمكنك أن ترى أن CUCM يقدم الشهادة مع CN على هيئة CUCM-ms.steven.lab (و cucm.steven.lab على هيئة SAN) موقعة من قبل Steven-DC-CA إلى Expressway-C على المنفذ 8443.

ولكن عندما نفحص الشهادة المقدمة على المنفذ 6972، يمكنك أن ترى أنها شهادة موقعة ذاتيا (المصدر نفسه) مع إعداد CN على هيئة CUCM-EC.Steven.lab. يعطي امتداد -EC إشارة إلى أن هذه هي شهادة ECDSA التي تم إعدادها على CUCM.

في CUCM تحت إدارة Cisco Unified OS، يمكنك النظر إلى الشهادات الموضحة تحت التأمين > إدارة الشهادات كما هو موضح هنا على سبيل المثال. تظهر شهادة مختلفة ل Tomcat و Tomcat-ECDSA حيث يكون Tomcat CA موقع (وموثوق به من قبل Expressway-C) بينما شهادة Tomcat-ECDSA موقعة ذاتيا وغير موثوق بها من قبل Expressway-C هنا.

2. عنوان الاتصال (FQDN أو IP) غير موجود في الشهادة

بالإضافة إلى مخزن الثقة، يتحقق خادم حركة مرور البيانات أيضا من عنوان الاتصال الذي يقوم عميل MRA بتقديم الطلب من أجله. على سبيل المثال، عند إعداد CUCM ضمن النظام > خادم CUCM الخاص بك باستخدام عنوان IP (10.48.36.215)، يعلن Expressway-C عن ذلك للعميل ويتم إستهداف الطلبات اللاحقة من العميل (الوكيل من خلال Expressway-C) بهذا العنوان.

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

2022-07-11T19:49:01.472+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,472" Module="network.http.trafficserver" Level="DEBUG": Detail="Receive Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Src-ip="127.0.0.1" Src-port="30044" Last-via-addr=""
HTTPMSG:
|GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw/cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1"
2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443"
HTTPMSG:
|GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] WARNING: SNI (10.48.36.215) not in certificate. Action=Terminate server=10.48.36.215(10.48.36.215)
2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] ERROR: SSL connection failed for '10.48.36.215': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

حيث تتم ترجمة c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw (base64) إلى steven.lab/https/10.48.36.215/8443، والذي يظهر أنه يجب أن يقوم بالاتصال نحو 10.48.36.215 كعنوان اتصال بدلا من cucm.steven.lab. كما هو موضح في حزم الالتقاط، لا تحتوي شهادة CUCM TOMCAT على عنوان IP في شبكة التخزين (SAN) ومن ثم يتم إلقاء الخطأ.

كيفية التحقق من صحتها بسهولة

يمكنك التحقق مما إذا كنت تريد تغيير هذا السلوك بسهولة باستخدام الخطوات التالية:

1. بدء التسجيل التشخيصي على خادم (خوادم) Expressway-E و C (نموذجيا مع تمكين TCPDumps) من الصيانة > التشخيصات > التسجيل التشخيصي (في حالة نظام مجموعة، يكون كافيا لتشغيله من العقدة الأساسية)

2. حاول تسجيل الدخول إلى MRA أو إختبار الوظيفة المعطلة بعد الترقية

3. انتظر حتى يفشل التسجيل التشخيصي على خادم (خوادم) Expressway-E و C ثم قم بإيقاف التسجيل التشخيصي (في حالة مجموعة، تأكد من جمع السجلات من كل عقدة من المجموعة بشكل فردي)

4. تحميل السجلات الموجودة على أداة محلل حلول التعاون وتحليلها

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

توقيع تشخيص CA

توقيع SNI التشخيصي

الحل

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

عند ملاحظة التحذير: فشل التحقق من شهادة الخادم الأساسي ل (<server-FQDN-or-IP>). الإجراء=End Error=Self Signed Certificate Server=cucm.steven.lab(10.48.36.215) depth=x message، ثم تحتاج إلى تحديث مخزن الثقة على خوادم Expressway-C وفقا لذلك. إما باستخدام سلسلة المرجع المصدق التي وقعت على هذه الشهادة (العمق > 0) أو باستخدام شهادة موقعة ذاتيا (العمق = 0) من الصيانة > التأمين > شهادة المرجع المصدق الثقة. تأكد من تنفيذ هذا الإجراء على كل خادم في نظام المجموعة. خيار آخر هو توقيع الشهادة عن بعد بواسطة مرجع مصدق معروف في مخزن ثقة Expressway-C.

ملاحظة: لا تسمح Expressway بتحميل شهادتين مختلفتين (موقعة ذاتيا على سبيل المثال) إلى مخزن الضمان ل Expressway لديهما نفس الاسم المشترك (CN) طبقا لمعرف تصحيح الأخطاء من Cisco CSCwa12905. لتصحيح هذا الأمر، قم بالانتقال إلى الشهادات الموقعة من CA أو ترقية CUCM إلى الإصدار 14 حيث يمكنك إعادة إستخدام نفس الشهادة (الموقعة ذاتيا) ل Tomcat و CallManager.

عندما تلاحظ التحذير: SNI (<server-FQDN-أو IP>) غير موجود في رسالة الشهادة، فإنه يشير إلى أن FQDN أو IP هذا الخادم غير موجود في الشهادة التي تم تقديمها. يمكنك إما تكييف الشهادة لتضمين هذه المعلومات أو يمكنك تعديل التكوين (مثل CUCM على النظام > الخادم إلى شيء موجود في شهادة الخادم) ثم تحديث التكوين على خادم Expressway-C حتى يتم وضعه في الاعتبار.

معلومات ذات صلة

الحل قصير الأجل هو تطبيق الحل كما هو موثق للرجوع إلى السلوك السابق قبل X14.2.0. يمكنك تنفيذ ذلك من خلال CLI (واجهة سطر الأوامر) على عقد خادم Expressway-C باستخدام الأمر الذي تم تقديمه حديثا:

xConfiguration EdgeConfigServer VerifyOriginServer: Off

تقنية المعلومات