لماذا لا يزال يظهر تحذير «غير آمن» بعد تثبيت شهادة أمان SSL؟

بعد إتمام تثبيت شهادة أمان SSL، إذا كان المتصفح لا يزال يعرض «الاتصال غير آمن» أو «الشهادة غير صالحة»، أو لا تظهر أيقونة القفل في شريط العنوان، فعادةً لا تكون المشكلة في ملف الشهادة نفسه، بل في عدم اكتمال سلسلة النشر، أو عدم تطابق اسم النطاق الذي تتم زيارته، أو استمرار الصفحة في تحميل موارد HTTP، أو عدم تمكين HTTPS بشكل صحيح على الخادم. قد تؤثر هذه المشكلات في ثقة الزوار بالموقع، وقد تؤدي أيضاً إلى قيام المتصفح بحظر تسجيل الدخول أو إرسال النماذج أو إعادة توجيه الدفع، أو عرض تحذيرات بالمخاطر.

عند استكشاف المشكلة، لا تكتفِ بالتحقق من «هل تم شراء الشهادة وهل تم رفعها». ينبغي الاعتماد على الشهادة التي يصل إليها المتصفح فعلياً، ومسار الوصول، وموارد الصفحة: ابدأ بتأكيد نوع الخطأ، ثم تحقّق من اسم النطاق وسلسلة الشهادات والمنفذ وقواعد إعادة التوجيه، وأخيراً عالج المحتوى المختلط. بهذه الطريقة، يمكن تجنب استبدال الشهادة مراراً دون حل المشكلة.

تحقق أولاً من تنبيه المتصفح لتحديد الطبقة التي تقع فيها المشكلة

انقر على تنبيه «غير آمن» أو أيقونة القفل في شريط عنوان المتصفح لعرض تفاصيل الشهادة ونص رسالة الخطأ المحددة. تختلف اتجاهات المعالجة باختلاف الظواهر.

تُعد وحدة تحكم المتصفح مهمة أيضاً. إذا ظهرت عبارة «Mixed Content» في وحدة التحكم، فهذا يعني أن الصفحة الرئيسية فُتحت عبر HTTPS، لكن بعض مواردها لا تزال تُطلب عبر HTTP؛ وإذا ظهر خطأ في اسم الشهادة أو فشل في التحقق من سلسلة الشهادات، فينبغي العودة إلى طبقة نشر الخادم للتحقق.

عدم تطابق اسم النطاق هو أكثر مشكلة يسهل تجاهلها بعد تثبيت شهادة أمان SSL

تكون الشهادة صالحة فقط لأسماء النطاقات المدرجة فيها، ولا تغطي جميع الصيغ تلقائياً. على سبيل المثال، إذا كانت الشهادة صادرة لـwww.example.com فقط، فقد يظهر خطأ عند زيارة example.com مباشرةً؛ كما أن شهادة النطاق الواحد العادية الصادرة للنطاق الرئيسي لا تغطي عادةً النطاقات الفرعية مثل shop.example.com وen.example.com.

تحقق من «أسماء البدائل للموضوع (SAN)» أو «أسماء البدائل للمستخدم» في تفاصيل الشهادة، وقارنها واحداً تلو الآخر بمداخل الزيارة الفعلية، مع التأكد على الأقل مما يلي:

• هل يغطي النطاقان مع www وبدونه www كليهما، أم تم توحيد إعادة التوجيه بينهما؛
• هل تستخدم المواقع متعددة اللغات، والمواقع الفرعية للمتجر، ومواقع التنزيل، ولوحات الإدارة، وغيرها، نطاقات فرعية مستقلة؛
• هل يمكن للمستخدمين الوصول مباشرةً عبر اسم نطاق قديم أو نطاق اختبار أو عنوان IP؛
• هل تم نشر الشهادة في ربط اسم النطاق أو إعداد المضيف الافتراضي الذي يقدم الخدمة الخارجية الحالية.

لا تحاول إخفاء عدم تطابق الاسم عبر «إعادة توجيه جميع أسماء النطاقات إلى HTTPS». تحدث إعادة التوجيه بعد مصافحة TLS، ويجب على المتصفح أولاً التحقق من شهادة اسم النطاق الحالي؛ لذلك، إذا لم يتطابق اسم الشهادة، فسيظهر التحذير أولاً. الإجراء الصحيح هو توسيع نطاق تغطية الشهادة لمداخل الوصول الفعلية، أو توحيد أسماء النطاقات على مستوى DNS ومدخل الموقع وروابط الترويج.

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

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

