المقدمة
يوضح هذا المستند كيفية الحصول على شهادة "وظيفة وكيل المرجع المصدق (CAPF)" موقعة من المرجع المصدق (CA) لبرنامج Cisco Unified Communications Manager (CUCM). توجد دائما طلبات لتوقيع CAPF مع CA الخارجي. يوضح هذا المستند سبب فهم كيفية عمله بنفس أهمية إجراء التكوين.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- البنية الأساسية للمفتاح العام (PKI)
- تكوين أمان CUCM
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى الإصدار 8.6 من Cisco Unified Communications Manager والإصدارات الأحدث.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
تحديد
قد يكون ل CA المختلف متطلبات مختلفة ل CSR. هناك تقارير تشير إلى أن إصدار مختلف من مرجع التحكم في الوصول ل OpenSSL يحتوي على بعض الأسئلة المحددة الخاصة ب CSR ومع ذلك يعمل Microsoft Windows CA بشكل جيد مع CSR من Cisco CAPF حتى الآن، وهو النقاش الذي لن تتم تغطيته في هذه المقالة.
المنتجات ذات الصلة
هذا وثيقة يستطيع أيضا كنت استعملت مع هذا جهاز وبرمجية صيغة:
- نظام التشغيل Microsoft Windows Server 2008 CA.
- Cisco Jabber ل Windows (قد يكون لأحرف مختلفة اسم مختلف للمجلد لتخزين LSC).
معلومات أساسية
الغرض من CA الموقع CAPF
يرغب بعض العملاء في التوافق مع نهج الشهادات العامة مع الشركة، لذا من الضروري توقيع CAPF مع CA نفسه كخوادم أخرى.
آلية هذا البكي
بشكل افتراضي، يتم توقيع الشهادة الهامة محليا (LSC) من قبل CAPF، لذلك فإن CAPF هي CA للهواتف في هذا السيناريو. ومع ذلك، عندما تحاول الحصول على CAPF موقع من المرجع المصدق الخارجي، فإن CAPF في هذا السيناريو يعمل كمرجع مصدق ثانوي أو مرجع مصدق متوسط.
الفرق بين CAPF الموقع ذاتيا و CAPF الموقع من CA هو: CAPF هو الجذر ل CA إلى LSC عند تنفيذ CAPF الموقع ذاتيا، CAPF هو التابع (الوسيط) CA إلى LSC عند تنفيذ CAPF الموقع من CA.
كيف يختلف CAPF CSR عن CSRs الأخرى؟
فيما يتعلق ب RFC5280، يحدد ملحق إستخدام المفتاح الغرض (على سبيل المثال، التشفير، التوقيع، توقيع الشهادة) من المفتاح الموجود في الشهادة. CAPF هو وكيل شهادة و CA ويمكنه توقيع شهادة إلى الهواتف ولكن الشهادة الأخرى مثل CallManager و Tomcat و IPSec تعمل كورقة (هوية المستخدم). عندما تنظر في CSR بالنسبة لهم، يمكنك أن ترى CAPF CSR لديه دور توقيع الشهادة وليس الآخرين.
CAPF CSR:
Attributes:
Requested Extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, IPSec End System
X509v3 Key Usage:
Digital Signature, Certificate Sign
تومكات سي آر إس:
Attributes:
Requested Extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
CallManager CSR:
Attributes:
Requested Extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
IPSec CSR:
السمات: الامتدادات المطلوبة: إستخدام المفتاح الموسع X509v3: مصادقة خادم ويب TLS، مصادقة عميل ويب TLS، إستخدام مفتاح النظام النهائي IPSec End System X509v3: التوقيع الرقمي، تشفير المفاتيح، تشفير البيانات، إتفاقية المفاتيح
التكوين
فيما يلي سيناريو واحد، يتم إستخدام المرجع المصدق الجذر الخارجي لتوقيع شهادة CAPF: لتشفير الإشارة/الوسائط لعميل Jabber وهاتف بروتوكول الإنترنت.
الخطوة 1. قم بإنشاء تجمع CUCM الخاص بك كمجموعة أمان.
admin:utils ctl set-cluster mixed-mode
الخطوة 2. كما هو موضح في الصورة، قم بإنشاء CAPF CSR.
الخطوة 3. وقع هذا مع CA (باستخدام القالب التابع في Windows 2008 CA).
ملاحظة: تحتاج إلى قالب مرجع التصديق التابع للمستخدم لتوقيع هذه الشهادة.
الخطوة 4. قم بتحميل المرجع المصدق الجذر ك CAPF-trust وشهادة الخادم ك CAPF. بالنسبة لهذا الاختبار، يرجى أيضا تحميل مرجع التحكم في الوصول الجذر هذا كثقة CallManager للحصول على اتصال TLS بين Jabber وخدمة CallManager لأن خدمة LSC الموقعة تحتاج إلى أن تكون موثوق بها بواسطة خدمة CallManager أيضا. كما هو مذكور في بداية هذه المقالة، هناك حاجة إلى محاذاة المرجع المصدق لجميع الخوادم، لذلك كان يجب تحميل هذا المرجع المصدق على CallManager بالفعل لتشفير الإشارات/الوسائط. بالنسبة إلى عملية نشر هاتف IP 802.1x، لا يجب عليك جعل CUCM كوضع مختلط أو تحميل CA الذي يوقع CAPF كثقة في خادم CUCM.
الخطوة 5. قم بإعادة تشغيل خدمة CAPF.
الخطوة 6. قم بإعادة تشغيل خدمات CallManager/TFTP في جميع الملاحظات.
الخطوة 7. وقع Jabber Softphone LSC.
الخطوة 8. قم بتمكين ملف تعريف الأمان ل Jabber Softphone.
الخطوة 9. يتم تنفيذ RTP الآمن الآن باسم:
التحقق من الصحة
قارن LSC عند إختيار CAPF ذاتيا و CAPF الموقع من CA:
كما يمكنك أن ترى من هذه الصور ل LSC، من وجهة نظر LSC، فإن CAPF هو المرجع المصدق الجذر عند إستخدام CAPF الموقع ذاتيا ولكن CAPF هو المرجع المصدق (الوسيط) الثانوي أثناء إستخدام CAPF الموقع من CA.
LSC عند توقيع CAPF ذاتيا
LSC عند CAPF الموقع من CA
تنبيه:
ال Jabber زبون LSC يظهر كامل شهادة سلسلة في هذا مثال مختلف من ال ip هاتف. نظرا لتصميم هواتف بروتوكول الإنترنت (IP) استنادا إلى معيار RFC 5280 (الإصدار 3.2. مسارات الاعتماد والثقة) ثم إن AKI (معرف مفتاح المرجع) مفقود، ثم CAPF وشهادة المرجع المصدق الجذر غير موجودين في سلسلة الشهادات. يؤدي فقد شهادة CAPF/Root CA في سلسلة الشهادات إلى حدوث بعض المشاكل في ISE لمصادقة هواتف IP أثناء مصادقة 801.x دون تحميل CAPF والشهادات الجذر إلى ISE. هناك خيار آخر في CUCM 12.5 مع LSC موقع من مرجع مصدق خارجي غير متصل مباشرة لذلك لا يلزم تحميل شهادة CAPF إلى ISE لمصادقة IP Phone 802.1x.
استكشاف الأخطاء وإصلاحها
لا تتوفر حاليًا معلومات محددة لاستكشاف الأخطاء وإصلاحها لهذا التكوين.
معلومات ذات صلة
العيب المعروف: شهادة CA الموقعة CAPF، يجب تحميل شهادة الجذر كثقة CM:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut87382/?referring_site=bugquickviewredir