استكشاف أخطاء فحص TLS

مقدمة

تغطي هذه المقالة سيناريوهات استكشاف الأخطاء المتقدمة لفحص TLS. قبل المتابعة، من المستحسن مراجعة تكوين الفحص TLS والسلوك لفهم كيفية معالجة حركة المرور وتنفيذها.

تحت الظروف العادية، فحص TLS ليس مرئياً للمستخدمين النهائيين. للتحقق مما إذا كان يتم فحص حركة المرور، تحقق من حقل فحص TLS في أحداث الحساب (1 = تم الفحص، 0 = تجاوز)، راجع مُصدر الشهادة في المتصفح (Cato Networks)، أو استخدم تقارير فحص TLS.

Cato يشمل مجموعة من قواعد التجاوز الافتراضية للتطبيقات والأجهزة والمجالات المعروفة جيداً. هذه القواعد المدارة من قبل النظام غير قابلة للتعديل ويجب دائمًا مراجعتها قبل إنشاء قواعد مخصصة. للمزيد من التفاصيل، اطلع على قواعد التجاوز الافتراضية

الأعراض

الأسباب المحتملة

معظم مشاكل فحص TLS ترتبط ببعض الظروف الشائعة.

  • بعض التطبيقات ليست متوافقة مع فحص TLS. التطبيقات التي تستخدم تثبيت الشهادة، التحقق الصارم من TLS، أو TLS المتبادل سوف ترفض الاعتراض وتفشل في الاتصال.

  • مشاكل ثقة الشهادة على العميل تعد سبباً متكرراً آخر. إذا كانت شهادة الجذر الخاصة بـ Cato مفقودة، غير موثوقة، أو موزعة بشكل غير متناسق، فإن حركة المرور المفحوصة ستفشل حتى لو كانت السياسة صحيحة.

  • في حالات أخرى، المشكلة تأتي من خادم الوجهة. المشاكل مثل الشهادات المنتهية، السلاسل غير المكتملة، عدم توافق اسم المضيف، أو السلطات غير المعروفة للشهادة قد لا تكون مرئية دائماً في المتصفح عندما يكون فحص TLS مفعل، ولكن يتم فرضها من قبل النقطة.

  • قد تفشل الأنظمة القديمة بسبب عدم توافق بروتوكول TLS أو الشفرات. التطبيقات التي تستخدم إصدارات TLS القديمة أو مجموعات الشفرات الضعيفة قد لا تفي بالمتطلبات التي تم تعريفها في سياسة فحص TLS.

  • يمكن أن تقدم المواقع الحديثة أيضًا مشاكل بسبب المجالات التابعة المتعددة. إذا تم السماح فقط بالمجال الرئيسي أو تجاوزه بينما يتم حظر المجالات الداعمة أو تفحص بشكل مختلف، فقد يعاني المستخدمون من تحميل بطيء أو محتوى مفقود.

  • وأخيرًا، يلعب السلوك المحدد للمنصة دوراً. قد تختلف سلوكيات الأجهزة المحمولة ونقاط النهاية BYOD وأنظمة Linux بسبب القيود المفروضة على ثقة الشهادة، التحقق الخاص بالتطبيق، أو قواعد التجاوز الافتراضية.

استكشاف الأخطاء وإصلاحها الأولية

عند التحقيق في المشاكل المتعلقة بـ TLS، فإن الهدف الأساسي هو تحديد ما إذا كانت المشكلة تنشأ من العميل، الشبكة (فحص TLS)، أو خادم الوجهة.

1. قم بعزل النطاق

ابدأ بالتحقق مما إذا كانت المشكلة محددة بالعميل. اختبر نفس عنوان URL:

  • من متصفح مختلف
  • من جهاز آخر على نفس الشبكة
  • من نفس الجهاز على شبكة مختلفة (مثل نقطة ساخنة)

إذا كانت المشكلة مقصورة على متصفح أو جهاز معين، فإن هذا يشير عادةً إلى مشكلة الثقة المحلية أو مشكلة الإعداد. إذا كانت تعمل خارج الشبكة، فمن المحتمل أن المشكلة مرتبطة بـ فحص TLS أو تنفيذ السياسة.

2. تحقق من فحص TLS / مُصدر الشهادة

