يصف هذا المستند التنقل في غروب شمس EKU العميل باستخدام Cisco Expressway x15.5.
الشهادات الرقمية هي وثائق اعتماد إلكترونية تصدرها سلطات التصديق الموثوق بها (CAs) تؤمن الاتصال بين الخوادم والعملاء عن طريق ضمان المصادقة وسلامة البيانات والسرية. تحتوي هذه الشهادات على حقول إستخدام المفتاح الموسع (EKU) التي تحدد الغرض منها:
وبشكل تقليدي، يمكن أن تحتوي الشهادة المفردة على وحدات EKU الخاصة بمصادقة الخادم والعميل، مما يتيح إستخدامها في أغراض مزدوجة. وهذا مهم بشكل خاص لمنتجات مثل Cisco Expressway التي تعمل كخادم وعميل في سيناريوهات اتصال مختلفة.
واعتبارا من يونيو 2026، تقيد سياسة برنامج جذر كروم شهادات المرجع المصدق (CA) المتضمنة في مخزن جذر كروم، للتخلص التدريجي من الجذور متعددة الأغراض لمحاذاة كافة التدرجات الهرمية للبنية الأساسية للمفتاح العام (PKI) لخدمة حالات إستخدام مصادقة خادم TLS فقط.
ملاحظة: لا ينطبق هذا النهج إلا على الشهادات الصادرة عن المراجع المصدقة العامة. لا تتأثر PKI الخاص والشهادات الموقعة ذاتيا بهذا النهج.
إذا كنت مهتما بالقراءة حول تأثير غروب الشمس على EKU العميل على الطرق السريعة، ارجع إلى تحضير Expressway لمغروب شمس EKU الخاص بالعميل في شهادات CA العامة.
يأتي Expressway x15.5 مع حل مقترح لمشكلة تنشأ بسبب إغلاق زبون EKU من قبل جميع سلطات الشهادات العامة. هذه مشكلة عامة وتؤثر على كل الموردين/عمليات النشر الذين يختارون إستخدام شهادات PKI العامة.
يحتوي الإصدار x15.4، وهو إصدار سابق، على محول أوامر CLI (واجهة سطر الأوامر) الذي يسمح للمسؤول بتحميل شهادة EKU للخادم فقط (لا يوجد عميل EKU) على Expressway E.
شهادة xConfiguration XCP TLS CVS EnableServerEkuUpload: تشغيل
ملاحظة: يتم إهمال هذا الأمر في x15.5.
يحتوي الطراز x15.5 على مخزنين للشهادات:
1. مخزن شهادات الخادم
2. مخزن شهادات العميل
Expressway (بطاقة واجهة شبكة (NIC) واحدة أو بطاقة واجهة شبكة (NIC) مزدوجة): يمكن لكل من واجهات Expressway إستخدام مخزنين للشهادات على أساس الحاجة.
مثال:
ملاحظة: يستخدم كل من مخزن الشهادات (العميل والخادم) نفس مكتبة المرجع المصدق الموثوق به. تأكد من تحميل المرجع المصدق الذي وقع شهادات الخادم والعميل بشكل صحيح على مخزن التوثيق. تتضمن سجلات التشخيص الآن شهادة الخادم وشهادة العميل بتنسيق ملف PEM.

عند إجراء ترقية، يتم نسخ شهادة الخادم من x15.4 أو إصدار سابق، مخزن شهادات خادم Expressway إلى مخزن شهادات العميل على x15.5. تحتوي مخازن شهادات العميل والخادم على x15.5 على نفس الشهادة.
خادم Expressway على 15.4، ترخيص الخادم الحالي الرقم التسلسلي 46:df:76:aa:00:00:00:00:29
الشهادة:
الإصدار: 3 (0x2)
الرقم التسلسلي:
46:df:76:aa:00:00:00:00:00:29
صلاحية
ليس قبل: 14 مارس، 02:37:40 م 2026 م جرينتش
مش بعد : 14 مارس، 02:47:40 م 2028 م جرينتش
الموضوع: C = IN، ST = KA، L = KA، O = Cisco، Ou = TAc، CN = cluster.s.com
دليل ثابت/ثابت لنظام ملفات Expressway على x15.4:

قائمة Expressway (صيانة > تأمين > شهادة الخادم) على x15.4 (حقل شهادة الخادم فقط):

هنا، ترى خيارين للشهادة تحت الصيانة > التأمين > شهادة العميل وشهادات الخادم. بعد الترقية إلى x15.5، تظهر بوابات شهادات الخادم والعميل على مسؤول الويب نفس الشهادة نظرا لنسخ شهادة الخادم من x15.4 إلى مخزن شهادات العميل على x15.5.