في بيئة Nginx، تتمثل المشكلة الشائعة في أن ssl_certificate يشير إلى ملف شهادة منفصل بدلاً من ملف سلسلة كاملة يتضمن شهادة الخادم والشهادات الوسيطة؛ أما في Apache، فيجب التأكد من أن إعداد سلسلة الشهادات المقابل يتوافق مع متطلبات الإصدار الحالي. في بيئة لوحة التحكم، استخدم ملف «سلسلة الشهادة الكاملة» أو «fullchain» أو «CA Bundle» الذي توفره جهة إصدار الشهادة، بدلاً من لصق محتوى الشهادة الأول فقط.

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

تم تمكين HTTPS، فلماذا لا تزال الصفحة تظهر بأنها غير آمنة؟

يرتبط هذا الوضع غالباً بالمحتوى المختلط. يتم نقل HTML الصفحة عبر HTTPS، لكن الصور وJavaScript وCSS والفيديو والخطوط وأكواد الإحصاءات وiframe أو عناوين الواجهات لا تزال مكتوبة بصيغة http://. تحظر المتصفحات الحديثة مباشرةً بعض المحتويات النشطة، مثل النصوص البرمجية وطلبات XHR؛ أما بعض موارد الصور أو الوسائط، فقد تسمح بتحميلها ولكن تخفض حالة الأمان.

ينبغي أن يبدأ ترتيب المعالجة من شفرة مصدر الصفحة ووحدة تحكم المتصفح لتحديد عنوان المورد المحدد، ثم التحقق من مصدر المورد:

1. يجب تحويل الموارد الثابتة داخل الموقع إلى عناوين HTTPS مطلقة، أو استخدام مسارات نسبية مناسبة للموقع الحالي؛
2. يجب فحص روابط HTTP المضمنة بشكل ثابت على دفعات في القوالب ومحتوى النصوص الغنية وتفاصيل المنتجات والمقالات السابقة؛
3. يجب التأكد من أن النصوص البرمجية الخارجية والخرائط ونافذة خدمة العملاء وتضمين الفيديو ومكونات النماذج تدعم HTTPS؛
4. ينبغي أيضاً نشر شهادات صالحة لنطاقات الواجهات ونطاقات تخزين الملفات وCDN الصور، ولا يكفي تعديل اسم نطاق الصفحة الرئيسية فقط؛
5. بعد التعديل، امسح ذاكرة التخزين المؤقت للموقع وCDN والمتصفح، ثم أعد الاختبار.

لا يُنصح بالاعتماد فقط على سياسة المتصفح «الترقية التلقائية للطلبات غير الآمنة». يمكن استخدامها كتدبير انتقالي، لكنها لا تضمن تحميل جميع الموارد بشكل صحيح؛ وإذا كانت موارد الجهات الخارجية لا تدعم HTTPS، فقد يؤدي ذلك إلى فقدان التنسيقات أو تعطل الوظائف أو فشل طلبات البيانات.

تحقق من إعدادات استماع الخادم وإعادة التوجيه والعُقد المتعددة

صحة الشهادة لا تعني أن المنفذ 443 تتم خدمته بالفعل من الموقع الصحيح. ينبغي التأكد من أن جدار حماية الخادم ومجموعة الأمان وخدمة Web جميعها تسمح بالوصول إلى المنفذ 443، وأن هذا المنفذ مرتبط بالشهادة المقابلة لاسم النطاق المستهدف. في بيئات IP المشتركة والمواقع المتعددة، قد يؤدي خلل إعداد SNI إلى إرجاع الخادم شهادة موقع آخر، مما يسبب عدم تطابق اسم النطاق.

يجب كذلك التحقق من إعادة التوجيه من HTTP إلى HTTPS. الحالة المثالية هي أنه بعد زيارة إصدار http://، يتم الانتقال عبر إعادة توجيه واحدة 301 أو 308 إلى عنوان HTTPS القياسي؛ ولا ينبغي أن تحدث حلقة من HTTP إلى HTTPS ثم العودة من HTTPS إلى HTTP، كما لا ينبغي أن تنتقل الصفحات ذهاباً وإياباً بين النطاق مع www والنطاق بدونه. ويجب التحقق بشكل منفصل من صفحة تسجيل الدخول وصفحة إرسال النموذج وصفحة استدعاء الدفع ومدخل لوحة الإدارة على وجه الخصوص.

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

تجنب المشكلات المتكررة المتمثلة في «ظهور خطأ مباشرة بعد التجديد»

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

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