من المستعرض:

  • افتح DevTools → مفتاح الأمان التبويب الأمان أو انقر فوق أيقونة القفل
  • افحص سلسلة الشهادات

تحقق من المُصدر:

  • وكيل / مؤسسة CA (مثل، Cato) → فحص TLS نشط
  • CA العامة (مثل، DigiCert، دعنا نشفر) → جلسة TLS مباشرة

3. التحقق من الثقة في العميل

  • تأكد من أن شهادة الجذر الخاصة بـ Cato مثبتة بشكل صحيح على نقطة النهاية.

  • تحقق من وجود شهادة الجذر في متجر الثقة الخاص بالنظام التشغيلي:
    • على ويندوز، افتح إدارة شهادات الكمبيوتر عبر كتابة certlm.msc وابحث عن شهادة الجذر ضمن هيئات التصديق الجذور الموثوقة
    • على ماك، افتح الوصول إلى الإغلاق وابحث عن شهادة الجذر ضمن الإغلاق النظامي
  • تحقق من الوقت والتاريخ النظام
  • إذا كانت شهادة الجذر الخاصة بـ Cato مفقودة من نقطة النهاية، قم بتنزيلها وتثبيتها كما هو مبين في تثبيت شهادة Cato على الأجهزة

  • سيؤدي الإعداد الخاطئ للثقة أو عدم ثقة إلى فشل TLS الفوري.

4. اختبار مصافحة TLS من العميل

استخدم الأدوات الخاصة بالعميل لمحاكاة اتصال TLS وتحديد بالضبط أين ولماذا تفشل المصافحة. تقدم هذه الأدوات الأخطاء التي تكون غالباً مخفية وراء رسائل المتصفح العامة.

قم بتشغيل ما يلي أو ما يشابه من نقطة النهاية المتأثرة:

curl.exe -v https://<domain>

إذا كان OpenSSL متاحاً:

openssl s_client -connect <domain>:443 -servername <domain>

الخروج المتوقع (نجاح)

* الاتصال SSL برغب باستخدام TLS1.2 / TLS1.3
* شهادة خادم:
* الموضوع: CN=www.google.com
* المُصدر: CN=GTS CA 1C3
> الحصول على / HTTP/1.1
< HTTP/1.1 200 OK

من المهم أولاً تحديد ما إذا كانت المشكلة تتعلق بـ العميل، خادم الوجهة، أو إعداد فحص TLS نفسه. 

استكشاف الأخطاء الشائعة

تنبيه:
المشاكل المدرجة أدناه تمثل سيناريوهات شائعة تم ملاحظتها في نشرات فحص TLS. العديد من هذه الأخطاء تكون عامة وقد تنطبق أو لا تنطبق مباشرةً على بيئتك الخاصة.
إذا كانت الأعراض أو الحلول الموضحة لا تتماشى مع حالتك، يوصى بتجميع بيانات تشخيصية (مثل SSS، HAR، وPCAP) من جهاز العميل ورفع تذكرة دعم للتحليل العميق.

استكشاف أخطاء التطبيقات بالفشل 

المشكلة: بعض التطبيقات تفشل في إنشاء اتصالات آمنة أو تتوقف عن العمل بعد تمكين فحص TLS.

توقع سلوكي:
التطبيقات التي تحتوي على قواعد أمان صارمة (مثل، التطبيقات المصرفية، أدوات أمن النقاط النهائية) قد تفشل اتصالاتها فوراً، تتعطل بصمت، أو تعيد محاولة الاتصالات بشكل متكرر. يحدث هذا لأن فحص TLS يقدم شهادة الرجل في الوسط (MITM)، والتي تم تصميم هذه التطبيقات تحديدها ورفضها.

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

إذا كان التطبيق أو الخادم يفرض تثبيت الشهادة أو متطلبات TLS صارمة، لا يمكن تطبيق فحص TLS. في مثل هذه الحالات، النهج الصحيح هو تجاوز تلك الحركة بشكل دائم.

مثال:
إذا كان التطبيق المالي يفشل في تسجيل الدخول ويعمل مباشرة بعد تجاوز فحص TLS لذلك المستخدم، هذا يؤكد عدم التوافق - أضف المجال الخاص بالتطبيق إلى قائمة التجاوز. 

استكشاف أخطاء تحذير شهادة متصفح

