قم بالتنقل في غروب شمس EKU الخاص بالعميل مع الطراز Expressway x15.5

المقدمة

يصف هذا المستند التنقل في غروب شمس EKU العميل باستخدام Cisco Expressway x15.5.

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

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

• يتم إستخدام EKU لمصادقة الخادم (id-kp-serverAuth عندما يقدم الخادم شهادته لإثبات الهوية.
• يتم إستخدام مصادقة العميل EKU (id-kp-clientAuth) في إتصالات TLS المتبادلة (mTLS) حيث يقوم كلا الطرفين بمصادقة بعضهما البعض.

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

تعريف المشكلة

تغيير سياسة برنامج جذر الكروم

واعتبارا من يونيو 2026، تقيد سياسة برنامج جذر كروم شهادات المرجع المصدق (CA) المتضمنة في مخزن جذر كروم، للتخلص التدريجي من الجذور متعددة الأغراض لمحاذاة كافة التدرجات الهرمية للبنية الأساسية للمفتاح العام (PKI) لخدمة حالات إستخدام مصادقة خادم TLS فقط.

المتطلبات الرئيسية للسياسات

• يجب أن تؤكد مراجع CA العامة إستخدام المفتاح الموسع (EKU) فقط لمصادقة الخادم (id-kp-serverAuth).
• يمنع تضمين EKU لمصادقة العميل في هذه الشهادات.
• لا مزيد من تراخيص CAs الجذر للاستخدام المختلط لشهادات TLS للخادم العام.
• الجدول الزمني للتنفيذ: يونيو 2026

الجدول الزمني للاستجابة للترخيص المصدق العام

• أكتوبر 2025: بدأ العديد من المرجع المصدق العام (DigiCert، Sectigo، SSL) في إصدار شهادات الخادم فقط بشكل افتراضي.
• مايو 2026: توقف خوادم CA العامة عن إصدار شهادات EKU لمصادقة العميل
• يونيو 2026: سياسة برنامج كروم روت تصبح فعالة تماما 

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

Expressway، الإصدار x15.5 مع حل

Expressway x15.5

يأتي 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 إستخدام مخزنين للشهادات على أساس الحاجة.

مثال:

• عند عمل Expressway كعميل أثناء مصافحة TLS، يتم تقديم شهادة العميل.
• عند عمل Expressway كخادم أثناء مصافحة TLS، يتم تقديم شهادة الخادم.

الترقية من X15.4 أو إصدار سابق إلى X15.5

عند إجراء ترقية، يتم نسخ شهادة الخادم من 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.5، تظهر بوابات شهادات الخادم والعميل على مسؤول الويب نفس الشهادة نظرا لنسخ شهادة الخادم من x15.4 إلى مخزن شهادات العميل على x15.5.

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

دليل ثابت/ثابت لنظام ملفات Expressway على x15.5:

فحص EKU X15.5 أثناء مصافحة TLS

في x15.5، تم إدخال أمر CLI جديد للتحقق من إستخدام المفتاح الموسع (EKU) أثناء مصافحة TLS. القيمة الافتراضية هي "تشغيل". مجموعة الأوامر صالحة على Expressway Core و Edge.

تقوم مجموعة الأوامر بتشغيل التحقق من جميع إتصالات SIP TLS الواردة في Expressway. (لوحة وصل العميل الواردة/الشهادة المقدمة). عند تشغيل "تشغيل"، يتحقق ذلك مما إذا كانت الشهادة المقدمة من قبل بادئ TLS تحتوي على EKU العميل في الشهادة أم لا. في حالة إيقاف التشغيل، يتم تجاوز التحقق؛ ومع ذلك، يتم التحقق من EKU للخادم إذا كان موجودا على الشهادة.

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

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

مخازن شهادات متعددة، سيناريوهات نشر متعددة

ونظرا لوجود مخزنين للشهادات على Expressway الآن، فهناك سيناريوهات متعددة لمخازن الشهادات.

الشرط 1: الترقية

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

الشرط 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 لا تعمل. يمكن أن تلجأ إلى المرجع المصدق الخاص.

 حالة الاختبار 1

• عندما يكون الشيك EKU "قيد التشغيل" على Expressway E  
• عندما يكون لشهادة العميل والخادم على Expressway Core EKU للخادم فقط
• حالة منطقة UC فاشلة

عند تشغيل التحقق من Expressway-Edge ExtendedKeyUse.

وضع التحقق من الاستخدام الموسع لشهادة SIP TLS ل XCONFIGURATION: تشغيل:

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

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

حالة الاختبار 2

• عند إيقاف تشغيل فحص EKU على Expressway E
• عندما يكون لشهادة العميل والخادم على Expressway Core خادم EKU فقط
• حالة منطقة الاتصالات الموحدة نشطة

إيقاف تشغيل تحقق EKU على Expressway E.

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

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

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

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

الشرط 2.1: حالة نجاح

CA 1 = CA داخلي

المرجع المصدق 2 = المرجع المصدق العام

• حيث يتم توقيع شهادة عميل Expressway الأساسية من قبل CA 1 (CA داخلي) وتتضمن كلا من EKU الخاص بالعميل/الخادم.
• يتم توقيع شهادة خادم Expressway الأساسية من قبل CA 2 العامة وتتضمن EKU للخادم فقط.
• يتم توقيع شهادة خادم Expressway Edge بواسطة CA 2 العامة وتتضمن EKU للخادم فقط.
• يتم توقيع شهادة عميل Expressway Edge بواسطة CA 2 العامة وتتضمن EKU للخادم فقط.

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

لا يهم ما إذا كان التحقق من EKU لحافة Expressway قيد الإيقاف أو قيد التشغيل. تحتوي شهادة عميل Expressway الأساسية على EKU العميل:

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

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

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

• تحتوي شهادة عميل Expressway-Core على EKU للخادم و EKU للعميل.
• تشتمل شهادة Expressway Core Server على Server EKU فقط.

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

الشرط 3: يوقع جميع الشهادات ذات المرجع المصدق الخاص

CA 1 = CA داخلي

المرجع المصدق 2 = المرجع المصدق العام

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

• عندما يرسل Expressway-E اتصال TLS، يلزم تبادل جذر/متوسط CA 1 مع كيان طرفي بعيد. إذا لم يكن للطرف البعيد قدرة أو لم يسمح بتحميل شهادة CA الخاصة، يكون اتصال TLS غير ناجح.
• يحصل عملاء MRA على شهادات لقبول الإطارات المنبثقة إذا لم تكن الشهادة الخاصة في مخزن ثقة OS.

الشرط 4: يحتوي Expressway Edge على شهادات عامة باستخدام EKU للخادم فقط

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

في الشرط 4، عند إجراء اتصال TLS إلى الطرف البعيد، إذا كان Expressway -E يرسل رسالة ترحيب عميل TLS، يجب على الطرف البعيد تعطيل التحقق من EKU للعميل (نظرا لأن شهادة العميل لا تحتوي على EKU لمصادقة العميل) وإلا فإن اتصال TLS غير ناجح.

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

• # إذا أصبح Expressway عميل أثناء مصافحة TLS، يتم تقديم شهادة العميل إلى النظراء.
• #إذا أصبح Expressway خادما أثناء مصافحة TLS؛ يتم تقديم شهادة الخادم إلى النظير.

وقد تم إثبات هذا المنطق مع حالات الاختبار هذه.

السيناريو 1

بالنسبة لهذا السيناريو، يقدم 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:

السيناريو 2

يصبح 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

• يرسل EXP C 16 رسالة ترحيب عميل على 6972 TFTP.
• يرسل EXP C 16 شهادة عميل أثناء مصافحة TLS.

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

محفوظات المراجعة

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