تعرف على متطلبات شهادة الوصول عن بعد والمتحرك ومحفوظات خادم حركة مرور Apache

المقدمة

يصف هذا المستند متطلبات تحميل الشهادة على CUCM للوصول المحمول والوصول عن بعد.

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

يستخدم Cisco Expressway خادم حركة مرور Apache (ATS). خادم حركة المرور مكون مهم جدا في حلول العبور، يستخدم بشكل أساسي لهذه الميزات:

• التحقق من الشهادة: وهو يجري التحقق من شهادة مدير الاتصالات الموحدة من Cisco (CUCM) والرسائل الفورية والحضور وعقد خادم الوحدة لخدمات MRA.
• التوكيل وذاكرة التخزين المؤقت: وهو يعمل كخادم وكيل تخزين مؤقت سريع وقابل للتطوير لحركة مرور بيانات HTTP/HTTPS.

على Expressway، الإصدار 14.0.2

يبدأ خادم حركة المرور (ATS) في رؤية تطبيق بسيط ل "التحقق من الشهادة" عند حديثه إلى CUCM أثناء تزويد MRA.

تم توثيق المتطلب بموجب CSCvz45074 حيث يجب تحميل الشهادات الجذر التي وقعت على شهادات خادم ExpressWay الأساسي، على CUCM ك Tomcat-Trust و CallManager Trust: https://cdetsng.cisco.com/summary/#/defect/CSCvz45074.

• يفرض خادم حركة المرور التحقق من الشهادة.
  
• قبل الترقية إلى إصدار X14.0.2، تأكد من استيفاء متطلبات الشهادة هذه.

المتطلب - يجب إضافة سلسلة المرجع المصدق (CA) (الجذر + الوسيط) التي وقعت على شهادة Expressway-C إلى قائمة الثقة المصدقة و CallManager-trust الخاصة ب CUCM، حتى إذا كان Unified Communications Manager (UCM) في وضع غير آمن.

السبب - ترسل خدمة خادم حركة مرور البيانات في Expressway شهادتها كلما طلبت منها إدارة الاتصالات الموحدة (UCM) الخاصة بالخادم. هذه الطلبات خاصة بالخدمات التي تعمل على منافذ أخرى غير 8443 (على سبيل المثال، المنافذ 6971 و 6972 وما إلى ذلك). وهذا يفرض التحقق من الشهادة حتى إذا كان UCM في وضع غير آمن. لمزيد من المعلومات، راجع Mobile Access و Remote Access من خلال دليل نشر Expressway.

السلوك على الإصدارات السابقة ل 14.0.8

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

كانت هناك أيضا مشكلة معروفة حيث لا يمكن تحميل شهادتين لهما نفس اسم CN على مخزن Expressway للثقة. تسبب هذا التقييد في مشكلتين:

1. إذا أخترت تحميل شهادة مدير المكالمات على مخزن Expressway Trust، فسيفشل التحقق من TLS "On" أثناء إضافة CUCMs.

2: إذا أخترت تحميل شهادة Tomcat على مخزن Expressway Trust، فسيفشل تسجيل SIP الآمن على 5061.

وثقت هذا تصرف في CSCwa12894.

أيضا، يتم إجراء التحقق من شهادة TLS هذا فقط عند اكتشاف خوادم CUCM/IM & P/Unity وليس في ذلك الوقت أثناء تزويد عميل MRA. 

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

السلوك على الإصدارات 14.0.8 والإصدارات الأحدث

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

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

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-0/mra/exwy_b_mra-deployment-guide-x150.pdf. 

قسم

متطلبات الشهادة > متطلبات تبادل الشهادات

ونظرا لهذه التغييرات في الطريقة التي يتم بها الاتصال بين Expressway-core و CUCM، يجب التأكد مما يلي:

1. توصي باستخدام الشهادات الموقعة من قبل CA للوصول الجوال والوصول عن بعد.

2. يجب أن تثق كل مجموعة CM موحدة بشهادة Expressway-C. بالنسبة لكل مجموعة، تأكد من:

• إذا تم تمكين الوضع المختلط — يجب تثبيت شهادة Expressway-C على مخزن CallManager-trust و Tomcat-trust على Unified CM.
• في حالة تعطيل الوضع المختلط — يجب تثبيت شهادة المرجع المصدق الجذر التي توقع على شهادة Expressway-C على مخزن CallManager للثقة و Tomcat للثقة على Unified CM. بعد ذلك، قم بإعادة تشغيل ما يلي: · خدمة Tomcat · خدمة CallManager · خدمة وكيل HA (في حالة إستخدام TLS على Tomcat).