تم نسخ الترقية اللاحقة إلى شهادة x15.5 الموجودة والمفتاح الخاص إلى مخزن شهادات العميل.
دليل ثابت/ثابت لنظام ملفات Expressway على x15.5:

في x15.5، تم إدخال أمر CLI جديد للتحقق من إستخدام المفتاح الموسع (EKU) أثناء مصافحة TLS. القيمة الافتراضية هي "تشغيل". مجموعة الأوامر صالحة على Expressway Core و Edge.
تقوم مجموعة الأوامر بتشغيل التحقق من جميع إتصالات SIP TLS الواردة في Expressway. (لوحة وصل العميل الواردة/الشهادة المقدمة). عند تشغيل "تشغيل"، يتحقق ذلك مما إذا كانت الشهادة المقدمة من قبل بادئ TLS تحتوي على EKU العميل في الشهادة أم لا. في حالة إيقاف التشغيل، يتم تجاوز التحقق؛ ومع ذلك، يتم التحقق من EKU للخادم إذا كان موجودا على الشهادة.
وضع التحقق من الاستخدام الموسع لشهادة SIP TLS ل XCONFIGURATION: تشغيل/إيقاف تشغيل:
ملاحظة: إذا قمت بإنشاء شهادة عميل، وتوقيع CSR لا تحتوي على EKU العميل (مثال على الشهادة العامة الموقعة CA)، فلن تتمكن من تحميل هذه الشهادة يدويا على مخزن شهادات العميل. لذلك، تحتاج إلى التأكد من أن الشهادات التي تم إنشاؤها عن طريق توقيع CSR تحتوي دائما على EKU العميل (يمكن إستخدام CA خاص لإدراج EKU العميل).
تلميح: يظهر هذا الخطأ عندما تحاول تحميل شهادة CSR موقعة، والتي تفتقد إلى EKU العميل، من مخزن شهادات العميل.

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

ونظرا لوجود مخزنين للشهادات على Expressway الآن، فهناك سيناريوهات متعددة لمخازن الشهادات.
الشرط 1: الترقية
عند ترقية Expressway من x15.4 أو قبل x15.5، يكون هذا الشرط صحيحا. يتم نسخ الشهادات الموجودة من إصدار x15.4 إلى مخزنين (2) للشهادات. في عميل وخادم X15.5، تكون الشهادات هي نفسها.

CA 1 = CA داخلي
المرجع المصدق 2 = المرجع المصدق العام
في الشكل الموضح بعد ذلك، يحتوي Expressway Core على شهادة عميل مع EKU للخادم موقعة من CA 2 فقط (CA عام) وشهادة خادم مع EKU للخادم موقعة من CA 2 فقط (CA عام). وبالمثل، فإن Expressway E لديه شهادة عميل مع EKU للخادم موقعة من CA2 (CA عام) وشهادة خادم مع EKU للخادم موقعة من CA 2 (CA عام) فقط.

إذا لم تكن شهادة خادم Expressway الأساسية تحتوي على EKU عميل، فإن منطقة تبادل الاتصالات الموحدة و MRA و WebRTC لا تعمل. تأكد من أن شهادة خادم Expressway Core تحتوي على EKU عميل. هذه حالة إستخدام شائع حيث يختار المستخدمون توقيع كل الشهادات من المرجع المصدق العام. بما أن المرجع المصدق العام لا يتضمن EKU العميل في الشهادات، فإن منطقة تبادل الاتصالات الموحدة تصبح نشطة.
لجعل منطقة الاتصالات الموحدة نشطة، هناك إصلاح سريع يتمثل في إيقاف تشغيل فحص EKU على Expressway E. وهذا يطرح منطقة الاتصالات الموحدة. ومع ذلك، تظل أنفاق SSH غير نشطة. واعتبارا من اليوم، يتطلب اتصال نفق SSH في عام 2222 التحقق من صحة وحدة المعالجة المركزية (EKU) العميلة.
تسجيل دخول عميل MRA ووظائف وكيل WebRTC لا تعمل. يمكن أن تلجأ إلى المرجع المصدق الخاص.
عند تشغيل التحقق من Expressway-Edge ExtendedKeyUse.
وضع التحقق من الاستخدام الموسع لشهادة SIP TLS ل XCONFIGURATION: تشغيل:

فشل منطقة الاتصال الموحد:

تظهر سجلات ExpressWay E أين يقع 10.106.80.16 = Expressway Core، 10.106.80.31 = Expressway Edge:

إيقاف تشغيل تحقق EKU على Expressway E.
وضع التحقق من الاستخدام الموسع لشهادة SIP TLS ل XCONFIGURATION: إيقاف تشغيل

منطقة الاتصالات الموحدة نشطة:

ومع ذلك، لا تزال أنفاق SSH معطلة:

سجلات أحداث Expressway:

CA 1 = CA داخلي
المرجع المصدق 2 = المرجع المصدق العام

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


