«Your connection is not private» على موقعك: أسباب خطأ الشهادة وحلّها

ظهور رسالة «Your connection is not private» (أو باللغة العربية: «الاتصال بهذا الموقع الإلكتروني ليس خاصاً») مع رمز قفل أحمر مشطوب أو شاشة حمراء داكنة يعني أن متصفح الزائر حاول إنشاء جلسة اتصال مشفرة عبر بروتوكول HTTPS مع خادم موقعك، لكنه اصطدم بخلل جوهري في شهادة الأمان (SSL/TLS) منعه من تأكيد هوية الموقع وتشفير حزم البيانات بثقة. لحماية الزائر من هجمات انتحال الهوية واعتراض البيانات الحساسة، يمنعه المتصفح تماماً من الوصول للمحتوى ويعرض هذا التحذير القاطع.

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

الخطوة الأولى: قراءة رمز الخطأ الدقيق أسفل شاشة التحذير#

عندما تظهر شاشة التحذير في متصفح مثل Google Chrome أو Microsoft Edge، انقر على زر إعدادات متقدمة (Advanced)؛ ستجد كوداً تقنياً يبدأ بـ NET::ERR_CERT_... يحدد سبب المشكلة بدقة متناهية:

السبب 1: انتهاء صلاحية شهادة SSL (NET::ERR_CERT_DATE_INVALID)#