المشكلة: يرى المستخدمون تحذيرات الشهادة أو تفشل التطبيقات بعد تمكين فحص TLS.

توقع سلوكي:
قد يواجه المستخدمون تحذيرات المتصفح (مثل "الاتصال غير آمن") أو فشل اتصالات كاملة. قد يختلف السلوك عبر الأجهزة حسب ما إذا كانت الشهادة الخاصة بـ Cato مثبتة بشكل صحيح.

الحل:
تأكد من أن شهادة الجذر الخاصة بفحص TLS لـ Cato مثبتة وموثوقة على جميع نقاط النهاية. قم بالنشر باستخدام GPO/MDM وحقق من سلسلة الشهادة الكاملة على العميل.

إذا كانت تستخدم شهادات خاصة / داخلية، تأكد من أنها موثوقة بشكل صحيح أو اتبع إجراءات التعامل مع شهادة فحص TLS ذات الصلة.

إذا كان السلوك غير متسق، تحقق عبر تجاوز فحص TLS لمستخدم أو جهاز واحد لتأكيد تأثير الشهادة.

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

استكشاف أخطاء عدم توافق اسم المضيف

المشكلة: يواجه المستخدمون أخطاء الشهادة أو الاتصالات المحظورة بسبب عدم توافق اسم المضيف عند الوصول إلى مواقع معينة، خاصة عندما يكون فحص TLS ممكناً.

توقع سلوكي:
عندما يقدم الخادم شهادة لا يطابق اسمها العام (CN) أو SAN اسم المضيف المطلوب، تعتبر الاتصال غير صالح.

دون فحص TLS، يكتشف المتصفح مباشرةً عدم التوافق هذا ويعرض تحذير شهادة.

مع تمكين فحص TLS، ينشئ المتصفح جلسة TLS مع نقطة التجمع الخاصة بـ Cato بدلاً من خادم الأصل. تقوم النقطة بتوقيع الشهادة باستخدام خاصية الجذر Cato CA، مما يجعلها تبدو صالحة للعميل. نتيجة لذلك، لا يتم إظهار عدم التوافق في المتصفح، على الرغم من أن المشكلة لا تزال موجودة في الخلفية.

الحل:
تحقق من السلوك عبر تجاوز فحص TLS لمستخدم محدد أو عنوان IP. إذا كان المتصفح يظهر بعد ذلك خطأ عدم توافق اسم المضيف، فإن هذا يؤكد المصدر من خادم الوجهة.

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

  • السماح بالوصول عبر تجاوز فحص TLS للمجال المحدد، أو
  • قم بحظر الحركة بناءً على السياسة إذا كان عدم التوافق يعتبر خطرًا أمنيًا

تجنب قواعد التجاوز الواسعة واستخدم بدلاً من ذلك استثناءات مستهدفة للمجال/FQDN عند الحاجة.

مثال:
عند الوصول إلى https://www.testingmcafeesites.com/، يقدم الخادم شهادة ل platformsplat1.mcafee.com.

من دون فحص TLS، يقوم المتصفح بتمييز عدم توافق اسم المضيف فوراً.

مع تمكين فحص TLS، يرى المتصفح شهادة صالحة صادرة عن خاصية الجذر Cato CA لـ www.testingmcafeesites.com، لذا لا يتم عرض خطأ. ومع ذلك، فإن نقطة التجمع الخاصة بـ Cato تكتشف عدم التوافق في الخلفية وتفرض السياسة المحددة (حظر أو تحذير).

استكشاف مشاكل تحميل موقع أو تطبيق

المشكلة: تفشل المواقع في التحميل، يتم عرضها جزئيًا، أو تتصرف بشكل غير متوقع عند تمكين فحص TLS.

توقع سلوكي:

  • قد تتعطل الصفحات أو تتجمد أو تتحمل إلى ما لا نهاية أو يتم عرضها جزئيًا
  • قد تفشل تدفقات تسجيل الدخول / التصديق أو تدور في حلقات
  • قد تظهر بعض المواقع بطيئة بسبب التعامل مع فك تشفير TLS / إعادة التشفير
  • قد يكون السلوك غير متسق (مثل، يعمل على شبكة واحدة، يفشل عبر Cato)

يتم ملاحظة ذلك عادةً مع تطبيقات الويب الحديثة التي تستخدم قواعد أمان صارمة أو اعتماد TLS معقد.

