TLS Errors في المتصفح: من شهادة منتهية إلى سلسلة ثقة ناقصة

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

ابدأ بكود الخطأ لا برسالة الصفحة

سجّل net error أو certificate error المحدد مثل CERT_DATE_INVALID أو CERT_AUTHORITY_INVALID أو CERT_COMMON_NAME_INVALID. كل كود يقلص مساحة البحث. لا تعتبر كل صفحة حمراء مشكلة شهادة من الموقع نفسه، لأن MITM proxy أو antivirus أو enterprise root قد يغيّر الشهادة التي يراها Chromium.

افحص السلسلة كاملة

تحقق من leaf certificate وال ـintermediate وال ـroot والمسار الذي اختاره المتصفح. قد يرسل السيرفر شهادة صحيحة لكنه ينسى intermediate، وقد ينجح على جهاز بسبب cache قديم ويفشل على جهاز جديد. قارن issuer و SAN و validity و chain بين بيئة سليمة وبيئة متأثرة.

اختبر الوقت والاسم والمسار

ساعة النظام الخاطئة قد تجعل شهادة سليمة تبدو غير صالحة. كذلك يجب التأكد أن ال ـhostname الذي يراه Chromium هو المطلوب فعلًا وليس redirect أو proxy gateway. عند استخدام HTTPS proxy أو TLS inspection، افحص الشهادة قبل وبعد تعطيل الوسيط في بيئة اختبار آمنة.

لا تتجاوز الخطأ كحل دائم

خيارات تجاهل certificate errors مفيدة فقط في بيئات اختبار محدودة، لكنها تخفي المشكلة وتلغي ضمان الهوية. في الإنتاج يجب إصلاح السلسلة أو الثقة أو إعداد البروكسي. أي استثناء يجب أن يكون ضيق النطاق، موثقًا، ومؤقتًا.

راقب الاختلاف بين البروفايلات

إذا فشل TLS في بروفايل واحد فقط، ابحث عن proxy مختلف، client certificate، extension تتدخل في الشبكة، أو partition له إعدادات خاصة. وإذا فشل في كل البروفايلات على جهاز واحد، انتقل إلى trust store والنظام وبرامج الحماية. هذا الفصل يوفر وقتًا كبيرًا قبل تعديل كود المتصفح.

اجمع الدليل قبل تغيير الإعدادات

في «TLS Errors في المتصفح: من شهادة منتهية إلى سلسلة ثقة ناقصة» اجمع timestamp وكود الخطأ والمكوّن والبروفايل ومسار الشبكة قبل أي تعديل. بعد ذلك قارن حالة سليمة بحالة متأثرة مع تغيير عامل واحد فقط، مثل proxy أو extension أو policy. إذا اختفى الخطأ، أعد العامل مرة أخرى للتأكد من السببية بدل الاكتفاء بتحسن مؤقت. احفظ النتيجة في checklist أو test يمكن تشغيله بعد الإصلاح. التشخيص الأمني الجيد يقلل البيانات التي يجمعها، لكنه يحتفظ بما يكفي لإثبات أين بدأت المشكلة وأين انتهت دون تخزين cookies أو tokens أو محتوى حسابات.

معيار القبول قبل الإغلاق

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

حالة فشل يجب اختبارها

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