الشهادات المجانية الأكثر انتشاراً عالمياً (مثل Let's Encrypt و AutoSSL في cPanel) صالحة لمدة تسعين يوماً فقط وفق المعايير الأمنية العالمية، وتعتمد على مهمة مجدولة (Cron Job أو Systemd Timer) لتجديدها تلقائياً قبل ثلاثين يوماً من انتهائها. إذا توقفت مهمة التجديد بسبب تعديل في جدار الحماية أو خلل في خادم الويب، تنتهي الشهادة فجأة ويظهر هذا التحذير لكافة الزوار.

التشخيص البرمجي عبر الطرفية:#

افحص تاريخ صلاحية الشهادة الفعلي المثبتة على السيرفر بأمر OpenSSL:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

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

الحل العملي:#

في خوادم VPS أو الخوادم المخصصة باستخدام Certbot:

# فحص حالة مؤقت التجديد التلقائي في نظام لينكس
sudo systemctl status certbot.timer

# تجربة التجديد دون إصدار فعلي لقراءة سبب الفشل إن وجد
sudo certbot renew --dry-run

# بعد إصلاح سبب الفشل: تجديد الشهادات القريبة من الانتهاء فعلياً
sudo certbot renew

# إعادة تحميل خادم الويب لتطبيق الشهادة الجديدة في الذاكرة الحية
sudo systemctl reload nginx
# أو في خوادم أباتشي:
sudo systemctl reload apache2

لا حاجة إلى certbot renew --force-renewal لحل المشكلة، ولا تضعه في مهمة دورية: فهو يجدد كل شهادة في كل تشغيل بصرف النظر عن تاريخ انتهائها، وينبّه دليل Certbot الرسمي إلى أن ذلك يصطدم سريعاً بحدود الإصدار لدى الجهة المانحة.

في الاستضافات التي تستخدم لوحة تحكم cPanel:

1. ادخل إلى cPanel وافتح أداة SSL/TLS Status؛ فهي تعرض بحسب توثيق cPanel حالة شهادة كل نطاق وآخر مرة شُغّل فيها AutoSSL له، وخطأ AutoSSL إن وُجد.
2. لتشغيل AutoSSL يدوياً تحتاج صلاحية WHM: افتح WHM » Home » SSL/TLS » Manage AutoSSL، ثم تبويب Manage Users واضغط زر Check أمام الحساب، أو Run AutoSSL for All Users لكل الحسابات، كما في توثيق Manage AutoSSL. وإن كانت استضافتك مشتركة بلا WHM، فاطلب ذلك من الدعم الفني.
3. انتظر بضع دقائق وسيقوم النظام بالتحقق من ملفات النطاق وتثبيت شهادة جديدة مجاناً وتحديث حالة الأمان تلقائياً.

السبب 2: تفاوت اسم النطاق (NET::ERR_CERT_COMMON_NAME_INVALID)#

يحدث هذا الخطأ عندما يدخل الزائر إلى الموقع باستخدام البادئة https://www.example.com بينما الشهادة تم إصدارها للنطاق المجرد https://example.com فقط (أو العكس)، أو عندما يعيد خادم الويب شهادة افتراضية تابعة لاسم الاستضافة الرئيسي (Server Hostname) لغياب دعم خاصية SNI.

التشخيص:#

افحص الأسماء المسجلة رسمياً داخل الشهادة الحالية:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A 2 "Subject Alternative Name"

يجب أن ترى في سطر النتيجة كلا الاسمين بوضوح تام: DNS:example.com, DNS:www.example.com.

الحل:#

أعد إصدار الشهادة لتشمل كلا الاسمين معاً في أمر واحد:

# لخوادم Nginx
sudo certbot --nginx -d example.com -d www.example.com

# لخوادم Apache
sudo certbot --apache -d example.com -d www.example.com

السبب 3: نقص شهادة السلسلة الوسيطة (NET::ERR_CERT_AUTHORITY_INVALID)#

لكي تثق متصفحات الهواتف والأنظمة بشهادتك، يجب أن تتحقق من تسلسل الثقة (Trust Chain) بدءاً من نطاقك، مروراً بالجهة الوسيطة المانحة (Intermediate CA)، وصولاً إلى السلطة الجذرية العالمية الموثوقة (Root CA) المخزنة في نظام التشغيل. إذا قمت بربط ملف الشهادة الفردي فقط (cert.pem) في إعدادات خادم الويب بدلاً من ملف السلسلة الكاملة، فسترفض هواتف أندرويد وبعض المتصفحات الاتصال لعدم اكتمال السلسلة.

الحل الصحيح في خوادم Nginx:#

افتح ملف إعدادات النطاق:

sudo nano /etc/nginx/sites-available/example.com

تأكد من أن سطر ssl_certificate يشير صراحة إلى ملف fullchain.pem وليس cert.pem:

# التكوين القياسي الصحيح لسلسلة الثقة:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

الحل في خوادم Apache (الإصدار 2.4.8 فأحدث):#

SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

السبب 4: تفاوت ساعة وتاريخ الخادم (Server Clock Desynchronization)#

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

التشخيص والحل عبر خدمة NTP:#

افحص توقيت الخادم وحالة المزامنة التلقائية:

timedatectl

إذا وجدت سطر System clock synchronized: no، فعّل المزامنة الفورية مع خوادم التوقيت العالمية الموحدة:

sudo timedatectl set-ntp on

السبب 5: قيود بروتوكول HSTS واختفاء زر المتابعة#

في كثير من الحالات، يلاحظ المستخدم اختفاء زر «متابعة إلى الموقع (غير آمن)» في متصفح كروم. يرجع ذلك إلى تفعيل ميزة HSTS (HTTP Strict Transport Security)؛ حيث يتذكر المتصفح أن هذا النطاق اشترط سابقاً عدم فتح صفحاته إطلاقاً في حال وجود أدنى شك في سلامة الشهادة. لحل هذه المعضلة يجب تصحيح الشهادة على السيرفر فوراً لأن المتصفح لن يقبل أي تجاوز يدوي.

جدول تشخيص رموز أخطاء SSL والعلاج المباشر#

كيف تتأكد أن الشهادة تعمل وموثوقة عالمياً؟#

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

1. فحص الاستجابة العميقة بـ cURL: نفذ الأمر التالي في الطرفية:

   curl -Iv https://example.com

   ابحث عن عبارة: SSL certificate verify ok. إذا ظهرت، فالاتصال مشفر والشهادة مقبولة نظامياً.
2. الفحص عبر أداة SSL Labs العالمية: افتح موقع ssllabs.com/ssltest واكتب اسم نطاقك. يقدم هذا الموقع فحصاً دقيقاً وشاملاً لسلسلة الثقة وبروتوكولات التشفير؛ احرص على أن يحصل موقعك على درجة A أو A+ لضمان أقصى موثوقية وأمان.

المصادر#

• التوثيق الرسمي لمؤسسة Let's Encrypt لتثبيت وتجديد شهادات الأمان
• دليل استخدام Certbot الرسمي: التجديد و--dry-run وتحذير --force-renewal
• دليل مؤسسة موزيلا الرسمي لتكوين وتأمين خوادم الويب ببروتوكولات TLS الحديثة
• دليل مساعدة متصفح Google Chrome الرسمي لتشخيص أخطاء شهادات الأمان
• توثيق cPanel لواجهة Manage AutoSSL في WHM