الحل:
التحقق عبر تجاوز الفحص لتركيبة TLS لمستخدم معين أو عنوان IP للمصدر. إذا عمل الموقع عند تجاوزه، أنشئ استثناء نطاق/ FQDN المستهدف.

تجنب قواعد تجاوز عامة — حدد الاستثناءات لتقتصر على النطاقات المطلوبة فقط.

إذا كانت التطبيق يعتمد على آليات أمان صارمة (مثل الشهادات المثبتة أو معالجة TLS المتقدمة)، قد لا يتم دعم الفحص، ويكون التجاوز هو النهج الصحيح.

السيناريو – تطبيقات ويب حديثة (SaaS):
بعض منصات SaaS (مثل التطبيقات مع نطاقات خلفية متعددة/CDNs) قد تحمل جزئيًا (واجهة المستخدم تعمل، تفشل API). في هذه الحالات، حدد جميع النطاقات المطلوبة عبر HAR/DevTools وتأكد من التغطية الكاملة في قاعدة التجاوز.

استكشاف أخطاء شهادة Cato ومسألة التحقق منها

المشكلة: تظهر أخطاء ذات صلة بـ Cato TLS أثناء التصفح أو استخدام التطبيقات.

التوقعات السلوكية:

قد يواجه المستخدمون أخطاء عامة مثل: 

  • “فشل الاتصال الآمن”
  • “الشهادة غير موثوق بها”
  • إعادة تعيين غير متوقعة للاتصال أو انقطاعه

هذه الأخطاء عادةً ما تكون غير محددة ولا تشير بوضوح إلى ما إذا كانت المشكلة ناشئة من العميل أو الخادم أو عملية فحص TLS.

الحل:
التحقق من السلوك عبر تجاوز مؤقت لفحص TLS لمستخدم واحد أو عنوان مصدر IP.

  • إذا تم حل المشكلة عند التجاوز، يؤكد ذلك فشل التحقق من الشهادة أثناء الفحص.
  • في الحالات التي لا يتم التعرف فيها على الشهادات المنقولة أو الصادرة، قد يكون السبب عدم إدراجها بعد في حزمة الشهادات الموثوقة لـ Cato

كحل مؤقت، يُوصى بـ تجاوز فحص TLS للنطاق/التطبيق المتأثر أثناء فتح حالة دعم.

تقوم Cato بتحديث حزمة الشهادات الموثوقة الخاصة بها باستمرار وفقاً لمعايير الصناعة وأكثر السلطات الشهادات المستخدمة. إذا كانت الشهادة صالحة ويتم الوثوق بها على نطاق واسع، من المرجح أن تتم إضافتها في تحديث مستقبلي.

يجب أن يركز العلاج الدائم على:

  • ضمان أن الخادم يقدم سلسلة شهادات كاملة وصالحة
  • استخدام شهادات صادرة عن سلطات معروفة وموثوقة

إذا قدم الخادم سلسلة شهادات غير صحيحة أو غير كاملة، فإن فحص TLS سيقوم بحظر الاتصال بشكل صحيح. يجب أن يتم العلاج على جانب الخادم، أو تجاوز فحص TLS إذا لزم الأمر.

نطاقات تم الوثوق بها حديثاً / نُشرت مؤخراً

النطاقات الجديدة التي تم نشرها، تحديثها مؤخرًا، أو إعادة تصنيفها على الإنترنت قد لا يتم التعرف عليها بإستمرار عبر جميع محركات السمعة، السلطات الشهادات، أو مخازن الثقة.

يمكن أن يؤدي ذلك إلى سيناريوهات حيث يتم حظر حركة المرور أو وضع العلامات — ليس بسبب فشل TLS وحده، ولكن نتيجة التطبيق الأمني لسياسات جدار الحماية على الإنترنت أو لعدم اكتمال الثقة في الشهادة.

التوقع السلوكي:
قد تكون هذه النطاقات:

  • تم تصنيفها بشكل غير صحيح أو بشكل غير متسق عبر محركات الأمان
  • تقديم شهادات لم يتم نشرها بالكامل أو موثوقاً بها على الصعيد العالمي
  • إثارة أخطاء TLS أثناء الفحص بسبب سلاسل الثقة غير المكتملة
  • الحظر استنادًا إلى السياسة بدلاً من مشكلة اتصال فعلية