أنفاق SSH على Expressway Core active:

أنفاق SSH على Expressway Edge النشطة:

حالة منطقة MRA للاتصالات الموحدة نشطة:


يقوم عميل MRA بتسجيل الدخول والتسجيل:

ملاحظة: قارن وأحيط علما بوحدات الطاقة الأحيائية الموجودة في شهادات MRA ووكيل WebRTC للعمل. إنها مقارنة بين النشر العملي وغير العملي.
CA 1 = CA داخلي
المرجع المصدق 2 = المرجع المصدق العام

في الشرط 3، يتم توقيع جميع الشهادات من قبل CA داخلي (CA1) .

في الشرط 4، يتم توقيع شهادات عميل Expressway الأساسي والخادم (CA1) الداخلية وتحتوي على كل من EKU الخاص بالعميل والخادم. شهادة خادم Expressway E هي CA العام الموقعة ولها EKU للخادم فقط. يتم نسخ شهادة الخادم إلى مخزن شهادات العميل الذي يختار تحميل ملف شهادة الخادم كشهادة عميل.
في الشرط 4، عند إجراء اتصال TLS إلى الطرف البعيد، إذا كان Expressway -E يرسل رسالة ترحيب عميل TLS، يجب على الطرف البعيد تعطيل التحقق من EKU للعميل (نظرا لأن شهادة العميل لا تحتوي على EKU لمصادقة العميل) وإلا فإن اتصال TLS غير ناجح.
يمكن أن يكون هناك العديد من الحالات أو السيناريوهات الأخرى في الميدان استنادا إلى حالات نشر المستخدمين واستخدامهم ولا يمكن تغطيتها جميعا بسبب محدودية دفق فكري. ولكن، النقاط التي يجب تذكرها هي:
وقد تم إثبات هذا المنطق مع حالات الاختبار هذه.
بالنسبة لهذا السيناريو، يقدم Expressway شهادة العميل أثناء مصافحة MTLS باستخدام Webex.
مكالمة فيديو لاجتماع Webex:
نموذج تدفق المكالمات Jabber -à CUCM -a EXP Core — a EXP Edge — على Webex
10.106.80.31= Expressway Edge
163.129.37.33 = Webex
2026-03-24T11:54:26.106+00:00 أجهزة TVCs الذكية: UTCTime="2026-03-24 11:54:26،106" module="network.sip" level="debug": الإجراء="Send" local-ip="10.106.80.31" local-port="25002" DST-IP="163.129.37.33" DST-port="5061"
يحتوي Expressway Edge على شهادة عميل بهذا الرقم التسلسلي (2f0000004 c869c77c8981becde0000004c).
يرسل Expressway Edge رسالة ترحيب بالعميل إلى 'Webex أثناء تفاوض TLS، ثم يرسل شهادة العميل.
الرقم التسلسلي 2f000004 c869c77c8981becde00000004c:
1. يرسل Expressway Edge رسالة ترحيب بالعميل (pkt= 13699) إلى 'Webex أثناء تفاوض mTLS.
2. يقوم Webex بإرسال ترحيب على الخادم إلى Expressway Edge (pkt=13701).
3. يرسل Webex شهادته إلى Expressway Edge (pkt=13711).
4. يطلب Webex شهادة Expressway Edge "CertificateRequest" (pkt=13715).
5. يرسل Expressway Edge شهادته إلى Webex (pkt=13718).
(لقطة شاشة)

شهادة العميل من Expressway Edge:

يصبح Expressway كيان الخادم أثناء مصافحة mTLS ويقدم شهادة الخادم الخاصة به:
حيث يعرض Expressway شهادة الخادم، يحتوي Expressway على منطقة مجاورة آمنة فوق 5061 مع التحقق من صحة الاسم.
المنطقة المجاورة الآمنة بين عقدة Expressway x15.5 وعقدة Expressway x8.11.4:
10.106.80.15 (x8.11.4) sends a client hello to 10.106.80.16 (x15.5) (pkt=736)
10.106.80.16 sends a server hello to 10.106.80.15 (pkt=738)
10.106.80.16 (x15.5) presents its server cert during TLS handshake (pkt=742) and requests client’s certificate ie 10.106.80.15 (x8.11.4)
10.106.80.15 (x8.11.4) sends client certificate (pkt=744)

توضح لقطة الشاشة هذه شهادة الخادم كمطابقة للرقم التسلسلي:

حالة الاختبار 3: يتم توفير عميل MRA لتسجيل الدخول، ويتضمن سير العمل التحقق من شهادة خادم حركة المرور بين Expressway Core و CUCM.
10.106.80.16 = Expressway Core x15.5
10.106.80.38 = CUCM

شهادة عميل Expressway الأساسية:

| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
15-Apr-2026
|
الإصدار الأولي |