تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند ميزة "الأمان" (SBD) الافتراضية لإصدارات 8.0 من Cisco Unified Communications Manager (CUCM) والإصدارات الأحدث.
يقدم CUCM الإصدار 8.0 والإصدارات الأحدث ميزة SBD، والتي تتكون من ملفات قائمة التحقق من الهوية (ITL) وخدمة التحقق من الثقة (TVS).
يستخدم الآن كل مجموعة CUCM الأمان القائم على ITL تلقائيا. هناك مفاضلة بين الأمان وسهولة الاستخدام/سهولة الإدارة يجب على المسؤولين الإداريين أن يكونوا على دراية بها قبل إجراء بعض التغييرات على مجموعة الإصدار 8.0 من CUCM.
يعمل هذا المستند كملحق للأمان الرسمي من خلال المستندات الافتراضية، كما يوفر معلومات التشغيل وإرشادات أستكشاف الأخطاء وإصلاحها لمساعدة المسؤولين وتسهيل عملية أستكشاف الأخطاء وإصلاحها.
إنها لفكرة جيدة أن تصبح على دراية بتلك المفاهيم الأساسية ل SBD: تشفير المفاتيح غير المتماثلة مقال ويكيبيديا و البنية التحتية للمفتاح العام مقال ويكيبيديا.
يوفر هذا القسم نظرة عامة سريعة على ما توفره الخدمة الافتراضية الخاصة (SBD) بالضبط. للحصول على التفاصيل الفنية الكاملة لكل وظيفة، راجع قسم تفاصيل SBD ومعلومات أستكشاف الأخطاء وإصلاحها.
توفر SBD هذه الوظائف الثلاث لهواتف بروتوكول الإنترنت (IP) المدعومة:
يوفر هذا المستند نظرة عامة على كل من هذه الوظائف.
عند وجود قائمة الشهادات الموثوق بها (CTL) أو ملف ITL، يطلب هاتف IP ملف تكوين TFTP موقع من خادم CUCM TFTP.
يسمح هذا الملف للهاتف بالتحقق من أن ملف التكوين جاء من مصدر موثوق به. مع وجود ملفات CTL/ITL على الهواتف، يجب توقيع ملفات التكوين بواسطة خادم TFTP موثوق به.
يكون الملف نصا عاديا على الشبكة أثناء إرساله، ولكنه يأتي مع توقيع تحقق خاص.
يطلب الهاتف SEP<MAC Address>.cnf.xml.sgn لاستلام ملف التكوين باستخدام التوقيع الخاص.
يتم توقيع ملف التكوين هذا بواسطة المفتاح الخاص TFTP الذي يتوافق مع CallManager.pem في صفحة إدارة شهادات نظام التشغيل (OS).
يحتوي الملف الموقع على توقيع في الأعلى لمصادقة الملف، لكن بخلاف ذلك في XML نص عادي.
توضح الصورة أدناه أن الموقع الخاص بملف التكوين هو CN=CUCM8-Publisher.bbbburns.lab الذي تم توقيعه بدوره من قبل CN=Jasburns-AD.
وهذا يعني أن الهاتف يحتاج إلى التحقق من توقيع CUCM8-Publisher.bbbburns.lab مقابل ملف ITL قبل قبول ملف التكوين هذا.
هنا رسم بياني يوضح كيف يتم إستخدام المفتاح الخاص مع خوارزمية ملخص الرسالة (MD)5 أو دالة تجزئة خوارزمية التجزئة الآمنة (SHA)1 لإنشاء الملف الموقع.
يعكس التحقق من التوقيع هذه العملية من خلال إستخدام المفتاح العام الذي يتطابق من أجل فك تشفير التجزئة. إذا تطابقت التجزئة، فإنها تظهر:
في حال تمكين تشفير تكوين TFTP الاختياري في ملف تعريف أمان الهاتف المقترن، يطلب الهاتف ملف تكوين مشفر.
يتم توقيع هذا الملف باستخدام المفتاح الخاص TFTP ويتم تشفيره باستخدام مفتاح متماثل يتم تبادله بين الهاتف و CUCM (راجع دليل أمان مدير الاتصالات الموحدة من Cisco، الإصدار 8.5(1) للحصول على التفاصيل الكاملة).
لا يمكن قراءة محتوياته باستخدام sniffer على الشبكة إلا إذا كان لدى المراقب المفاتيح الضرورية.
يطلب الهاتف sep<mac address>.cnf.xml.enc.sgn للحصول على الملف المشفر الموقع.
يحتوي ملف التكوين المشفر على التوقيع في البداية أيضا، ولكن لا توجد بيانات نصية عادية بعد ذلك، فقط بيانات مشفرة (حروف ثنائية مضبوطة في محرر النص هذا).
توضح الصورة أن الموقع هو نفسه كما في المثال السابق، لذلك يجب أن يكون هذا الموقع موجودا في ملف ITL قبل أن يقبل الهاتف الملف.
بالإضافة إلى ذلك، يجب أن تكون مفاتيح فك التشفير صحيحة قبل أن يتمكن الهاتف من قراءة محتويات الملف.
تحتوي هواتف بروتوكول الإنترنت (IP) على قدر محدود من الذاكرة، كما يمكن أن يكون هناك عدد كبير من الهواتف لإدارتها في الشبكة.
يعمل CUCM كمخزن ثقة عن بعد عبر أجهزة التلفزيون بحيث لا يلزم وضع مخزن الشهادات الموثوق بها بالكامل على كل هاتف من هواتف بروتوكول الإنترنت (IP).
في أي وقت لا يستطيع الهاتف التحقق من توقيع أو شهادة من خلال ملفات CTL أو ITL، فإنه يطلب من خادم TVS التحقق.
يمكن إدارة مخزن الثقة المركزي هذا بشكل أسهل مما لو كان مخزن الثقة موجودا على جميع هواتف IP.
يوضح هذا القسم تفاصيل عملية SBD.
أولا، هناك عدد من الملفات التي يجب أن تكون موجودة على خادم CUCM نفسه. أهم قطعة هي شهادة TFTP ومفتاح TFTP الخاص.
توجد شهادة TFTP تحت إدارة نظام التشغيل > التأمين > إدارة الشهادات > CallManager.pem.
يستخدم خادم CUCM المفاتيح الخاصة والعامة لشهادة CallManager.pem لخدمة TFTP (وكذلك لخدمة مدير المكالمات (CCM) من Cisco).
تظهر الصورة أن شهادة CallManager.pem تم إصدارها إلى CUCM8-publisher.bbbburns.lab وموقعة من Jasburns-AD. يتم توقيع جميع ملفات تكوين TFTP بواسطة المفتاح الخاص أدناه.
يمكن لجميع الهواتف إستخدام المفتاح العام TFTP في شهادة CallManager.pem لتشفير أي ملف مشفر باستخدام مفتاح TFTP الخاص، وكذلك للتحقق من أي ملف موقع باستخدام مفتاح TFTP الخاص.
بالإضافة إلى المفتاح الخاص بشهادة CallManager.pem، يقوم خادم CUCM أيضا بتخزين ملف ITL الذي يتم تقديمه إلى الهواتف.
يعرض الأمر show itl المحتويات الكاملة لملف ITL هذا عبر وصول Secure Shell (SSH) إلى واجهة سطر الأوامر (CLI) الخاصة بنظام تشغيل خادم CUCM.
ينقسم هذا القسم ملف ITL قطعة، لأن به عدد من المكونات الهامة التي يستخدمها الهاتف.
الجزء الأول هو معلومات التوقيع. حتى ملف ITL هو ملف موقع. يوضح هذا الإخراج أنه موقع بواسطة المفتاح الخاص TFTP المقترن بشهادة CallManager.pem السابقة.
admin:show itl
Length of ITL file: 5438
The ITL File was last modified on Wed Jul 27 10:16:24 EDT 2011
Parse ITL File
----------------
Version: 1.2
HeaderLength: 296 (BYTES)
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
3 SIGNERID 2 110
4 SIGNERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
5 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
6 CANAME 15 CN=JASBURNS-AD
*Signature omitted for brevity*
تحتوي كل من الأقسام التالية على الغرض الخاص بها داخل معلمة دالة خاصة. الوظيفة الأولى هي الرمز المميز لأمان مسؤول النظام. هذا هو توقيع المفتاح العام TFTP.
ITL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1972
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 15 CN=JASBURNS-AD
6 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
7 PUBLICKEY 140
8 SIGNATURE 256
9 CERTIFICATE 1442 0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5
8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.
الوظيفة التالية هي CCM+TFTP. هذا مرة أخرى هو المفتاح العام TFTP الذي يعمل على مصادقة ملفات تكوين TFTP التي تم تنزيلها وفك تشفيرها.
ITL Record #:2
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1972
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CCM+TFTP
5 ISSUERNAME 15 CN=JASBURNS-AD
6 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
7 PUBLICKEY 140
8 SIGNATURE 256
9 CERTIFICATE 1442 0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5
8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
الوظيفة التالية هي أجهزة التلفزيون. يوجد مدخل للمفتاح العام لكل خادم تليفزيونات يتصل به الهاتف.
وهذا يسمح للهاتف بإنشاء جلسة عمل لطبقة مآخذ التوصيل الآمنة (SSL) لخادم TVS.
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 743
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 2E:3E:1A:7B:DA:A6:4D:84
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C7 E1 D9 7A CC B0 2B C2 A8 B2 90 FB
AA FE 66 5B EC 41 42 5D
12 HASH ALGORITHM 1 SHA-1
الوظيفة النهائية المضمنة في ملف ITL هي وظيفة وكيل المرجع المصدق (CAPF).
تسمح هذه الشهادة للهواتف بإنشاء اتصال آمن بخدمة CAPF على خادم CUCM حتى يمكن للهاتف تثبيت أو تحديث شهادة ذات أهمية محلية (LSC).
ITL Record #:4
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 455
2 DNSNAME 2
3 SUBJECTNAME 61 CN=CAPF-9c4cba7d;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 61 CN=CAPF-9c4cba7d;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 0A:DC:6E:77:42:91:4A:53
7 PUBLICKEY 140
8 SIGNATURE 128
11 CERTHASH 20 C7 3D EA 77 94 5E 06 14 D2 90 B1
A1 43 7B 69 84 1D 2D 85 2E
12 HASH ALGORITHM 1 SHA-1
The ITL file was verified successfully.
يغطي القسم التالي ما يحدث بالضبط عندما يجري جزمة الهاتف.
بعد تمهيد الهاتف والحصول على عنوان IP وعنوان خادم TFTP، يطلب ملفات CTL و ITL أولا.
يظهر التقاط الحزمة هذا طلب هاتف لملف ITL. إذا قمت بالتصفية على tftp.opcode == 1، سترى كل طلب قراءة TFTP من الهاتف:
نظرا لأن الهاتف تلقى ملفات CTL و ITL من TFTP بنجاح، يطلب الهاتف ملف تكوين موقع.
تتوفر سجلات وحدة تحكم الهاتف التي تظهر هذا السلوك من واجهة الويب للهاتف:
يطلب الهاتف أولا ملف CTL، والذي ينجح:
837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv
846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from
14 . 48 . 44 . 80
847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes
بعد ذلك الهاتف أيضا يطلب ملف ITL:
868: NOT 09:13:17.860613 TFTP: [28]:Requesting ITLSEP0011215A1AE3.tlv from
14 . 48 . 44 . 80
869: NOT 09:13:17.875059 TFTP: [28]:Finished --> rcvd 5438 bytes
بعد تنزيل ملف ITL، يجب التحقق من صحته. هناك عدد من الحالات التي يمكن أن يكون فيها الهاتف في هذه المرحلة، لذلك هذا المستند يغطي جميعها.
فيما يلي مخطط تدفق يصف كيفية تحقق الهاتف من الملفات الموقعة وشهادات HTTPS:
وفي هذه الحالة، يمكن للهاتف التحقق من صحة التوقيع في ملفات ITL و CTL. يحتوي الهاتف بالفعل على كل من CTL و ITL، لذلك قام بالتحقق من خلالهما ووجد التوقيع الصحيح.
877: NOT 09:13:17.925249 SECD: validate_file_envelope:
File sign verify SUCCESS; header length <296>
بما أن الهاتف قام بتنزيل ملفات CTL و ITL، فإنه من هذه النقطة عليه يطلب ملفات التكوين الموقعة فقط.
وهذا يوضح أن منطق الهاتف هو تحديد أن خادم TFTP آمن، استنادا إلى وجود CTL و ITL، ثم لطلب ملف موقع:
917: NOT 09:13:18.433411 tftpClient: tftp request rcv'd from /usr/tmp/tftp,
srcFile = SEP0011215A1AE3.cnf.xml, dstFile = /usr/ram/SEP0011215A1AE3.cnf.xml
max size = 550001
918: NOT 09:13:18.457949 tftpClient: auth server - tftpList[0] = ::ffff:
14 . 48 . 44 . 80
919: NOT 09:13:18.458937 tftpClient: look up server - 0
920: NOT 09:13:18.462479 SECD: lookupCTL: TFTP SRVR secure
921: NOT 09:13:18.466658 tftpClient: secVal = 0x9 922: NOT 09:13:18.467762
tftpClient: ::ffff:14 . 48 . 44 . 80 is a secure server
923: NOT 09:13:18.468614 tftpClient: retval = SRVR_SECURE
924: NOT 09:13:18.469485 tftpClient: Secure file requested
925: NOT 09:13:18.471217 tftpClient: authenticated file approved - add .sgn
-- SEP0011215A1AE3.cnf.xml.sgn
926: NOT 09:13:18.540562 TFTP: [10]:Requesting SEP0011215A1AE3.cnf.xml.sgn
from 14 . 48 . 44 . 80 with size limit of 550001
927: NOT 09:13:18.559326 TFTP: [10]:Finished --> rcvd 7652 bytes
بمجرد تنزيل ملف التكوين الموقع، يجب أن يصادق الهاتف عليه مقابل الدالة الخاصة ب CCM+TFTP داخل ITL:
937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS
</usr/ram/SEP0011215A1AE3.cnf.xml>
يوفر ملف ITL وظيفة TVS التي تحتوي على شهادة خدمة TVS التي تعمل على منفذ TCP لخادم CUCM 2445.
يتم تشغيل أجهزة التلفزيون على كافة الخوادم حيث يتم تنشيط خدمة CallManager. تستخدم خدمة CUCM TFTP مجموعة CallManager التي تم تكوينها لإنشاء قائمة بخوادم TVS التي يجب على الهاتف الاتصال بها على ملف تكوين الهاتف.
تستخدم بعض المختبرات خادم CUCM واحد فقط. في مجموعة CUCM متعددة العقد، يمكن أن يكون هناك ما يصل إلى ثلاثة إدخالات في أجهزة التلفزيون للهاتف، واحد لكل CUCM في مجموعة CUCM للهاتف.
يوضح هذا المثال ما يحدث عند ضغط زر الدلائل على هاتف IP. تم تكوين عنوان URL للأدلة ل HTTPS، لذلك يتم عرض الهاتف مع شهادة ويب Tomcat من خادم Directories.
لم يتم تحميل شهادة ويب Tomcat هذه (tomcat.pem في إدارة OS) في الهاتف، لذلك يجب أن يتصل الهاتف بالتلفاز لمصادقة الشهادة.
أحلت السابق TVS نظرة عامة رسم بياني لوصف من التفاعل. فيما يلي منظور سجل وحدة تحكم الهاتف:
أولا تجد عنوان URL الخاص بالدليل:
1184: NOT 15:20:55.219275 JVM: Startup Module Loader|cip.dir.TandunDirectories:
? - Directory url https://14 . 48 . 44 . 80:8443/ccmcip/xmldirectory.jsp
هذه جلسة HTTP آمنة ل SSL/Transport Layer Security (TLS) تتطلب التحقق.
1205: NOT 15:20:59.404971 SECD: clpSetupSsl: Trying to connect to IPV4, IP:
14 . 48 . 44 . 80, Port : 8443
1206: NOT 15:20:59.406896 SECD: clpSetupSsl: TCP connect() waiting,
<14 . 48 . 44 . 80> c:8 s:9 port: 8443
1207: NOT 15:20:59.408136 SECD: clpSetupSsl: TCP connected,
<14 . 48 . 44 . 80> c:8 s:9
1208: NOT 15:20:59.409393 SECD: clpSetupSsl: start SSL/TLS handshake,
<14 . 48 . 44 . 80> c:8 s:9
1209: NOT 15:20:59.423386 SECD: srvr_cert_vfy: Server Certificate
Validation needs to be done
يتحقق الهاتف أولا من أن الشهادة المقدمة من خادم SSL/TLS موجودة في CTL. ثم يفحص الهاتف الدالات الموجودة في ملف ITL لمعرفة ما إذا وجد تطابق.
تقول رسالة الخطأ هذه "لا يوجد HTTPS في CTL"، مما يعني "لا يمكن العثور على الشهادة في CTL أو ITL."
1213: NOT 15:20:59.429176 SECD: findByCertAndRoleInTL: Searching TL from CTL file
1214: NOT 15:20:59.430315 SECD: findByCertAndRoleInTL: Searching TL from ITL file
1215: ERR 15:20:59.431314 SECD: EROR:https_cert_vfy: HTTPS cert not in CTL,
<14 . 48 . 44 . 80>
بعد التحقق من المحتويات المباشرة لملف CTL و ITL للشهادة، فإن الشيء التالي الذي يتحقق منه الهاتف هو ذاكرة التخزين المؤقت للتلفزيون.
ويتم القيام بذلك لتقليل حركة مرور البيانات على الشبكة إذا كان الهاتف قد طلب مؤخرا من خادم TVS الحصول على نفس الشهادة.
إذا لم يتم العثور على شهادة HTTPS في ذاكرة التخزين المؤقت للهاتف، يمكنك إجراء اتصال TCP بخادم TVS نفسه.
1220: NOT 15:20:59.444517 SECD: processTvsClntReq: TVS Certificate
Authentication request
1221: NOT 15:20:59.445507 SECD: lookupAuthCertTvsCacheEntry: No matching
entry found at cache
1222: NOT 15:20:59.446518 SECD: processTvsClntReq: No server sock exists,
must be created
1223: NOT 15:20:59.451378 SECD: secReq_initClient: clnt sock fd 11 bound
to </tmp/secClnt_secd>
1224: NOT 15:20:59.457643 SECD: getTvsServerInfo: Phone in IPv4 only mode
1225: NOT 15:20:59.458706 SECD: getTvsServerInfo: Retreiving IPv4 address
1230: NOT 15:20:59.472628 SECD: connectToTvsServer: Successfully started
a TLS connection establishment to the TVS server: IP:14 . 48 . 44 . 80, port:2445
(default); Waiting for it to get connected.
تذكر أن الاتصال بأجهزة التلفزيون نفسها هو SSL/TLS (HTTP الآمن، أو HTTPS)، وبالتالي فهو أيضا شهادة يلزم مصادقتها مقابل CTL إلى ITL.
إذا سار كل شيء بشكل صحيح، فإن شهادة خادم TVS يتم العثور عليها في وظيفة TVS الخاصة بملف ITL. راجع سجل ITL #3 في ملف ITL للمثال السابق.
1244: NOT 15:20:59.529938 SECD: srvr_cert_vfy: Server Certificate Validation
needs to be done
1245: NOT 15:20:59.533412 SECD: findByIssuerAndSerialAndRoleInTL:
Searching TL from CTL file
1246: NOT 15:20:59.534936 SECD: findByIssuerAndSerialAndRoleInTL:
Searching TL from ITL file
1247: NOT 15:20:59.537359 SECD: verifyCertWithHashFromTL: cert hash and
hash in TL MATCH
1248: NOT 15:20:59.538726 SECD: tvs_cert_vfy: TVS cert verified with hash
from TL, <14 . 48 . 44 . 80>
نجاح! الهاتف الآن لديه اتصال آمن بخادم TVS. الخطوة التالية هي أن تسأل خادم TVS "مرحبا، هل أثق بشهادة خادم Guides هذه؟ "
يوضح هذا المثال الإجابة على هذا السؤال - إجابة 0 تعني النجاح (لا خطأ).
1264: NOT 15:20:59.789738 SECD: sendTvsClientReqToSrvr: Authenticate
Certificate : request sent to TVS server - waiting for response
1273: NOT 15:20:59.825648 SECD: processTvsSrvrResponse: Authentication Response
received, status : 0
ونظرا لوجود إستجابة ناجحة من أجهزة التلفزيون، يتم حفظ نتائج هذه الشهادة في ذاكرة التخزين المؤقت.
هذا يعني أنه إذا قمت بالضغط على زر الدلائل مرة أخرى خلال ال 86400 ثانية التالية، فلن تحتاج إلى الاتصال بخادم TVS للتحقق من الترخيص. يمكنك ببساطة الوصول إلى ذاكرة التخزين المؤقت المحلية.
1279: NOT 15:20:59.837086 SECD: saveCertToTvsCache: Saving certificate
in TVS cache with default time-to-live value: 86400 seconds
1287: ERR 15:20:59.859993 SECD: Authenticated the HTTPS conn via TVS
أخيرا، تحقق من نجاح إتصالك بخادم الدلائل.
1302: ERR 15:21:01.959700 JVM: Startup Module Loader|cip.http.ae:?
- listener.httpSucceed: https://14 . 48 . 44 . 80:8443/ccmcip/
xmldirectoryinput.jsp?name=SEP0011215A1AE3
هنا مثال لما يحدث على خادم CUCM حيث تعمل أجهزة التلفزيون. يمكنك تجميع سجلات أجهزة التلفزيون باستخدام أداة مراقبة الوقت الفعلي الموحدة (RTMT) من Cisco.
تظهر سجلات CUCM TVS أن مصافحة SSL مع الهاتف، الهاتف يسأل أجهزة التلفزيون عن شهادة Tomcat، ثم يستجيب أجهزة التلفزيون لتشير إلى أن الشهادة مطابقة في مخزن شهادات TVS.
15:21:01.954 | debug 14 . 48 . 44 . 202: tvsSSLHandShake Session ciphers - AES256-SHA
15:21:01.954 | debug TLS HS Done for ph_conn .
15:21:02.010 | debug MsgType : TVS_MSG_CERT_VERIFICATION_REQ
15:21:02.011 | debug tvsGetIssuerNameFromX509 - issuerName : CN=CUCM8-
Publisher.bbbburns.lab;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US and Length: 75
15:21:02.011 | debug CertificateDBCache::getCertificateInformation -
Certificate compare return =0
15:21:02.011 | debug CertificateDBCache::getCertificateInformation -
Certificate found and equal
15:21:02.011 | debug MsgType : TVS_MSG_CERT_VERIFICATION_RES
مخزن شهادات TVS هي قائمة بكافة الشهادات الموجودة في صفحة الويب إدارة نظام التشغيل > إدارة الشهادات.
هناك مفهوم خاطئ شائع يظهر أثناء أستكشاف المشكلات وإصلاحها يتعلق بالميل إلى حذف ملف ITL على أمل أن يحل مشكلة التحقق من الملف.
في بعض الأحيان يكون حذف ملف ITL مطلوبا، لكن ملف ITL يحتاج فقط إلى أن يتم حذفه عندما تكون جميع هذه الشروط مستوفاة.
وإليكم كيف تتفحصون أول إثنين من هذه الحالات.
أولا، يمكنك مقارنة المجموع الاختباري لملف ITL الموجود على CUCM بملف المجموع الاختباري ITL للهاتف.
لا توجد حاليا طريقة للنظر إلى مجموع MD5الخاص بملف ITL على CUCM من CUCM نفسه حتى تقوم بتشغيل إصدار باستخدام الإصلاح الخاص بمعرف تصحيح الأخطاء هذا CSCto60209 من Cisco.
في الفترة الانتقالية، قم بتشغيل هذا باستخدام برامج واجهة المستخدم الرسومية (GUI) أو واجهة سطر الأوامر (CLI) المفضلة لديك:
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14 . 48 . 44 . 80
tftp> get ITLSEP0011215A1AE3.tlv
Received 5438 bytes in 0.0 seconds
tftp> quit
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum
ITLSEP0011215A1AE3.tlv
b61910bb01d8d3a1c1b36526cc9f2ddc ITLSEP0011215A1AE3.tlv
هذا يوضح أن ال MD5sum من ال ITL مبرد في CUCM هو b61910bb01d8d3a1c1b36526cc9f2ddc.
الآن يمكنك النظر إلى الهاتف نفسه لتحديد تجزئة ملف ITL الذي تم تحميله هناك: الإعدادات > تكوين الأمان > قائمة الثقة.
وهذا يوضح أن مجموعات MD5SUMS متطابقة. وهذا يعني أن ملف ITL الموجود على الهاتف يطابق الملف الموجود على CUCM، وبالتالي لا يلزم حذفه.
إذا لم تتطابق مع الشهادة، يجب الانتقال إلى العملية التالية - تحديد ما إذا كانت شهادة TVS في ITL مطابقة للشهادة المقدمة من أجهزة التلفزيون أم لا. هذه العملية أكثر انخراطا.
أولا، راجع التقاط حزمة الهاتف الذي يتصل بخادم TVS على منفذ TCP 2445.
انقر بزر الماوس الأيمن فوق أي حزمة في هذا الدفق في Wireshark، ثم انقر فوق فك التشفير باسم، وحدد SSL. ابحث عن شهادة الخادم التي تبدو كما يلي:
انظر إلى ترخيص TVS الموجود ضمن ملف ITL السابق. بعد ذلك ترى مدخل مع الرقم التسلسلي 2E3E1A7BDAA64D84.
admin:show itl
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 743
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 2E:3E:1A:7B:DA:A6:4D:84
نجاح، يطابق TVS.pem الموجود داخل ملف ITL شهادة TVS المقدمة على الشبكة. لا تحتاج إلى حذف سجل المعاملات الدولي، وتقدم أجهزة التلفزيون الشهادة الصحيحة.
إذا إستمرت مصادقة الملف في الفشل، فتحقق من بقية مخطط التدفق السابق.
أهم شهادة الآن هي شهادة CallManager.pem. يتم إستخدام مفتاح الشهادة الخاص هذا لتوقيع جميع ملفات تكوين TFTP، والتي تتضمن ملف ITL.
في حالة إعادة إنشاء ملف CallManager.pem، يتم إنشاء شهادة CCM+TFTP جديدة باستخدام مفتاح خاص جديد. بالإضافة إلى ذلك، تم الآن توقيع ملف ITL بواسطة مفتاح CCM+TFTP الجديد هذا.
بعد إعادة إنشاء CallManager.pem وإعادة تشغيل خدمة TVS و TFTP، يحدث ذلك عند تمهيد الهاتف.
ملاحظة: هذا الجزء مهم للغاية. يجب أن تظل شهادة TVS من ملف ITL القديم متطابقة. في حالة إعادة إنشاء كل من CallManager.pem و TVS.pem في نفس الوقت بالضبط، يتعذر على الهواتف تنزيل أي ملفات جديدة دون حذف ITL من الهاتف يدويا.
النقاط الرئيسية:
عند نقل الهواتف من مجموعة إلى أخرى مع وجود قوائم التحكم في الوصول إلى النقل (ITL)، يجب أخذ المفتاح الخاص الخاص الخاص الخاص الخاص ب TFTP في الاعتبار.
يجب أن يتطابق أي ملف تكوين جديد مقدم إلى الهاتف مع توقيع في CTL أو ITL أو توقيع في خدمة الهاتف الحالية.
يشرح هذا المستند كيفية التأكد من إمكانية الوثوق بملف ITL لنظام المجموعة الجديد وملفات التكوين بواسطة ملف ITL الحالي على الهاتف. https://supportforums.cisco.com/docs/DOC-15799.
يتم إجراء نسخ إحتياطي لشهادة CallManager.pem والمفتاح الخاص عبر نظام إسترداد البيانات بعد الكوارث (DRS). إذا تم إعادة إنشاء خادم TFTP، فيجب استعادته من النسخة الاحتياطية حتى يمكن إستعادة المفتاح الخاص.
بدون المفتاح الخاص CallManager.pem على الخادم، لا تثق الهواتف التي تحتوي على قوائم التحكم في الوصول (ITL) الحالية التي تستخدم المفتاح القديم في ملفات التكوين الموقعة.
إذا تم إعادة إنشاء نظام مجموعة ولم تتم استعادته من النسخة الاحتياطية، فإنه يشبه مستند نقل الهواتف بين المجموعات". وذلك لأن المجموعة ذات المفتاح الجديد هي مجموعة مختلفة بقدر ما يتعلق الامر بالهواتف.
هناك عيب خطير واحد مرتبط بالنسخ الاحتياطي والاستعادة. إذا كان نظام مجموعة عرضة لمعرف تصحيح الأخطاء من Cisco CSCtn50405، فإن عمليات النسخ الاحتياطي ل DRS لا تحتوي على شهادة CallManager.pem.
وهذا يتسبب في قيام أي خادم تم استعادته من النسخة الاحتياطية هذه بإنشاء ملفات ITL تالفة حتى يتم إنشاء CallManager.pem جديد.
في حالة عدم وجود خوادم TFTP وظيفية أخرى لم تمر بعملية النسخ الاحتياطي والاستعادة، قد يعني ذلك أنه يجب حذف جميع ملفات ITL من الهواتف.
للتحقق مما إذا كان ملف CallManager.pem يحتاج إلى إعادة الإنشاء، أدخل الأمر show itl الذي يتبعه:
run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from
certificate as c, certificatetrustrolemap as r, typetrustrole as t where c.pkid =
r.fkcertificate and t.enum = r.tktrustrole
في مخرجات ITL، تكون الأخطاء الأساسية التي يجب البحث عنها هي:
This etoken was not used to sign the ITL file.
و
Verification of the ITL file failed.
Error parsing the ITL file!!
يقوم الاستعلام للغة الاستعلام المنظمة (SQL) السابقة بالبحث عن الشهادات التي لها دور "المصادقة والتفويض."
يجب أن تكون شهادة CallManager.pem في استعلام قاعدة البيانات السابق الذي يشتمل على دور المصادقة والتفويض موجودة أيضا في صفحة ويب إدارة شهادات إدارة نظام التشغيل.
في حالة مواجهة العيب السابق، يكون هناك عدم تطابق بين شهادات CallManager.pem في الاستعلام وفي صفحة ويب لنظام التشغيل.
إذا قمت بتغيير اسم المضيف أو اسم المجال لخادم CUCM، فإنه يعيد إنشاء كل الشهادات مرة واحدة على ذلك الخادم. شرح قسم تجديد الشهادات أن إعادة إنشاء كل من TVS.PEM و CallManager.PEM "أمر سيء".
هناك بعض السيناريوهات التي يفشل فيها تغيير اسم المضيف، و البعض الآخر يعمل دون مشاكل. يغطي هذا القسم كل هذه العناصر ويربطها مع ما تعرفه بالفعل عن التلفزيون و ITL من هذا المستند.
نظام مجموعة ذو عقدة واحدة مع ITL فقط (أستخدم الحذر، وهذا يكسر دون تحضير)
نظام مجموعة أحادي العقد مزود بكل من CTL و ITL (يمكن كسر هذا بشكل مؤقت، ولكن يمكن إصلاحه بسهولة)
نظام المجموعة متعدد العقد مع ITL فقط (يعمل هذا النظام بشكل عام، ولكنه يمكن تعطيله بشكل دائم إذا تم على عجل)
نظام مجموعة متعدد العقد مع كل من CTL و ITL (لا يمكن كسر هذا بشكل دائم)
عندما يجزمة هاتف مع ITL، فإنه يطلب هذه الملفات: CTLSEP<MAC Address>.tlv، ITLSEP<MAC Address>.tlv، وSEP<MAC Address>.cnf.xml.sgn.
إذا تعذر على الهاتف العثور على هذه الملفات، فإنه يطلب ITLFile.tlv وCTLFile.tlv، وهو ما يوفره خادم TFTP مركزي لأي هاتف يطلبه.
باستخدام بروتوكول TFTP المركزي، يوجد مجموعة TFTP واحدة تشير إلى عدد من المجموعات الفرعية الأخرى.
غالبا ما يتم القيام بذلك لأن الهواتف الموجودة على مجموعات CUCM المتعددة تشترك في نطاق DHCP نفسه، وبالتالي يجب أن يكون لها نفس خيار DHCP رقم 150 TFTP.
تشير جميع هواتف بروتوكول الإنترنت (IP) إلى مجموعة TFTP المركزية، حتى إذا كانت مسجلة في مجموعات أخرى. يستعلم خادم TFTP المركزي خوادم TFTP البعيدة عندما يستلم طلبا لملف لا يمكنه العثور عليه.
وبسبب هذه العملية، تعمل TFTP المركزية فقط في بيئة ITL المتجانسة.
يجب أن تقوم جميع الخوادم بتشغيل الإصدار 8.x من CUCM أو الإصدارات الأحدث، أو يجب أن تقوم جميع الخوادم بتشغيل الإصدارات قبل الإصدار 8.x.
إذا تم تقديم ITLFile.tlv من خادم TFTP المركزي، فإن الهواتف لا تثق في أي ملفات من خادم TFTP البعيد نظرا لعدم تطابق التوقيعات.
هذا يحدث في مزيج غير متجانس. في مزيج متجانس، يطلب الهاتف ITLSEP<MAC>.tlv الذي يتم سحبه من المجموعة البعيدة الصحيحة.
في بيئة غير متجانسة تحتوي على مزيج من مجموعات الإصدار 8.x والإصدار 8.x، يجب تمكين "مجموعة التحضير للرجوع إلى ما قبل 8.0" على مجموعة الإصدار 8.x كما هو موضح في معرف تصحيح الأخطاء من Cisco CSCto87262 .
قم بتكوين "معلمات عنوان URL للهاتف الآمن" باستخدام HTTP بدلا من HTTPS. يؤدي هذا إلى تعطيل وظائف ITL بشكل فعال على الهاتف.
لا يمكنك إيقاف تشغيل SBD إلا إذا كانت SBD و ITL يعملان حاليا.
يمكن تعطيل SBD مؤقتا على الهواتف باستخدام مجموعة التحضير للرجوع إلى معلمة المؤسسة السابقة 8.0" ومن خلال تكوين "معلمات عنوان URL للهاتف الآمن" باستخدام HTTP بدلا من HTTPS.
عندما تقوم بضبط معلمة التراجع، فإنها تقوم بإنشاء ملف ITL موقع بإدخالات دالة فارغة.
لا يزال ملف ITL "الفارغ" موقعا، لذلك يجب أن يكون نظام المجموعة في حالة أمان وظيفية بالكامل قبل تمكين هذه المعلمة.
بعد تمكين هذه المعلمة وتنزيل ملف ITL الجديد بإدخالات فارغة والتحقق من صحتها، تقبل الهواتف أي ملف تكوين، بغض النظر عمن قام بتوقيعه.
لا يوصى بترك المجموعة في هذه الحالة، نظرا لعدم توفر أي من الوظائف الثلاث التي تمت الإشارة إليها مسبقا (ملفات التكوين المصادق عليها وملفات التكوين المشفرة وعناوين HTTPS URL).
لا توجد حاليا طريقة لحذف جميع قوائم التحكم في الوصول إلى النقل (ITL) من هاتف تقدمه Cisco عن بعد. ولهذا السبب فإن الإجراءات والتفاعلات الموصوفة في هذا المستند مهمة للغاية لأخذها في الاعتبار.
هناك حاليا تحسين غير محلول ل Cisco CSCto47052 أن يطلب هذا وظيفة، غير أنه لم يتم تنفيذه بعد.
في الفترة الانتقالية، تمت إضافة ميزة جديدة عبر Cisco بق CSCts01319 التي قد تسمح لمركز المساعدة الفنية (TAC) من Cisco بالعودة إلى قائمة التحكم في الوصول (ITL) الموثوقة سابقا إذا كانت لا تزال متوفرة على الخادم.
ويعمل هذا فقط في حالات معينة حيث يكون نظام المجموعة على إصدار به إصلاح هذا الخلل، وحيث يوجد سجل المعاملات الدولي السابق في نسخة إحتياطية مخزنة في موقع خاص على الخادم.
قم بعرض العيب لمعرفة ما إذا كان الإصدار الخاص بك يحتوي على الإصلاح أم لا. اتصل ب cisco TAC in order to ركضت من خلال المحتمل إستعادة إجراء شرح في الخطأ.
إذا لم يكن الإجراء السابق متاحا، يجب دفع أزرار الهاتف يدويا على الهاتف لحذف ملف ITL. هذه هي المقايضة التي تتم بين الأمن وسهولة الإدارة. لكي يكون ملف ITL آمنا بالفعل، يجب ألا يتم إزالته بسهولة عن بعد.
حتى مع ضغطات الزر المفتوحة بالبرامج النصية التي تحتوي على كائنات XML لبروتوكول الوصول البسيط إلى الكائن (SOAP)، لا يمكن إزالة ITL عن بعد.
وذلك لأن الوصول إلى TVS (وبالتالي الوصول الآمن إلى URL للمصادقة للتحقق من صحة كائنات الضغط الواردة على زر SOAP XML) لا يعمل في هذه المرحلة.
إذا لم يتم تكوين عنوان URL للمصادقة على أنه آمن، فمن الممكن كتابة المطابع النصية لحذف ITL، ولكن لا يتوفر هذا البرنامج النصي من Cisco.
من الممكن أن تكون الطرق الأخرى لعمل نصوص لضغطات المفاتيح البعيدة بدون إستخدام عنوان URL للمصادقة متاحة من طرف ثالث، لكن هذه التطبيقات لا تقدمها Cisco.
وأكثر الطرق إستخداما لحذف سجل المعاملات الدولي هي بث بريد إلكتروني إلى جميع مستخدمي الهاتف يرشدهم إلى تسلسل المفاتيح.
في حالة تعيين الوصول إلى الإعدادات إلى Restricted أو Disabled، يجب إعادة ضبط الهاتف في المصنع، حيث لا يمكن للمستخدمين الوصول إلى قائمة "الإعدادات" الخاصة بالهاتف.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
2.0 |
14-Jul-2023 |
تقويم |
1.0 |
27-May-2013 |
الإصدار الأولي |