هذا السلوك شائع بعد وقت قصير من تفعيل النطاق أو إجراء تغييرات عليه.

الحل:

  • تحقق من الشهادة مباشرةً من نقطة النهاية لتأكيد الشرعية
  • إذا تم التحقق من النطاق على أنه آمن:
    • أعد تصنيفه إلى فئة مسموحة بناءً على متطلبات السياسة، أو
    • أنشئ قاعدة سماح/تجاوز مستهدفة (تجنب الاستثناءات الواسعة)
  • اعتبر قواعد التجاوز كحل مؤقت حيثما كان ذلك ممكنًا
  • قَيّم النطاق بعد مرور بعض الوقت، فور تأسيس سمعته وثقة الشهادة على الصعيد العالمي

ملاحظة رئيسية:
حتى إذا كان النطاق شرعي، فقد يسبب انتشار الشهادة غير المكتمل أخطاء ذات صلة بـ TLS. في هذه الحالات، السلوك متوقع ويجب التعامل معه من خلال تعديلات السياسة المسيطر عليها بدلاً من افتراض وجود سوء تكوين.

السيناريو – سلسلة شهادات غير مكتملة:
قد يعمل الموقع مباشرة في المتصفح (بسبب المؤقتات المخزنة) ولكنه يفشل تحت فحص TLS. هذا يشير إلى أن الخادم لا يقدم السلسلة الكاملة للشهادة. الحل هو تصحيح إعدادات الخادم أو تجاوز النطاق.

البروتوكولات غير المدعومة والأنظمة القديمة

المشكلة:
تفشل الاتصالات للتطبيقات أو الأنظمة التي تستخدم إصدارات TLS القديمة أو مجموعات الشفرات الضعيفة التي لا تدعم تحت فحص TLS.

التوقع السلوكي:
تحدث الإخفاقات عادةً أثناء مصافحة TLS وتكون مرئية مباشرة في المتصفح أو العميل.

تتضمن أخطاء المتصفح الشائعة:

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 طلب سيئ
لم يتم إرسال الشهادة المطلوبة

في بعض الحالات:

  • قد تفشل الصفحة في التحميل بالكامل
  • قد يعيد الاتصال التعيين فوراً
  • قد تفشل التطبيقات السميكة أو التطبيقات القديمة بصمت أو تعرض أخطاء اتصال عامة

يحدث هذا بسبب عدم قدرة العميل أو الخادم على التفاوض على إصدار متوافق من TLS أو مجموعة شفرات مع Cato PoP الذي يعمل ك mitm.

في الأحداث، ستلاحظ أيضًا حقل خطأ TLS Description مليء بمعلومات محددة. 

لمزيد من المعلومات عن الأخطاء يُرجى زيارة فهم أخطاء TLS. 

الحل:

  • تجاوز مؤقت لفحص TLS لمستخدم معين أو عنوان مصدر IP للتحقق من السلوك
  • إذا عمل التطبيق عند التجاوز → التحقق من عدم توافق التفاوض خلال الفحص TLS.

بعد ذلك، تحقق من قدرات TLS باستخدام أدوات خارجية مثل https://www.ssllabs.com/ssltest/

قارن النتائج مع سياسة فحص TLS الخاصة بك:

  • إصدار TLS الأدنى المسموح به
  • مستوى تطبيق مجموعة الشفرات

إذا تم التأكيد:

  • قم بتحديث أو ترقيه التطبيق أو الخادم لدعم إصدارات TLS الحديثة ومجموعات الشفرات القوية
  • إذا لم تكن الترقيات ممكنة، قم بتكوين تجاوز مستهدف لفحص TLS للتطبيق أو النطاق المتأثر

ملاحظة:
بشكل افتراضي، تسمح Cato بمجموعة واسعة من إصدارات TLS ومجموعات الشفرات. ومع ذلك، يمكن للمسؤولين تطبيق ضوابط أكثر صرامة في سياسة فحص TLS (مثل إصدار TLS الأدنى أو قوة الشفرات)، مما قد يتسبب في فشل التطبيقات القديمة. للمزيد من المعلومات اقرأ هنا.

 

