المحتويات

المقدمة

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

المتطلبات

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

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

الهيئة العامة مقابل الخاصة للشهادة (CA)

كيفية عمل سلاسل الشهادات

ملخص مصافحة SSL

التكوين

منطقة تجارة / ائتمان Expressway-C و Expressway-E

GenerateandSign CSRs

قم بتكوين Expressway-C و Expressway-E للثقة في بعضها البعض

الاتصال الآمن بين Cisco Unified Communications Manager (CUCM) و Expressway-C

نظرة عامة

تكوين الثقة بين CUCM و Expressway-C

خوادم CUCM بشهادات موقعة ذاتيا

اعتبارات مجموعة Expressway-C و Expressway-E

شهادات نظام المجموعة

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

التحقق من الصحة

التحقق من معلومات الشهادة الحالية

قراءة/تصدير شهادة في Wireshark

استكشاف الأخطاء وإصلاحها

إختبار لمعرفة ما إذا كانت الشهادة موثوق بها على Expressway

نقاط النهاية الضوئية للتآزر (هواتف سلسلة 7800/8800)

موارد الفيديو

إنشاء CSR من أجل MRA أو طرق Expressway المجمعة

شهادة InstallServer إلى Expressway

كيفية تكوين ثقة الشهادة بين ExpressWay

المقدمة

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

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

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

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

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

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

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

هيئة الشهادة العامة مقابل الخاصة (CA)

هناك عدد من الخيارات لتوقيع الشهادات على خوادم Expressway-C و E. يمكنك إختيار توقيع طلب توقيع الشهادة (CSR) من قبل مرجع مصدق عام مثل GoDaddy أو Verisign أو آخرين، أو يمكنك توقيعه داخليا إذا كنت تستخدم مرجع الشهادات الخاص بك (يمكن أن تكون موقعة ذاتيا مع OpenSSL أو مرجع مصدق داخلي للمؤسسة مثل خادم Microsoft Windows).  لمزيد من المعلومات حول كيفية إنشاء وتوقيع CSRs المستخدمة من قبل أي من هذه الطرق، يرجى مراجعة دليل إنشاء شهادة Video Communication Server (VCS).

الخادم الوحيد المطلوب بالفعل توقيعه من قبل مرجع مصدق عام هو Expressway-E.  هذا هو الخادم الوحيد الذي يرى فيه العملاء الشهادة عند تسجيل الدخول عبر MRA، لذلك أستخدم مرجع مصدق عام للتأكد من عدم ضرورة قبول المستخدمين للشهادة يدويا.  يمكن أن يعمل Expressway-E بشهادة CA داخلية موقعة، لكن سيطلب من المستخدمين لأول مرة قبول الشهادة غير الموثوق بها. لن يعمل تسجيل MRA لهواتف السلسلتين 7800 و 8800 مع الشهادات الداخلية بسبب تعذر تعديل قائمة الشهادات الموثوق بها.  وللتبسيط، يقترح أن يتم توقيع كل من شهادات Expressway-C و Expressway-E من نفس CA؛ ومع ذلك، فهذا ليس متطلبا طالما أنك قمت بتكوين قوائم CA الموثوق بها بشكل صحيح على كلا الخادمين.

كيفية عمل سلاسل الشهادات

يتم ربط الشهادات معا في سلسلة مؤلفة من إثنين أو أكثر يتم إستخدامها للتحقق من المصدر الذي وقع شهادة الخادم.  توجد ثلاثة أنواع من الشهادات في سلسلة؛ شهادة العميل/الخادم، والشهادة الوسيطة (في بعض الحالات)، والشهادة الجذر (ويشار إليها أيضا باسم المرجع المصدق الجذري، حيث أن هذه هي أعلى سلطة من حيث المستوى وقعت على الشهادة).

تحتوي الشهادات على حقلين أساسيين لتكوين السلسلة؛ الموضوع، والمصدر.