على Expressway - Core، تأكد من إتخاذ هذه الإجراءات:

• يجب أن تثق Expressway-C بالشهادات المقدمة من كل من Unified CM و IM ومجموعة Presence Service.

يجب أن يتضمن مخزن الثقة الخاص ب Expressway-C شهادة المرجع المصدق الجذر التي توقع شهادات CM و IM الموحدة وخدمة التواجد لجميع مجموعات الاتصالات الموحدة.

السبب - ترسل خدمة خادم حركة مرور البيانات في Expressway شهادتها كلما طلب منها خادم (UCM). هذه الطلبات خاصة بالخدمات التي تعمل على منافذ أخرى غير 8443 (على سبيل المثال، المنافذ 6971 و 6972 وما إلى ذلك). وهذا يفرض التحقق من الشهادة حتى إذا كان UCM في وضع غير آمن.

تلعب طريقة إضافة عنوان CUCM تحت النظام > الخادم دورا مهما جدا في إضافة CUCM/IMP على Expressway Core تحت التكوين > الاتصالات الموحدة > خوادم CM الموحدة/IM وعقد خدمة التواجد.

يجب إضافة CUCM دائما باستخدام FQDN وليس اسم المضيف أو عنوان IP. في حال ملاحظة إضافة CUCM ضمن النظام > الخادم كعنوان IP/اسم المضيف

أثناء مصافحة TLS، سيفشل التحقق من TLS "تشغيل" ولن تتم إضافة مجموعة CUCM على Expressway-Core.

تظهر هذه الصورة CUCM الذي تمت إضافته كاسم المضيف:

يوضح هذا الشكل أن CUCM تمت إضافته على Expressway-Core باستخدام FQDN مع تحقق TLS في الوضع = على:

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

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

تظهر لقطة الشاشة التالية في تشفير ECDSA المعلن عنه بواسطة ExpressWay Core أثناء رسالة تفاوض TLS في Client Hello، '#if يتم إختيار TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384' بواسطة المستجيب البعيد (CUCM) في Hello على الخادم، ثم يفشل تفاوض TLS إذا:

شهادات CA الجذر أو شهادات ECDSA الفعلية من Responder، أي أن CUCM غير مثبت على مخزن Expressway Trust في هذه الحالة.

بدلا من ذلك، يمكنك أيضا تعديل شفرة Expressway بحيث لا تأخذ ECDSA الأولوية.

1. قم بتعديل تشفير SIP من خلال إلحاق سلسلة GCM-SHA384 المفتوحة ل SSL.

'ecdhe-rsa-aes256-gcm-sha384:eecdh:edh:high:.....:!MD5:!PSK:!eNULL:!aNULL:!aDH'

2. أضف + لنقل التشفير في التفضيل الأخير أو أضف ! لتعطيل ECDSA بشكل دائم.

التشفير: 'eecdh:edh:high:-AES256+SHA:!متوسط:!منخفض:!3des:!MD5:!psk:!eNULL:!aNULL:!aDH:+Ecdsa'

3. إضافة شهادة CA الجذر والمتوسط التي وقعت على شهادة ECDSA على CUCM أو إضافة شهادة TOMCAT-ECDSA على مخزن Expressway Trust (في بعض الحالات).

ومع ذلك، نظرا للتغيير في أسبقية التشفير، يمكن أن تنقطع عمليات نشر MRA بعد الترقية، لذا سيتعين على TAC تنفيذ الحل البديل المذكور آنفا لإعادة الأمور إلى العمل.

ومع إدخال نظام النقل 1.3، يصبح من الصعب أكثر التحقق من الشهادات التي يتم تبادلها في البريد الإلكتروني.

السلوك على الإصدارات x15.3

لواجهة SIP فقط، يمكنك إختيار أن يكون لديك شفرات RSA أو ECDSA.

تم فرض X15.x TLS 1.3. كما هو موضح في الحقل، يتم إختيار خوارزمية RSA غالبا عبر ECDSA. يمكن للعملاء الذين يقومون بالترقية إلى الإصدار x15.2 الآن الاختيار

بين خوارزمية RSA و ECDSA باستخدام مجموعة الأوامر هذه:

xConfiguration SIP المتقدم TLSsignatureAlgoPrefRsa: تشغيل/إيقاف تشغيل

سيعمل TlssignatureAlgoPrefRSA فقط إذا كانت واجهة SIP تحتوي على TLS 1.3

إصدارات SIP المتقدمة ل xConfiguration: 'TLSv1.3'

سيتم إرسال بدل التشفير أثناء "Client Hello" بواسطة Expressway إلى CUCM كما هو موضح عند إختيار RSA.

• خوارزمية التوقيع: rsa_pss_rsae_sha512 (0x0806)
• خوارزمية التوقيع: rsa_pss_rsae_sha384 (0x0805)
• خوارزمية التوقيع: rsa_pss_rsae_sha256 (0x0804)
• خوارزمية التوقيع: ecdsa_secp521r1_sha512 (0x0603)
• خوارزمية التوقيع: ecdsa_secp384r1_sha384 (0x0503)
• خوارزمية التوقيع: ecdsa_secp256r1_sha256 (0x0403)

سيعمل التكوين السابق بشكل مترادف على التكوين الذي إخترته على CUCM إلى شفرات TLS تحت معلمات المؤسسة > معلمات الأمان.

من المهم أيضا ملاحظة أنه أثناء عملية تأكيد اتصال TLS مقطوعة عبر TLS 1.3 بين Expressway-C و CUCM، فإن الأخطاء المطبوعة في سجلات التشخيص أو PCAP لا تساعد كثيرا. ويجدر تمكين هذه الأخطاء أثناء العمل باستخدام TAC، بحيث يطبع المكون أخطاء واضحة لاستكشاف الأخطاء وإصلاحها.

xConfiguration Logger Developer.TrafficServer.http مستوى: 'debug'
مطور مسجل التكوين xConfiguration.TrafficServer.http_trans level: 'debug'
مستوى Developer.TrafficServer.iocore لمسجل التكوين xConfiguration: 'debug'
مستوى Developer.TrafficServer.ssl لمسجل التكوين xConfiguration: 'debug'

ما يمكن توقعه عند مشاركة CallManager لشهادة واحدة مع خدمات متعددة

تتغير الأمور قليلا مع إعادة إستخدام شهادة على CUCM.

بدءا من CUCM 14.0، يمكنك إعادة إستخدام شهادات Tomcat و Tomcat ECDSA ك CallManager و CallManager ECDSA.

يمكن إعادة إستخدام شهادة Tomcat كشهادة CallManager.

يمكن إعادة إستخدام شهادة Tomcat-ECDSA كشهادة CallManager-ECDSA.

وهذا يجعل الحياة سهلة.

1. تستخدم الآن خدمات متعددة في CUCM شهادة واحدة، مما يخفض تكلفة الشهادة.

2 - إدارة أقل للشهادات.

3. إذا كنت بحاجة إلى تحميل شهادة Tomcat/CallManager أو Tomcat-ECDSA/CallManager-ECDSA (لأي سبب) على مخزن Expressway-Core الموثوق، فستكون مجرد شهادة واحدة تحتاج إلى تحميلها. لن تكون هناك مشكلة في وجود نفس إصدار اسم CN (تحدث سابقا في هذا المستند).

شهادات خادم Post Reuse و CallManager و CallManager ECDSA غير مرئية على مخزن ثقة CUCM. يمكنك التحقق من إعادة إستخدام الشهادة من CLI بتشغيل الأوامر:

إظهار جهة الاتصال الخاصة

عرض التومت الخاص

خطوات إعادة إستخدام الشهادة

إنشاء Tomcat CSR PUB.

تحميل شهادة CA التي ستوقع على شهادة Tomcat على CUCM كثقة Tomcat.

بمجرد توقيع شهادة Tomcat، قم بتحميلها على الناشر. قم بإعادة تشغيل الخدمات ذات الصلة عند طلبها.

بمجرد توقيع شهادة Tomcat، قم بتحميلها على الناشر. قم بإعادة تشغيل الخدمات ذات الصلة عند طلبها.

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

قم بإعادة تشغيل خدمة ويب Cisco Tomcat باستخدام CLI "إعادة تشغيل خدمة UTILS Cisco Tomcat" على جميع عقد نظام المجموعة (UCM/IMP). قم بإعادة تشغيل خدمات الويب Cisco UDS Tomcat و Cisco AXL Tomcat باستخدام CLI 'utils service restart cisco UDS Tomcat' و'utils service restart Cisco AXL Tomcat' على جميع عقد نظام المجموعة UCM. قم أيضا بإعادة تشغيل مدير Cisco DRF وخدمات Cisco DRF المحلية على عقدة الناشر. قم بإعادة تشغيل الخدمة المحلية ل Cisco DRF فقط على عقدة (عقد) المشترك.