السيناريو – تطبيق داخلي قديم:
قد يفشل تطبيق داخلي أو تابع لجهات خارجية قديم فقط عند تمريره عبر Cato مع تمكين فحص TLS ولكن يعمل عند تجاوزه. هذا يشير عادة إلى الاعتماد على إصدارات TLS القديمة، مما يتطلب إما ترقية التطبيق أو تجاوز دائم.

استكشاف مشكلات TLS الخاصة بالنظام التشغيلي (القيود المتوقعة)

المشكلة: مشاكل الاتصال، سلوك غير متسق، أو نقص في رؤية فحص TLS على أنظمة تشغيل وأنواع أجهزة معينة (مثل الهاتف المحمول، BYOD، لينكس).

التوقعات السلوكية:

يتفاوت السلوك بشكل كبير حسب النظام التشغيلي وتصميم التطبيق.

بالنسبة لأجهزة أندرويد ولينكس، يتم التجاوز تلقائيًا لفحص TLS بسبب قيود الثقة في الشهادات وسلوك التطبيقات. ومع ذلك، تتيح التكوينات الأحدث (عبر الإعدادات المتقدمة في CMA) للمسؤولين فرض فحص TLS على هذه الأنظمة، بشرط أن تثبت الثقة في الشهادة بشكل صحيح.

بالنسبة لأجهزة iOS، يتم دعم فحص TLS، لكن العديد من التطبيقات (مثل منصات الشبكات الاجتماعية مثل Instagram و Facebook وتطبيقات مشابهة) يتم تجاوزها تلقائيًا بسبب تثبيت الشهادات وعدم توافقات معروفة. التطبيقات الأخرى التي تفرض التحقق الصارم قد تفشل وتتطلب تكوين تجاوز يدوي.

بشكل عام:

  • قد تعمل المتصفحات كما هو متوقع بمجرد تثبيت شهادة Cato
  • قد تفشل التطبيقات الأصلية/المتنقلة فورًا بسبب تثبيت الشهادات أو متاجر الثقة المقيدة
  • قد يختلف السلوك لكل تطبيق، حتى على نفس الجهاز

الحل:

هذه السلوكيات عادةً ما تكون متوقعة وموجهة من قبل النظام الأساسي، وليست علامة على سوء التكوين.

  • تطبيق فحص TLS في المقام الأول على الأجهزة المدارة حيث يتم التحكم في نشر الشهادات
  • استخدام حلول MDM لتثبيت شهادة Cato على مستوى النظام (حيث يتم دعمها)
  • كن على علم بـ قواعد تجاوز الشائعة للتطبيقات والمنصات المعروفة
  • بالنسبة للتطبيقات التي تفشل بسبب تثبيت الشهادات أو التحقق الصارم، قم بتكوين تجاوز مستهدف للفحص TLS
  • عند فرض فحص TLS على أنظمة مثل Android أو Linux، تحقق من التوافق بعناية قبل النشر بشكل واسع

السيناريو – فشل تطبيق متحرك:
يفشل تطبيق الهاتف المحمول (مثل التطبيق البنكي أو تطبيق أمني) في الاتصال عبر Cato بينما يعمل المتصفح. التطبيق يفرض تثبيت الشهادات ولا يثق في شهادة Cato. هذا متوقع — الإجراء الصحيح هو تجاوز فحص TLS لتلك التطبيق أو الخدمة.

رفع الحالات إلى دعم Cato

في حال كان فحص TLS إلزاميًا للتطبيق بسبب اكتفاء أو أسباب تنظيمية أو إذا كنت تعتقد أن حظر TLS كان غير متوقع، يُرجى تقديم تذكرة دعم مع نتائج خطوات الاستكشاف المذكورة أعلاه. يرجى تضمين المعلومات التالية في التذكرة:

  • تفاصيل المشكلة المكتسبة والتأثير العام على المستخدمين. الوقت/المنطقة الزمنية للمستخدم الذي يواجه المشكلة. 
  • الأحداث ذات الصلة وتكوين قواعد جدار الحماية/TLS.
  • قم بإعادة إنتاج المشكلة وتشغيل خدمة الدعم الذاتي. قم بتضمين رقم التذكرة الذي تم إنشاؤه بواسطة الأداة.

 

هل كان هذا المقال مفيداً؟

0 من 0 وجدوا هذا مفيداً

لا توجد تعليقات