الموضوع هو اسم الخادم أو السلطة التي تمثلها هذه الشهادة. وفي حالة أجهزة Expressway-C أو Expressway-E (أو غيرها من أجهزة الاتصالات الموحدة (UC)، يتم إنشاء ذلك من اسم المجال المؤهل بالكامل (FQDN).

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

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

ملخص مصافحة SSL

في حالة منطقة العبور، يعمل Expressway-C دائما كعميل بينما يكون Expressway-E هو الخادم دائما.  يعمل التبادل المبسط كما هو موضح:

Expressway-C Expressway-E

—Client Hello—>

<—Server Hello—

<—شهادة الخادم—

<—طلب الشهادة—

—شهادة العميل—>

المفتاح هنا في التبادل بما أن Expressway-C يباشر الاتصال دائما، وبالتالي يكون العميل دائما. ويعد Expressway-E أول من يرسل شهادته. إذا لم يتمكن Expressway-C من التحقق من هذه الشهادة، فإنه يخمد المصافحة ولا يمكنه إرسال مصافحته الخاصة إلى Expressway-E.

والشيء المهم الآخر الذي يجب ملاحظته هو مصادقة عميل ويب أمان طبقة النقل (TLS) وسمات مصادقة خادم ويب TLS على الشهادات. يتم تحديد هذه السمات على المرجع المصدق الذي قام بتوقيع CSR (في حالة إستخدام مرجع مصدق Windows، يتم تحديد ذلك بواسطة القالب المحدد)، وتشير إلى ما إذا كانت الشهادة صحيحة في دور العميل أو الخادم (أو كليهما).  نظرا لأنه بالنسبة إلى VCS أو Expressway، يمكن أن يعتمد على الحالة (تكون دائما هي نفسها لمنطقة العبور)، ويجب أن تحتوي الشهادة على سمات مصادقة العميل والخادم على حد سواء.

تعطي Expressway-C و Expressway-E خطأ عند التحميل إلى شهادة خادم جديدة، إذا لم يتم تطبيق كليهما.

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

مثال:

التكوين

منطقة تجارة / ائتمان Expressway-C و Expressway-E

إنشاء CSRs وتوقيعها

كما تمت الإشارة إليه مسبقا، يجب توقيع شهادات Expressway-C و Expressway-E إما من مرجع مصدق داخلي أو خارجي أو من OpenSSL للتوقيع الذاتي.

ملاحظة: لا يمكنك إستخدام الشهادة المؤقتة الواردة على خادم Expressway، لأنها غير معتمدة. إذا كنت تستخدم شهادات حرف البدل حيث يكون لديك شهادة توقيع CA ويكون سطر الموضوع غير محدد بشكل محدد، فإنه غير مدعوم.

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

Expressway-C

- تمت إضافة أي مجالات (داخلية أو خارجية) إلى قائمة المجالات.

- يتم إستبدال أي عقدة دردشة مستمرة إذا تم إستخدام إتحاد XMPP.

- أسماء ملفات تعريف الأجهزة الآمنة على CUCM في حالة إستخدام ملفات تعريف الأجهزة الآمنة.

Expressway-E

- أي مجالات تم تكوينها على Expressway-C.

- يتم إستبدال أي عقدة دردشة مستمرة إذا تم إستخدام إتحاد XMPP.

- أي مجالات تم الإعلان عنها لاتحادات XMPP.

ملاحظة: إذا لم يتم تضمين المجال الأساسي المستخدم لعمليات البحث عن سجل الخدمة الخارجي (SRV) كشبكة منطقة تخزين (SAN) في شهادة Expressway-E (إما xxx.com أو collab-edge.xxx.com)، فسيظل عملاء Jabber يطالبون المستخدم النهائي بقبول الشهادة في الاتصال الأول وسيفشل نقاط النهاية TC في الاتصال على الإطلاق.

قم بتكوين Expressway-C و Expressway-E للثقة في بعضها البعض

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

الشهادة 3

المصدر: GoDaddy Root CA

الموضوع: GoDaddy Root CA

الشهادة 2

المصدر: GoDaddy Root CA

الموضوع: سلطة GoDaddy الوسيطة

الشهادة 1

المصدر: سلطة GoDaddy الوسيطة

الموضوع: Expressway-E.lab

يلزم تكوين Expressway-C باستخدام شهادة الثقة 1. في معظم الحالات، بناء على الشهادات الموثوقة المطبقة على الخادم، فإنها ترسل فقط أقل شهادة خادم مستوى.  هذا يعني أنه لكي يتم تأمين Expressway-C للشهادة 1، يجب عليك تحميل كلا الشهادتين 2 و 3 إلى قائمة CA الموثوقة الخاصة ب Expressway-C (الصيانة> الأمان > قائمة CA الموثوقة).  إذا قمت بترك الشهادة الوسيطة 2 عند تلقي Expressway-C لشهادة Expressway-E، فلا يمكن أن تكون هناك طريقة لربطها ب GoDaddy Root CA، وبالتالي سيتم رفضها.

الشهادة 3

المصدر: GoDaddy Root CA

الموضوع: GoDaddy Root CA

الشهادة 1

المصدر: سلطة GoDaddy الوسيطة - غير موثوق بها!

الموضوع: Expressway-E.lab

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

الشهادة 2

المصدر: GoDaddy Root CA - غير موثوق به!

الموضوع: سلطة GoDaddy الوسيطة

الشهادة 1

المصدر: سلطة GoDaddy الوسيطة

الموضوع: Expressway-E.lab

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

الشهادة 3

المصدر: GoDaddy Root CA - الشهادة ذات التوقيع الذاتي من المستوى الأعلى موثوق بها وكاملة السلسلة!

الموضوع: GoDaddy Root CA

الشهادة 2

المصدر: GoDaddy Root CA

الموضوع: سلطة GoDaddy الوسيطة

الشهادة 1

المصدر: سلطة GoDaddy الوسيطة

الموضوع: Expressway-E.lab

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

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

الاتصال الآمن بين Cisco Unified Communications Manager (CUCM) و Expressway-C

نظرة عامة

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

هناك ميزتان رئيسيتان للأمان يمكن تمكينهما بين CUCM و Expressway-C، حيث يتحقق TLS من تسجيل الأجهزة ويضمن حدوثه.  هناك تمييز مهم بين هذين الشهادتين لأنهما تستخدمان شهادتين مختلفتين من جانب CUCM في مصافحة SSL.

التحقق من TLS - شهادة TOMCAT

تسجيلات SIP الآمنة - شهادة CallManager

تكوين الثقة بين CUCM و Expressway-C

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

أنت تحتاج أن يضمن أن Expressway-C يثق ال CA أن يوقع شهادات CUCM. ويمكن تحقيق ذلك إذا أضفتهم إلى قائمة المرجع المصدق الموثوق به.  في جميع الحالات تقريبا، إذا قمت بتوقيع شهادات CUCM باستخدام CA، يجب توقيع شهادات Tomcat و CallManager من نفس CA. إذا كانت مختلفة، تحتاج إلى الثقة في كليهما إذا كنت تستخدم TLS للتحقق من التسجيلات وتأمينها.

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

ملاحظة: عند إجراء مصافحة SSL بين CUCM و Expressway-C للتسجيل الآمن ل SIP، يتم مصافحتان. أولا، يعمل Expressway-C كعميل ويبدأ الاتصال ب CUCM. بمجرد اكتمال ذلك بنجاح، يقوم CUCM بتهيئة مصافحة أخرى كعميل للرد.  وهذا يعني أنه مثل Expressway-C، يجب أن تحتوي شهادة CallManager على CUCM على سمات مصادقة عميل ويب TLS وخادم ويب TLS.  الفرق هو أن CUCM يسمح بتحميل هذه الشهادات دون كليهما، وسوف تعمل التسجيلات الداخلية الآمنة بشكل جيد إذا كان CUCM لديه سمة مصادقة الخادم فقط. يمكنك تأكيد هذا على CUCM إذا قمت بالبحث عن شهادة CallManager في القائمة وحددها.  هناك، يمكنك النظر في معرفات الاستخدام تحت قسم الملحق. يمكنك الاطلاع على 1.3.6.1.5.7.3.2 لمصادقة العميل و 1.3.6.1.5.7.3.1 لمصادقة الخادم. يمكنك أيضا تنزيل الشهادة من هذا الإطار.

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

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

خوادم CUCM بشهادات موقعة ذاتيا

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

اعتبارات مجموعة Expressway-C و Expressway-E

شهادات نظام المجموعة

يوصى بشدة في حالة توفر مجموعة من خوادم Expressway-C أو Expressway-E للتكرار بإنشاء معدل تكرار دوري (CSR) منفصل لكل خادم وجعله موقعا من قبل مرجع مصدق. في السيناريو السابق، يكون الاسم الشائع (CN) لكل شهادة نظير هو نفس اسم المجال المؤهل بالكامل (FQDN) الخاص بالمجموعة، وتكون شبكات التخزين (SAN) هي FQDN الخاصة بالمجموعة و FQDN الخاصة بالأجهزة النظيرة كما هو موضح في الصورة:

من الممكن إستخدام FQDN الخاصة بالمجموعة كشبكة CN، ويقارن كل من FQDN ومجموعة FQDN في شبكة منطقة التخزين (SAN) لاستخدام نفس الشهادة لجميع العقد في المجموعة، وبالتالي تجنب تكلفة الشهادات المتعددة الموقعة من قبل مرجع مصدق عام.

ملاحظة: أسماء ملفات تعريف أمان الهاتف في شهادة CS مطلوبة فقط في حالة إستخدام ملفات تعريف أمان الهاتف الآمنة في UCM. المجال الخارجي أو collab-edge.example.com (حيث example.com هو المجال الخاص بك) هو أحد متطلبات تسجيل نقطة نهاية IP Phone و TC عبر MRA فقط. هذا إختياري لتسجيل Jabber عبر MRA. إذا لم يكن موجودا، فسيطلب Jabber قبول الشهادة عند تسجيل دخول Jabber عبر MRA.

إذا كان ذلك ضروريا للغاية، يمكن القيام بذلك باستخدام العملية التالية أو يمكنك إستخدام OpenSSL لإنشاء كل من المفتاح الخاص و CSR يدويا:

الخطوة 1. قم بإنشاء CSR في المجموعة الأساسية وقم بتكوينها لتسرد الاسم المستعار للمجموعة باسم CN. أضف كافة النظراء في المجموعة كأسماء بديلة، بالإضافة إلى جميع شبكات التخزين (SAN) المطلوبة الأخرى.

الخطوة 2. وقع على CSR هذا وقم بتحميله إلى النظير الأساسي.

الخطوة 3. سجل الدخول إلى الأساسي كجذر وقم بتنزيل المفتاح الخاص الموجود في /Tandberg/persistent/certs.

الخطوة 4. قم بتحميل كل من الشهادة الموقعة والمفتاح الخاص المتطابق لكل نظير في المجموعة.

ملاحظة: لا يوصى بذلك للأسباب التالية:

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

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

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

على عكس مشتركي CUCM في مجموعة، لا يتم نسخ قائمة CA الموثوقة من نظير إلى آخر في Expressway أو مجموعة VCS.  وهذا يعني أنه إذا كان لديك نظام مجموعة، فأنت بحاجة إلى تحميل الشهادات الموثوقة يدويا إلى قائمة المرجع المصدق على كل نظير.

التحقق من الصحة

استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.

التحقق من معلومات الشهادة الحالية

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

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

قراءة/تصدير شهادة في Wireshark

إذا كان لديك التقاط Wireshark لمصافحة SSL التي تتضمن تبادل الشهادات، يمكن ل Wireshark فك ترميز الشهادة لك، ويمكنك تصدير أي شهادات في السلسلة (إذا تم تبادل السلسلة الكاملة) من الداخل.  قم بتصفية التقاط الحزمة لمنفذ محدد من تبادل الشهادات (بشكل عام 7001 في حالة منطقة العبور).  بعد ذلك، إذا لم ترى حزم ترحيب العميل والخادم مع مصافحة SSL، فانقر بزر الماوس الأيمن فوق إحدى الحزم في تدفق TCP وحدد فك التشفير باسم.  هنا، حدد SSL وانقر فوق تطبيق.  الآن، إذا كنت قد التقطت حركة المرور الصحيحة، يجب أن ترى تبادل الشهادات.  ابحث عن الحزمة من الخادم الصحيح الذي يحتوي على الشهادة في الحمولة.  قم بتمديد قسم SSL في الجزء السفلي حتى ترى قائمة الشهادات كما هو موضح في الصورة:

هنا يمكنك توسيع أي من الشهادات لترى كل التفاصيل.  إذا كنت تريد تصدير الشهادة، انقر بزر الماوس الأيمن على الشهادة المرغوبة في السلسلة (إذا كان هناك متعدد) وحدد تصدير وحدات بايت الحزم المحددة.  أدخل اسما للشهادة وانقر على حفظ.  الآن، يجب أن تكون قادرا على فتح الشهادة في "عارض شهادات Windows" (إذا أعطيتها ملحق .cer)، أو تحميلها إلى أي أدوات أخرى للتحليل.

استكشاف الأخطاء وإصلاحها

يوفر هذا القسم المعلومات التي يمكنك إستخدامها لاستكشاف أخطاء التكوين وإصلاحها.

إختبار لمعرفة ما إذا كانت الشهادة موثوق بها على Expressway

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

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

نقاط النهاية الضوئية للتآزر (هواتف سلسلة 7800/8800)

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

ملاحظة: تبين لبعض عمليات النشر أن إستخدام جهاز مثل Citrix NetScaler مع CA من القائمة المضمنة في سلسلة 7800/8800 من الهواتف يمكن أن يتم تسجيله عبر MRA حتى إذا كانت Expressway-E تستخدم مرجع مصدق داخلي. يجب تحميل المرجع المصدق الجذر ل NetScalers إلى Expressway-E، ويلزم تحميل المرجع المصدق الجذر الداخلي إلى NetScaler لكي تعمل مصادقة SSL. وقد ثبت أن هذا هو العمل، وهو دعم يبذل قصارى جهده.

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

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

ملاحظة: لا يدعم VCS أو Expressway أكثر من 999 حرفا في حقل شبكة منطقة التخزين (SAN) في الشهادة. سيتم تجاهل أي شبكات تخزين (SAN) تتجاوز هذا الحد (والذي يتطلب العديد من الأسماء البديلة) كما لو أنها غير موجودة.

موارد الفيديو

يوفر هذا القسم معلومات في الفيديو يمكن أن ترشدك خلال كل عمليات تكوين الشهادة.

إنشاء CSR من أجل MRA أو طرق Expressway المجمعة

تثبيت شهادة الخادم على Expressway

كيفية تكوين ثقة الشهادة بين ExpressWay