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

المقدمة

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

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

المتطلبات

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

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

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

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

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

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

مع هذا التغيير في السلوك معلم ب cisco بق id CSCwc69661 أو Cisco بق id CSCwa25108 ، يقوم خادم حركة المرور على منصة Expressway بإجراء التحقق من شهادة Cisco Unified Communications Manager (CUCM) و Cisco Unified Instant Messaging & Presence (IM&P) وعقد خادم Unity لخدمات Mobile و Remote Access (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 وهكذا. حتى النهاية، CA الوسيط يحصل على شهادته مباشرة من المرجع المصدق الجذر:

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، يجب أن تكون قادرة على بناء سلسلة من الثقة من شهادة الخادم حتى شهادة مرجع مصدق رئيسي. لكي يحدث ذلك، تحتاج إلى تحميل شهادة CA الجذر وأيضا جميع شهادات CA الوسيطة (إذا كانت هناك أي شهادات CA، وهو ليس الحال إذا كان المرجع المصدق الجذر قد أصدر مباشرة شهادة خادم CUCM) في مخزن التوثيق الخاص ب Expressway-C.

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

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

فحص SAN أو CN

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

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

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

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

ومع ذلك، عندما لا تقوم بالاستعراض إلى Cisco.com ولكن بدلا من ذلك مباشرة إلى عنوان IP (عنوان الويب المرقم)، فإنه لا يعرض اتصالا آمنا لأنه لا يثق في المرجع المصدق الذي قام بتوقيعه. لا تحتوي الشهادة المقدمة على العنوان (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 server ضمن التكوين > الاتصالات الموحدة > خوادم 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 "وضع التحقق" معين إلى "نجاح" ولكن الاتصالات الفعلية من عملاء 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"

يشير خطأ التحقق من الشهادة وفشل التحقق من صحة تأكيد تأكيد TLS إلى حقيقة أن 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>). الإجراء=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=x، ثم تحتاج إلى تحديث مخزن التوثيق على خوادم Expressway-C وفقا لذلك. إما باستخدام سلسلة المرجع المصدق التي وقعت على هذه الشهادة (العمق > 0) أو باستخدام شهادة موقعة ذاتيا (العمق = 0) من الصيانة > التأمين > شهادة المرجع المصدق الثقة. تأكد من تنفيذ هذا الإجراء على كل خادم في نظام المجموعة. خيار آخر هو توقيع الشهادة عن بعد بواسطة مرجع مصدق معروف في مخزن ثقة Expressway-C.

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

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

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

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

xConfiguration EdgeConfigServer VerifyOriginServer: Off