تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يوضح هذا المستند كيفية تثبيت شهادة ذات قيمة محلية (LSC) على هاتف بروتوكول الإنترنت (هاتف بروتوكول الإنترنت من Cisco).
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
تستند المعلومات الواردة في هذا المستند إلى إصدارات CUCM التي تدعم SBD، وهي CUCM 8.0(1) وما فوقها.
ملاحظة: يتعلق فقط بالهواتف التي تدعم الأمان بشكل افتراضي (SBD). على سبيل المثال، هواتف 7940 و 7960 لا تدعم هواتف SBD، ولا هواتف المؤتمرات 7935 و 7936 و 7937. للحصول على قائمة بالأجهزة التي تدعم SBD في إصدارك من CUCM، انتقل إلى Cisco Unified Reporting > System Reports (تقارير النظام) > قائمة ميزات هاتف CM الموحد وقم بتشغيل تقرير عن الميزة: الأمان بشكل افتراضي.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
تعمل خدمة وظيفة وكيل السلطة (CAPF) من Cisco فقط على عقدة الناشر. يعمل الناشر كمرجع للشهادة (CA) أو موقع LSC.
إذا كنت تستخدم المصادقة المستندة إلى الشهادة ل 802.1X أو AnyConnect Phone VPN، فمن المهم فهم الفرق بين بطاقات MIC و LSCs.
يأتي كل هاتف من Cisco مزودا بميكروفون مثبت مسبقا في المصنع. يتم توقيع هذه الشهادة بواسطة إحدى شهادات Cisco Manufacturing CA، إما بواسطة شهادة Cisco Manufacturing CA أو Cisco Manufacturing CA SHA2 أو CAP-RTP-001 أو CAP-RTP-002. عندما يقدم الهاتف هذه الشهادة، فإنه يثبت أنه هاتف Cisco صالح، ولكن هذا لا يثبت أن الهاتف ينتمي إلى عميل معين أو مجموعة CUCM. من المحتمل أن يكون هاتفا مخادعا تم شراؤه من السوق المفتوح أو تم جلبه من موقع مختلف.
ومن ناحية أخرى، يتم تثبيت قوائم التحكم في الوصول الخاصة بالمنفذ (LSC) عمدا على الهواتف بواسطة مسؤول، ويتم توقيعها بواسطة شهادة CAPF الخاصة بناشر CUCM. أنت شكلت 802.1X أو AnyConnect VPN أن يثق فقط LSCs يصدر من قبل يعرف CAPF شهادة مرجع. يوفر لك إنشاء مصادقة الشهادة على بطاقات LSCs بدلا من بطاقات MIC تحكما أكثر دقة بكثير حول أي أجهزة الهاتف موثوق بها.
تم إستخدام خوادم CUCM lab هذه لهذا المستند:
تحقق من عدم انتهاء صلاحية شهادة CAPF، أو أنها على وشك الانتهاء في المستقبل القريب. انتقل إلى إدارة نظام التشغيل الموحدة من Cisco > الأمان > إدارة الشهادات، ثم ابحث عن قائمة الشهادات حيث تكون الشهادة CAPF بالضبط كما هو موضح في الصورة.
انقر على اسم عام لفتح صفحة تفاصيل الشهادة. تحقق من الصحة من: وإلى: التواريخ في جزء بيانات ملف الشهادة لتحديد وقت انتهاء صلاحية الشهادة، كما هو موضح في الصورة.
إذا انتهت صلاحية شهادة CAPF أو توشك على الانتهاء، أعد إنشاء هذه الشهادة. لا تتحرك للأمام مع عملية تثبيت LSC بشهادة CAPF منتهية الصلاحية أو ستنتهي صلاحيتها قريبا. يتجنب هذا الحاجة إلى إعادة إصدار قوائم التحكم في الوصول (LSCs) في المستقبل القريب بسبب انتهاء صلاحية شهادة CAPF. للحصول على معلومات حول كيفية إعادة إنشاء شهادة CAPF، راجع مقالة تجديد/عملية تجديد/شهادة CUCM.
وبالمثل، إذا كنت بحاجة إلى توقيع شهادة CAPF الخاصة بك من قبل جهة خارجية، فلديك خيار في هذه المرحلة. قم إما بإكمال إنشاء ملف طلب توقيع الشهادة (CSR) واستيراد شهادة CAPF الموقعة الآن، أو واصل التكوين باستخدام LSC موقعة ذاتيا لإجراء إختبار أولي. إذا احتجت إلى شهادة CAPF موقعة من طرف ثالث، فمن المعقول بشكل عام تكوين هذه الميزة أولا باستخدام شهادة CAPF موقعة ذاتيا، والاختبار والتحقق، ثم إعادة نشر قوائم التحكم في الوصول الخاصة (LSCs) الموقعة من قبل شهادة CAPF موقعة من طرف ثالث. يؤدي هذا إلى تبسيط عملية أستكشاف الأخطاء وإصلاحها لاحقا، في حالة فشل الاختبارات التي تم إجراؤها باستخدام شهادة CAPF الموقعة من قبل الطرف الثالث.
تحذير: إذا قمت بإعادة إنشاء شهادة CAPF أو إستيراد شهادة CAPF موقعة من طرف خارجي أثناء تنشيط خدمة CAPF وبدء تشغيلها، فإنه يتم إعادة ضبط الهواتف تلقائيا بواسطة CUCM. أكمل هذه الإجراءات في نافذة صيانة عندما يكون من المقبول إعادة تعيين الهواتف. للمرجع، راجع معرف تصحيح الأخطاء من Cisco CSCue55353 - إضافة تحذير عند إعادة إنشاء شهادة TVS/CCM/CAPF التي تعيد ضبط الهواتف
ملاحظة: إذا كان إصدار CUCM الخاص بك يدعم SBD، فإن إجراء تثبيت LSC هذا يطبق بغض النظر عن ما إذا كان مجموعة CUCM الخاصة بك معينة إلى الوضع المختلط أو لا. SBD هو جزء من CUCM الإصدار 8.0(1) والإصدارات اللاحقة. في هذه الإصدارات من CUCM، تحتوي ملفات ITL على شهادة خدمة CAPF في ناشر CUCM. وهذا يسمح للهواتف بالاتصال بخدمة CAPF لدعم عمليات الشهادات مثل "التثبيت/الترقية" واستكشاف الأخطاء وإصلاحها.
في الإصدارات السابقة من CUCM، كان من الضروري تكوين نظام المجموعة للوضع المختلط لدعم عمليات الشهادات. ونظرا لأن هذا لم يعد ضروريا، فإن ذلك يقلل من الحواجز التي تعترض إستخدام قوائم التحكم في الوصول إلى الشبكة (LSCs) كشهادات هوية هاتف لمصادقة 802.1X أو لمصادقة عميل AnyConnect VPN.
قم بتشغيل الأمر show itl على جميع خوادم TFTP في مجموعة CUCM. لاحظ أن ملف ITL يحتوي على شهادة CAPF.
على سبيل المثال، هنا مقتطف من إخراج show itl من مشترك CUCM في المختبر AO115sub.
ملاحظة: يوجد إدخال سجل ITL في هذا الملف بوظيفة CAPF.
ملاحظة: إذا لم يكن لملف ITL الخاص بك إدخال CAPF، فقم بتسجيل الدخول إلى ناشر CUCM وتأكيد تنشيط خدمة CAPF. لتأكيد هذا، انتقل إلى Cisco Unified ServiceAbility > Tools > Service Activation (تنشيط الخدمة) > CUCM Publisher > Security، ثم قم بتنشيط خدمة وظيفة وكيل مرجع شهادات Cisco. إذا تم إلغاء تنشيط الخدمة وقمت بتنشيطها فقط، فانتقل إلى Cisco Unified ServiceAbility > Tools > Control Center - Feature Services > Server > CM Services، ثم أعد تشغيل خدمة Cisco TFTP على جميع خوادم TFTP في مجموعة CUCM لإعادة إنشاء ملف ITL. أيضا، ضمنت أن أنت لا يضرب cisco بق id CSCuj78330.
ملاحظة: بعد الانتهاء، قم بتشغيل الأمر show itl على جميع خوادم TFTP في مجموعة CUCM للتحقق من تضمين شهادة CAPF الخاصة بناشر CUCM حاليا في الملف.
ITL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 727
2 DNSNAME 2
3 SUBJECTNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 64:F2:FE:61:3B:79:C5:D3:62:E2:6D:AB:4A:8B:76:1B
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C3 E6 97 D0 8A E1 0B F2 31 EC ED 20 EC C5 BC 0F 83 BC BC 5E
12 HASH ALGORITHM 1 null
ITL Record #:2
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 6B:99:31:15:D1:55:5E:75:9C:42:8A:CE:F2:7E:EA:E8
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 05 9A DE 20 14 55 23 2D 08 20 31 4E B5 9C E9 FE BD 2D 55 87
12 HASH ALGORITHM 1 null
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1680
2 DNSNAME 2
3 SUBJECTNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 51:BB:2F:1C:EE:80:02:16:62:69:51:9A:14:F6:03:7E
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 963 DF 98 C1 DB E0 61 02 1C 10 18 D8 BA F7 1B 2C AB 4C F8 C9 D5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.
ITL Record #:4
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 65:E5:10:72:E7:F8:77:DA:F1:34:D5:E3:5A:E0:17:41
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 00 44 54 42 B4 8B 26 24 F3 64 3E 57 8D 0E 5F B0 8B 79 3B BF
12 HASH ALGORITHM 1 null
ITL Record #:5
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
This etoken was used to sign the ITL file.
ITL Record #:6
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
ITL Record #:7
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1031
2 DNSNAME 9 ao115sub
3 SUBJECTNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 53:CC:1D:87:BA:6A:28:BD:DA:22:B2:49:56:8B:51:6C
7 PUBLICKEY 97
8 SIGNATURE 103
9 CERTIFICATE 651 E0 CF 8A B3 4F 79 CE 93 03 72 C3 7A 3F CF AE C3 3E DE 64 C5 (SHA1 Hash HEX)
The ITL file was verified successfully.
مع تأكيد إدخال CAPF كإدخال في ITL، يمكنك إكمال عملية شهادة على الهاتف. في هذا المثال، يتم تثبيت شهادة RSA من نوع 2048 بت باستخدام مصادقة السلسلة الفارغة.
على الهاتف، تحقق من عدم تثبيت LSC بعد كما هو موضح في الصورة. على سبيل المثال، على هاتف من السلسلة 79xx، انتقل إلى الإعدادات > 4 - تكوين الأمان > 4 - LSC.
افتح صفحة تكوين الهاتف لهاتفك. انتقل إلى إدارة Cisco Unified CM > Device > Phone.
أدخل هذه التفاصيل إلى قسم معلومات CAPF في تكوين الهاتف، كما هو موضح في الصورة:
احفظ تغييرات التكوين، ثم قم بتطبيق التكوين.
تتغير حالة LSC على الهاتف إلى معلق كما هو موضح في الصورة.
يولد الهاتف المفاتيح كما هو موضح في الصورة.
تقوم بإعادة ضبط الهاتف، وعندما تكتمل إعادة التعيين، تتغير حالة LSC للهاتف إلى مثبتة كما هو موضح في الصورة.
وهذا يظهر أيضا تحت رسائل الحالة في الهاتف كما هو موضح في الصورة.
استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.
للتحقق من تثبيت شهادة LSC على هواتف متعددة، ارجع إلى قسم إنشاء تقرير CAPF في دليل الأمان ل Cisco Unified Communications Manager، الإصدار 11.0(1). بدلا من ذلك، يمكنك عرض نفس البيانات ضمن واجهة ويب إدارة CUCM باستخدام إجراء البحث عن الهواتف حسب حالة LSC أو إجراء سلسلة المصادقة.
للحصول على نسخ من شهادات LSC المثبتة في الهواتف، ارجع إلى كيفية إسترداد الشهادات من مقالة صوت Cisco IP.
أستخدم هذا القسم لتحميل LCS بشكل مجمع إلى هواتف الطراز نفسه.
عند إستخدام الإدارة المجمعة وتحديد وضع المصادقة، يجب أن يتطابق وضع المصادقة مع عملية ملف تعريف أمان الهاتف. إذا كان هناك عدم تطابق، على سبيل المثال، حسب سلسلة فارغة بكميات كبيرة وحسب الشهادة الموجودة (أسبقية على LSC) في ملف تعريف أمان الهاتف، لا يمكن إكمال العملية.
تحقق من ملف تعريف أمان الهاتف ووضع المصادقة لتتحمل أنك تستخدم الوضع الصحيح.
لتعيين التكوين المجمع، في القائمة المنسدلة، حدد وضع المصادقة الذي يطابق ملف تعريف أمان الهاتف.
إذا قمت بتغيير وضع مصادقة ملف تعريف أمان الهاتف، فأنت بحاجة إلى الحفظ، ثم قم بتطبيق التكوين. قد يؤدي ذلك إلى إعادة تشغيل هذه الأجهزة التي تستخدم ملف تعريف أمان الهاتف المحدد.
يوفر هذا القسم معلومات يمكنك إستخدامها لاستكشاف أخطاء التكوين وإصلاحها.
فشل تثبيت LSC. تظهر رسائل حالة الهاتف "لا يوجد خادم CAPF صالح". وهذا يشير إلى عدم وجود إدخال CAPF في ملف ITL. تحقق من تنشيط خدمة CAPF، ثم أعد تشغيل خدمة TFTP. تحقق من أن ملف ITL يحتوي على شهادة CAPF بعد إعادة التشغيل، ثم أعد تعيين الهاتف لالتقاط أحدث ملف ITL، ثم أعد محاولة إجراء عملية الشهادة. إذا عرض إدخال خادم CAPF في قائمة إعدادات الأمان للهاتف كاسم المضيف أو اسم المجال المؤهل بالكامل، فأكد أن الهاتف قادر على حل الإدخال إلى عنوان IP.
فشل تثبيت LSC. تظهر رسائل حالة الهاتف "LSC: فشل الاتصال". يمكن أن يشير ذلك إلى أحد الشروط التالية:
تحقق من تنشيط خدمة CAPF، ثم أعد تشغيل خدمة CAPF، وأعد تشغيل خدمات TFTP من حيث بدء التشغيل، وأعد ضبط الهاتف لالتقاط أحدث ملف ITL، ثم أعد محاولة إجراء عملية الشهادة. إذا إستمرت المشكلة، فعليك التقاط حزمة من الهاتف وناشر CUCM وتحليلها لمعرفة ما إذا كان هناك اتصال ثنائي الإتجاه على المنفذ 3804، وهو منفذ خدمة CAPF الافتراضي. إذا لم تكن هناك شبكة مشكلة.
فشل تثبيت LSC. تظهر رسائل حالة الهاتف "LSC: Failed". تظهر صفحة ويب تكوين الهاتف "حالة عملية الشهادة: فشلت الترقية: تأخر المستخدم في بدء الطلب/النشر". يشير ذلك إلى أن العملية تنتهي حسب الوقت والتاريخ أو أنها انتهت في الماضي. أدخل تاريخا وساعة على الأقل في المستقبل، ثم أعد محاولة إجراء عملية الشهادة.
فشل تثبيت LSC. تظهر رسائل حالة الهاتف "LSC: فشل الاتصال". تظهر صفحة تكوين الهاتف "حالة عملية الشهادة: العملية معلقة". هناك أسباب مختلفة يمكن للمرء أن يرى حالة عملية الشهادة: حالة العملية المعلقة. ومن بين هذه الأسباب ما يلي:
للسيناريو الأخير، يتم إعداد بيئة معملية لمحاكاة ما ستراه في السجلات إذا لم يتمكن الهاتف من حل FQDN الخاص ب CUCM. حاليا، يتم إعداد المختبر مع هذه الخوادم:
للاختبار، لا يوجد إدخال DNS لخادم PUB11 CUCM الذي تم تكوينه.
حاولت دفع LSC إلى واحد من الهواتف (8845) في المختبر. راجع أنه لا يزال يظهر حالة عملية الشهادة: العملية معلقة.
في سجلات وحدة التحكم في الهاتف، راجع أن الهاتف يحاول الاستعلام عن ذاكرة التخزين المؤقت المحلية (127.0.0.1)، قبل إعادة توجيه الاستعلام إلى عنوان خادم DNS الذي تم تكوينه.
0475 INF Mar 12 15:07:53.686410 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0476 INF Mar 12 15:07:53.686450 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0477 INF Mar 12 15:07:53.694909 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0478 INF Mar 12 15:07:53.695263 dnsmasq[12864]: reply PUB11.brianw2.lab is NXDOMAIN-IPv4
0479 INF Mar 12 15:07:53.695833 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0480 INF Mar 12 15:07:53.695865 dnsmasq[12864]: cached PUB11.brianw2.lab is NXDOMAIN-IPv4
0481 WRN Mar 12 15:07:53.697091 (12905:13036) JAVA-configmgr MQThread|NetUtil.traceIPv4DNSErrors:? - DNS unknown IPv4 host PUB11.brianw2.lab
++ However, we see that the phone is not able to resolve the FQDN of the CUCM Publisher. This is because we need to configure the DNS entry for PUB11 on our DNS server.
0482 ERR Mar 12 15:07:53.697267 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Failed to resolve Tvs Ipv4 Address with hostname PUB11.brianw2.lab
++ Afterwards, we see the CAPF operation fail. This is expected because we do not have a DNS mapping for PUB11.
0632 NOT Mar 12 15:07:55.760715 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty:? - CertificateProperty.setCertificate() authMode=CAPF_AUTH_MODE_NULL_STR authorizationString=null theReason=CAPF_REASON_AUTO
0633 NOT Mar 12 15:07:55.761649 (322:17812) SECUREAPP-RCAPF_START_MODE: Start CAPF - mode:[1]([NULL_STR]), reason:[1]([AUTO]) no auth-str
0634 NOT Mar 12 15:07:55.761749 (322:17812) SECUREAPP-CAPF_CLNT_INIT:CAPF clnt initialized
0635 NOT Mar 12 15:07:55.761808 (322:17812) SECUREAPP-CAPFClnt: SetDelayTimer - set with value <0>
0636 ERR Mar 12 15:07:55.761903 (322:17812) SECUREAPP-Sec create BIO - invalid parameter.
0637 ERR Mar 12 15:07:55.761984 (322:17812) SECUREAPP-SEC_CAPF_BIO_F: CAPF create bio failed
0638 ERR Mar 12 15:07:55.762040 (322:17812) SECUREAPP-SEC_CAPF_OP_F: CAPF operation failed, ret -7
0639 CRT Mar 12 15:07:55.863826 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty$1:? - LSC: Connection failed
++ What we would expect to see is something similar to the following where DNS replies with the IP address that is associated with the FQDN of CUCM. After configuring a AAAA record in DNS for PUB11, we now see the below result in the console logs.
4288 INF Mar 12 16:34:06.162666 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
4289 INF Mar 12 16:34:06.162826 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
4290 INF Mar 12 16:34:06.164908 dnsmasq[12864]: reply PUB11.brianw2.lab is X.X.X.X
4291 NOT Mar 12 16:34:06.165024 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Resolve Tvs Ipv4 Address to X.X.X.X from hostname PUB11.brianw2.lab
راجع رسائل حالة الهاتف التي لا يمكن للهاتف حلها PUB11.BRIANW2.lab. رأيت بعد ذلك ال "LSC: توصيل" failed رسالة.
العيوب التي يجب أخذها بعين الاعتبار:
معرف تصحيح الأخطاء من Cisco CSCub62243 - يفشل تثبيت LSC بشكل متقطع وبعد ذلك يجمد CAPF SRVR.
نقص في التعزيز للأخذ في الاعتبار:
معرف تصحيح الأخطاء من Cisco CSCuz18034 - يلزم إعداد تقارير لنقاط النهاية المثبتة ل LSC مع حالة انتهاء الصلاحية.
توفر هذه المستندات مزيد من المعلومات حول إستخدام قوائم التحكم في الوصول (LSCs) في سياق مصادقة عميل AnyConnect VPN ومصادقة 802.1X.
هناك أيضا نوع متقدم لتكوين LSC، حيث يتم توقيع شهادات LSC مباشرة من قبل مرجع مصدق طرف ثالث، وليس شهادة CAPF.
للحصول على تفاصيل، ارجع إلى: مثال تكوين إستيراد وإنشاء LSCs الموقع على CUCM من قبل CA الطرف الثالث
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
3.0 |
28-Oct-2024 |
تحديث SEO ومتطلبات النمط والترجمة الآلية والتنسيق. |
2.0 |
17-Mar-2023 |
عنوان، مقدمة، نص بديل، SEO، متطلبات النمط، ترجمة آلية، جدائل وتنسيق محدث.
التدقيق الإملائي الذي تم تصحيحه. |
1.0 |
03-May-2018 |
الإصدار الأولي |