شهادة Tomcat موقعة الآن من قبل CA.

لإعادة إستخدام شهادة Tomcat كشهادة CallManager الآن.

انقر على إعادة إستخدام الشهادة.

أختر Tomcat في القائمة المنسدلة وفحص شهادة CallManager.

انقر فوق إنهاء.

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

الرقم التسلسلي لشهادة CallManager (SN): 56:ff:6c:71:00:00:00:00:00:0d.

شهادة Tomcat SN: 56:ff:6c:71:00:00:00:00:00:0d.

قم بإجراء الخطوات نفسها على المشترك.

يتيح توقيع شهادة ECDSA الآن حتى يمكن إعادة إستخدامها ك CallManager-ECDSA.

شهادة Tomcat-ECDSA الحالية موقعة ذاتيا.

توقيع CSR متعدد المواقع لشهادة Tomcat-ECDSA.

توقيع الشهادة باستخدام CSR وتحميلها.

تم التحميل بنجاح. قم بإعادة تشغيل الخدمات ذات الصلة كما هو مطلوب.

Tomcat و Tomcat-ECDSA توقيع CA.

الآن أعد إستخدام شهادة Tomcat-ECDSA كشهادة CallManager-ECDSA.

تم التحميل بنجاح. قم بإعادة تشغيل الخدمات ذات الصلة عند طلبها.

التحقق من الشهادات من CLI.

CallManager-ECDSA Certificate SN: 2f:00:00:00:38:80:be:cc:a8:a1:8e:8f:23:00:00:00:00:00:38.

شهادة Tomcat-ECDSA SN: 2f:00:00:00:38:80:be:cc:a8:a1:8e:8f:23:00:00:00:00:00:38.

نظرا لأنك تستخدم الآن شهادة واحدة لخدمتين، أي شهادة Tomcat لخدمات Tomcat و CallManager، و Tomcat-ECDSA لخدمات Tomcat-ECDSA و CallManager-ECDSA، فقد أصبح تحميل الشهادات على مخزن Expressway Trust أقل إرهاقا (إذا لزم الأمر تحميل).

أصبحت إمكانية قيام TLS بالتحقق من "تشغيل" أثناء إضافة UCM على Expressway-core ل MRA، أكثر سهولة من ذي قبل. بمجرد إضافة مرجع مصدق واحد أو شهادة خادم للقيام بالمهمة (نظرا لمشاركة الشهادة الآن بين خدمة CallManager وخدمة Tomcat).

إذا أدت الترقية إلى X14.2 أو إصدار أحدث إلى انقطاع خدمة Mobile Remote Access، فيمكنك أيضا الرجوع إلى هذا المستند الشامل لاستكشاف الأخطاء وإصلاحها.

محفوظات إصدار خادم حركة مرور Apache

للتحقق من الإصدار الموجود على تسجيل دخول الخادم إلى الجذر والتشغيل ~ # /apache2/bin/httpd -v.

Expressway x8.11.4
إصدار الخادم: Apache/2.4.34 (Unix)
الخادم الذي تم إنشاؤه: 12 نوفمبر، 2018 م 7:04:23 م

Expressway x12.6

إصدار الخادم: Apache/2.4.43 (Unix)
الخادم الذي تم إنشاؤه: 26 مايو، 2020 م 18:27:21

Expressway x14.0.8

إصدار الخادم: Apache/2.4.53 (Unix)
الخادم الذي تم إنشاؤه: 4 مايو، 2022 م 8:52:57 م

Expressway x15.3

إصدار الخادم: Apache/2.4.62 (Unix)
الخادم الذي تم إنشاؤه: 16 يوليو، 2025 م 12:10:19 م

Expressway x15.4

إصدار الخادم: Apache/2.4.65 (Unix)
الخادم الذي تم إنشاؤه: 14 يناير، 2026 م 6:41:03 ص

Expressway x15.5

إصدار الخادم: Apache/2.4.66 (Unix)
الخادم الذي تم إنشاؤه: 16 مارس، 2026 م 3:57:19 م

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

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