شهادات الأمان SSL: الانتهاء والسلاسل والأخطاء التي تكلفك زوارك

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

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

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

انتهاء الصلاحية: الأتمتة التي تتوقف بهدوء

تمتد صلاحية شهادات Let's Encrypt لمدة 90 يوماً، وهي مصممة لتتجدد تلقائياً عند بلوغ اليوم 60. وتزيل هذه الأتمتة المخاطر تماماً — حتى يتعطل أمر التجديد المجدول (cron job) ولا ينتبه أحد لذلك طوال شهر كامل.

تتعطل عمليات التجديد لأسباب تقنية روتينية: قاعدة جدار حماية تحجب طلب التحقق، أو تغيير مسار المجلد الجذري (webroot) أثناء التحديث، أو انتهاء صلاحية رمز API لدى مزود DNS، أو امتلاء مساحة القرص، أو تعطل حزمة certbot إثر ترقية نظام التشغيل. لا يعلن أي من هذه الأعطال عن نفسه بإنذار. بل تتوقف الشهادة عن التجديد بهدوء، وبعد ثلاثين يوماً يصبح الموقع محاصراً بشاشة تحذير مخيفة.

القاعدة الذهبية لحمايتك: راقب تاريخ انتهاء الشهادة الحية بشكل مستقل تماماً عن عملية التجديد. فإذا كان نظام التنبيه لديك يكتفي بسؤال "هل نجح تشغيل certbot؟"، فأنت تأتمن الآلية ذاتها المعرضة للفشل. أما إذا كان التنبيه هو "هل تنتهي صلاحية الشهادة النشطة على الموقع خلال 14 يوماً؟"، فستلتقط كافة سيناريوهات الفشل، بما فيها الأخطاء التي لم تكن تخطر ببالك.

اضبط هذا التنبيه عند بقاء 14 يوماً. فالشهادة التي تمتد 90 يوماً وكان ينبغي لها أن تتجدد في اليوم 60 ولا يزال متبقياً في صلاحيتها 14 يوماً فقط هي شهادة معطلة يقيناً، وسيكون أمامك أسبوعان كاملان لإصلاحها بهدوء ودون ضغوط.

تغطية أسماء النطاقات: مشكلة www

تغطي الشهادة الأمنية نطاقات محددة بالاسم، وتُسرد في حقل الأسماء البديلة للموضوع (Subject Alternative Name - SAN). فالشهادة الصادرة للنطاق example.com لا تغطي النطاق www.example.com ما لم تكن www مدرجة صراحة بالاسم.

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

افحص النطاقين معاً، في كل مرة وبلا استثناء.

الشهادات الشاملة (Wildcard) تطابق مستوى نطاقياً واحداً فقط. حيث تغطي *.example.com النطاق shop.example.com، لكنها لا تغطي eu.shop.example.com. كما أنها لا تغطي النطاق المجرد example.com في حد ذاته — بل يجب إدراجه كعنصر منفصل، وهو ما تقوم به معظم جهات الإصدار تلقائياً، ولكن ليس جميعها.

مشاكل السلسلة: تعمل على الحاسوب وتتعطل على الجوال

تُوقَّع شهادتك بواسطة شهادة وسيطة (intermediate certificate)، والتي تكون بدورها موقعة من شهادة جذرية (root certificate) موثوقة مسبقاً في مخزن المتصفح. ويجب على خادمك إرسال هذه الشهادة الوسيطة. فالشهادة الجذرية موجودة بالفعل لدى العميل؛ بينما الشهادة الوسيطة ليست كذلك.

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

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

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

إصدارات بروتوكول TLS

• TLS 1.3 — البروتوكول القياسي الحالي. ينجز المصافحة الأمنية في رحلة اتصال شبكية واحدة بدلاً من اثنتين، مما يحقق تحسناً ملموساً في السرعة عند كل اتصال جديد، بالإضافة إلى أمانه المتفوق.
• TLS 1.2 — الحد الأدنى المقبول حالياً.
• TLS 1.1 و 1.0 — بروتوكولات قديمة مهجورة، ترفضها المتصفحات الحديثة، وتتسبب في رسوب فوري باختبارات الامتثال لمعايير الدفع الإلكتروني (PCI DSS).

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

مقارنة الشهادات: المجانية مقابل المدفوعة

من منظور التشفير وحماية البيانات، فهما متطابقتان تماماً. تستخدم شهادات Let's Encrypt المجانية نفس خوارزميات التشفير وأحجام المفاتيح، وتتلقى المعاملة البرمجية ذاتها في كافة المتصفحات كشهادة تكلف مئات الدولارات سنوياً.

ما تضيفه الشهادات المدفوعة هو التحقق المؤسسي (OV/EV) — أي تأكيد جهة الإصدار قانونياً أن شركتك قائمة فعلياً وتمتلك هذا النطاق، بدلاً من الاكتفاء بالتحقق من ملكيتك للنطاق فقط (DV).

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

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

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

العمر الزمني للشهادات يتقلص باستمرار

ترفض المتصفحات الحديثة الآن الشهادات الصادرة لأكثر من 398 يوماً، ويتجه قطاع الويب عالمياً نحو فترات صلاحية أقصر بكثير — حيث تتقدم مقترحات لتقليصها إلى 90 يوماً ثم إلى 47 يوماً كحد أقصى مستقبلاً.

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

المحتوى المختلط (Mixed Content)

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

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

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

ما يجب فحصه، ودورية الفحص الموصى بها

شهرياً، وبشكل تلقائي:

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

بعد إجراء أي تعديل على الاستضافة أو إعدادات CDN:

• فحص كافة النقاط المذكورة أعلاه، مع التأكد من خلو الصفحات الرئيسية من المحتوى المختلط

مرة واحدة فقط، ولا داعي للتفكير فيها مجدداً:

• ضبط سجل CAA في DNS لتحديد جهات إصدار الشهادات المعتمدة والمسموح لها فقط بإصدار شهادات لنطاقك. يستغرق ذلك دقيقتين فقط، ويضمن عجز أي جهة إصدار غير مصرح لها عن توليد شهادة لموقعك حتى لو تعرضت للاحتيال.

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

الخلاصة

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

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

فتح الأداة فحص SSL اقرأ شهادة النطاق الحية: تاريخ الانتهاء، الجهة المصدرة، تغطية النطاقات، وإصدار TLS. →