فشل الثقة في وحدة Secure Client Umbrella Module SSL/TLS أثناء تسجيل الجهاز

مسألة

أثناء طرح Cisco Secure Client مع وحدة Umbrella النمطية، توقفت الأجهزة عن المزامنة مع لوحة المعلومات وتم الإبلاغ عنها على أنها "غير نشطة." واجه العملاء المتضررون حالات فشل في ثقة SSL/TLS عند محاولة التسجيل إلى موقع الويب devices.api.sse.cisco.com، مما منع تسجيل الأجهزة بنجاح وتغطية الحماية.

أظهرت واجهة المستخدم Umbrella كغير نشط مع رسائل الحالة التالية:

• المظلة غير نشطة.

• أنت غير محمي حاليا بواسطة بوابة ويب آمنة.

• عبارة ويب الآمنة غير مرخصة / معطلة.

كشفت نتائج التشخيص عن فشل ثقة SSL/TLS متسق أثناء التسجيل مع رسالة الخطأ هذه في سجلات العميل الآمنة:

[ERROR] < 10> Device Registration: Registration failed against https://devices.api.sse.cisco.com/deployments/v2/devices/registration with response message The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

البيئة

• Cisco Secure Client مع نشر وحدة Umbrella عبر 2000+ نقطة نهاية

• بنية SD-WAN الأساسية مع سياسات التوجيه

• إنشاء أنفاق مظلية قديمة

• تكوين الشبكة الذي يسمح بجميع الوجهات المطلوبة لكل وثائق Cisco

• لا يوجد فك تشفير SSL نشط لوجهات Cisco على النطاق

قرار

تضمن الحل تحديد مشكلة في تكوين التوجيه وتصحيحها كانت تتسبب في توجيه حركة مرور تسجيل الأجهزة بشكل خاطئ من خلال أنفاق Umbrella القديمة.

تعريف السبب الجذري

كشف تحليل بيانات التقاط الحزمة عن أن شهادة TLS المقدمة لاتصال API كانت شهادة Cisco Umbrella بدلا من شهادة Cisco Secure Access/Let Encrypt المتوقعة. حدد عنوان IP ل devices.api.sse.cisco.com.

وحدد المزيد من التحقيقات سياسة مسار SD-WAN التي تطابق الشبكة الفرعية 146.112.0.0/16، مما تسبب في توجيه حركة المرور إلى موقع devices.api.sse.cisco.com إلى أنفاق المظلة القديمة بدلا من الوجهة المقصودة.

تغييرات التكوين

وقد اتخذت هذه الخطوات لحل المسألة:

• الخطوة 1: قم بإزالة المسارات الثابتة المسببة للمشاكل. تمت إزالة المسارات الثابتة التي تشير إلى 146.112.0.0/16 إلى أنفاق Umbrella القديمة من تكوين SD-WAN.

• الخطوة 2: التحقق من صحة الاتصال. بعد إزالة المسارات الثابتة، تم إختبار العملاء المتضررين لضمان قدرتهم على الاتصال والتسجيل بنجاح في الموقع devices.api.sse.cisco.com.

التحقق

يجب أن تظهر سلسلة الشهادات المتوقعة ل devices.api.sse.cisco.com كما هو موضح:

openssl s_client -connect devices.api.sse.cisco.com:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R13
verify return:1
depth=0 CN = api.sse.cisco.com
verify return:1
---
Certificate chain
 0 s:CN = api.sse.cisco.com
   i:C = US, O = Let's Encrypt, CN = R13
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  5 14:13:56 2026 GMT; NotAfter: Jun  3 14:13:55 2026 GMT
 1 s:C = US, O = Let's Encrypt, CN = R13
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT

بعد تنفيذ تغييرات التكوين، نجح العملاء المتضررون في الاتصال والتسجيل، وتم إكمال النشر بنجاح.

السبب

كان السبب الجذري هو سياسة مسار SD-WAN التي تطابق الشبكة الفرعية 146.112.0.0/16، مما تسبب في توجيه حركة مرور تسجيل الأجهزة الموجهة إلى devices.api.sse.cisco.com (146.112.59.104) بشكل غير صحيح من خلال أنفاق Umbrella القديمة. نتج عن ذلك تقديم شهادة TLS غير صحيحة (شهادة Cisco Umbrella بدلا من شهادة Cisco Secure Access/Let's Encrypt المتوقعة)، مما أدى إلى حدوث حالات فشل في ثقة SSL/TLS أثناء عملية تسجيل الجهاز.

المحتوى ذي الصلة

• توثيق متطلبات شبكة العميل الآمنة من Cisco

• الدعم الفني والتنزيلات من Cisco

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

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