كيف أصلحت مشاكل شهادة SSL على موقعي الإلكتروني - دليل شامل

تخيّل الموقف: كنت قد ثبّتُّ للتو شهادة SSL على موقعي الإلكتروني shadynagy.com. بدا كل شيء رائعًا من جانبي — الشهادة صالحة، صادرة من Sectigo، ولا يزال أمامها وقت طويل قبل انتهاء صلاحيتها (265 يومًا!). لكن عندما أجريت اختبار SSL سريعًا على WhyNoPadlock.com، ظهرت لي بعض علامات X الحمراء المحبطة:

❌ فرض HTTPS: الموقع لا يفرض استخدام SSL ❌ شهادة وسيطة غير صالحة: الشهادة الوسيطة (الحزمة) مفقودة

شعرتُ بخيبة أمل كبيرة. ما فائدة شهادة SSL إن لم تعمل بشكل صحيح؟ قد يرى زوّار موقعي تحذيرات أمنية، وقد تُخفّض محركات البحث ترتيبي، والأسوأ من ذلك — قد يبدو موقعي غير احترافي.

لكن الخبر السار: أصلحتُ كل شيء، وسأوضح لك بالضبط كيف فعلت ذلك خطوة بخطوة.

فهم ما حدث من خطأ

قبل الخوض في الحلول، دعنا نفهم ما تعنيه هذه الأخطاء فعليًا:

المشكلة الأولى: الشهادة الوسيطة مفقودة

ما هي الشهادة الوسيطة؟

فكّر في شهادات SSL كسلسلة ثقة:

يثق متصفحك بجهات إصدار جذرية معيّنة (مثل Sectigo)
تُصدر هذه الجهات شهادات “وسيطة” لجهات فرعية
تُصدر هذه الجهات الفرعية شهادة موقعك الإلكتروني

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

التأثير الفعلي:

بعض المتصفحات تعرض تحذيرات أمنية
الأجهزة المحمولة غالبًا ما تفشل في الاتصال
يبدو موقعك غير آمن للزوّار

المشكلة الثانية: عدم وجود إعادة توجيه من HTTP إلى HTTPS

ماذا يعني هذا؟

عندما يكتب أحدهم http://shadynagy.com (بدون حرف ‘s’)، يجب أن تتم إعادة توجيهه تلقائيًا إلى https://shadynagy.com. بدون هذا التوجيه:

يمكن للزوّار الوصول إلى موقعك عبر اتصال HTTP غير آمن
ترى محركات البحث محتوى مكررًا (نسختا HTTP وHTTPS)
تفقد مزايا تحسين محركات البحث (SEO) الخاصة بـ HTTPS

الحل الأول: إصلاح الشهادة الوسيطة المفقودة

الخطوة 1: فهم السبب الجذري

اكتشفتُ أن إعدادات nginx كانت تستخدم التوجيه الخاطئ. إليك ما كان لديّ:

# ❌ إعدادات خاطئة
ssl_certificate /etc/nginx/ssl/shadynagy.com.crt;
ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;

المشكلة: التوجيه ssl_trusted_certificate مخصص لتدبيس OCSP (ميزة أداء)، وليس لإرسال سلسلة الشهادات إلى المتصفحات!

الخطوة 2: إنشاء شهادة السلسلة الكاملة

الحل هو إنشاء شهادة “سلسلة كاملة” (fullchain) تجمع بين شهادتك والشهادة الوسيطة.

الأمر:

cat /etc/nginx/ssl/shadynagy.com.crt /etc/nginx/ssl/shadynagy.com.ca-bundle > /etc/nginx/ssl/shadynagy.com-fullchain.crt

ماذا يفعل هذا:

cat - يدمج (يُلحق) الملفات
الملف الأول: شهادة موقعك الإلكتروني
الملف الثاني: حزمة الشهادات الوسيطة (CA bundle)
> - يُخرج النتيجة إلى ملف جديد يُسمى “fullchain”

مثال توضيحي: تخيّل أن لديك قطعتي أحجية:

شهادتك (القطعة أ)
الشهادة الوسيطة (القطعة ب)

أنت تلصقهما معًا لإنشاء أحجية كاملة يمكن للمتصفحات فهمها.

الخطوة 3: تحديث إعدادات Nginx

افتح ملف إعدادات SSL:

nano /etc/nginx/conf.d/shadynagy.com-ssl.conf

حدّثه إلى التالي:

server {
    listen 443 ssl http2;  # المنفذ 443 مع SSL وHTTP/2
    
    # ✅ صحيح - استخدم شهادة السلسلة الكاملة
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    
    # اختياري: احتفظ به لتدبيس OCSP (تحسين الأداء)
    ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;
    
    root /var/www/shady-nagy.com/html;
    index index.html index.htm;
    server_name shadynagy.com www.shadynagy.com;
    
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

شرح التغييرات الرئيسية:

listen 443 ssl http2;
- 443 = منفذ HTTPS
- ssl = تفعيل SSL
- http2 = تفعيل HTTP/2 لأداء أفضل
- يحل محل التوجيه القديم ssl on;
ssl_certificate يشير الآن إلى السلسلة الكاملة بدلاً من شهادتك فقط
ssl_trusted_certificate يُحتفظ به لتدبيس OCSP (اختياري لكنه مُوصى به)

الخطوة 4: الاختبار وتطبيق التغييرات

اختبر الإعدادات:

nginx -t

المخرجات المتوقعة:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

إذا ظهرت أي أخطاء، تحقق مرة أخرى من مسارات الملفات والصياغة!

طبّق التغييرات:

systemctl reload nginx

لماذا إعادة التحميل بدلاً من إعادة التشغيل؟

reload يُطبّق التغييرات دون قطع الاتصالات الحالية
restart سيُوقف موقعك لفترة وجيزة

✅ فوائد هذا الإصلاح

✅ جميع المتصفحات يمكنها التحقق من شهادة SSL الخاصة بك
✅ لا مزيد من تحذيرات “شهادة غير صالحة”
✅ الأجهزة المحمولة تتصل بشكل صحيح
✅ ثقة أفضل وترتيب أعلى في محركات البحث
✅ مظهر احترافي

الحل الثاني: فرض إعادة التوجيه إلى HTTPS

رحلة التحقيق

أولاً، تحققتُ من إعدادات HTTP:

cat /etc/nginx/conf.d/shadynagy.com.conf

وجدتُ هذا:

# ❌ إعدادات معطّلة
server {
    listen 80;
    root /var/www/shady-nagy.com/html;
    server_name shadynagy.com www.shadynagy.com;
    
    location / {
        try_files $uri $uri/ =404;
    }
    
    return 301 https://$server_name$request_uri;  # لن يتم الوصول إليه أبدًا!
}

المشكلة: يقرأ Nginx الإعدادات من الأعلى إلى الأسفل. عند ورود طلب:

يُطابق كتلة location /
يُعالج الطلب
لا يصل أبدًا إلى سطر إعادة التوجيه

الأمر أشبه بوضع لافتة “تحويلة” بعد الطريق!

الخطوة 1: إنشاء إعدادات إعادة التوجيه الصحيحة

الإصلاح:

# ✅ إعدادات صحيحة
server {
    listen 80;
    listen [::]:80;  # الاستماع أيضًا على IPv6
    server_name shadynagy.com www.shadynagy.com;
    
    # إعادة توجيه جميع حركة مرور HTTP إلى HTTPS
    return 301 https://$host$request_uri;
}

ماذا يفعل كل جزء:

listen 80; - الاستماع لطلبات HTTP (المنفذ 80)
listen [::]:80; - الاستماع أيضًا لطلبات HTTP عبر IPv6
server_name - النطاقات التي ينطبق عليها هذا الإعداد
return 301 - إرسال إعادة توجيه دائمة (رمز الحالة 301)
$host - النطاق الذي كتبه المستخدم (يحافظ على www مقابل بدون www)
$request_uri - المسار المطلوب (مثل /about أو /contact)

مثال عملي:

إذا زار أحدهم: http://www.shadynagy.com/how-i-fixed-ssl-certificate-issues-on-my-website-a-complete-guide تتم إعادة توجيهه إلى: https://www.shadynagy.com/how-i-fixed-ssl-certificate-issues-on-my-website-a-complete-guide

الخطوة 2: التطبيق والاختبار

اختبر الإعدادات:

nginx -t

أعد تحميل nginx:

systemctl reload nginx

اختبر إعادة التوجيه:

curl -I http://shadynagy.com

المخرجات المتوقعة:

HTTP/1.1 301 Moved Permanently
Location: https://shadynagy.com/

ممتاز! لكن انتظر…

التحوّل غير المتوقع: جدار الحماية كان يحظر المنفذ 80!

عندما اختبرتُ في المتصفح، لم يعمل الأمر! بعد بعض التحقيق:

firewall-cmd --list-all

المخرجات:

services: https

لاحظ ما ينقص؟ HTTP (المنفذ 80)!

كانت إعدادات إعادة التوجيه مضبوطة بشكل مثالي، لكن جدار الحماية كان يحظر حركة مرور HTTP الواردة. الأمر أشبه بتركيب باب أمامي ثم بناء جدار أمامه!

الخطوة 3: فتح جدار الحماية

أضف خدمة HTTP:

firewall-cmd --permanent --add-service=http

أعد تحميل جدار الحماية:

firewall-cmd --reload

تحقق من نجاح العملية:

firewall-cmd --list-all

الآن يجب أن ترى:

services: http https

✅ فوائد هذا الإصلاح

✅ جميع الزوّار يستخدمون HTTPS تلقائيًا
✅ لا مشاكل محتوى مكرر لمحركات البحث
✅ أمان أفضل لزوّارك
✅ ترتيب أعلى في محركات البحث
✅ قفل أخضر في المتصفحات
✅ بناء الثقة مع الزوّار

أوامر التشخيص الشاملة

إليك جميع الأوامر التي استخدمتها أثناء استكشاف الأخطاء:

فحص إعدادات Nginx

# البحث عن جميع كتل الخادم التي تستمع على المنفذ 80
grep -r "listen 80" /etc/nginx/

# اختبار صياغة إعدادات nginx
nginx -t

# عرض إعدادات nginx الكاملة
nginx -T

# عرض كتلة خادم محددة
nginx -T 2>/dev/null | grep -A 15 "server_name shadynagy.com"

فحص حالة Nginx

# هل nginx يعمل؟
systemctl status nginx

# إعادة تحميل nginx (تطبيق التغييرات بدون توقف)
systemctl reload nginx

# إعادة تشغيل nginx (توقف قصير)
systemctl restart nginx

# فحص سجلات الأخطاء
tail -20 /var/log/nginx/error.log

اختبار إعادة التوجيه من HTTP إلى HTTPS

# اختبار إعادة التوجيه (يتجاوز ذاكرة التخزين المؤقت للمتصفح)
curl -I http://shadynagy.com

# تتبع جميع عمليات إعادة التوجيه
curl -IL http://shadynagy.com

فحص حالة المنافذ

# هل nginx يستمع على المنفذ 80؟
ss -tlnp | grep :80

# هل nginx يستمع على المنفذ 443؟
ss -tlnp | grep :443

فحص جدار الحماية

# عرض جميع قواعد جدار الحماية
firewall-cmd --list-all

# إضافة HTTP بشكل دائم
firewall-cmd --permanent --add-service=http

# إضافة HTTPS بشكل دائم
firewall-cmd --permanent --add-service=https

# تطبيق التغييرات
firewall-cmd --reload

ملفات الإعدادات النهائية

إعدادات HTTP (المنفذ 80)

الملف: /etc/nginx/conf.d/shadynagy.com.conf

server {
    listen 80;
    listen [::]:80;
    server_name shadynagy.com www.shadynagy.com;
    
    return 301 https://$host$request_uri;
}

إعدادات HTTPS (المنفذ 443)

الملف: /etc/nginx/conf.d/shadynagy.com-ssl.conf

server {
    listen 443 ssl http2;
    
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;
    
    root /var/www/shady-nagy.com/html;
    index index.html index.htm index.nginx-debian.html;
    server_name shadynagy.com www.shadynagy.com;
    
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    
    location / {
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Pragma "no-cache";
        add_header Expires 0;
        try_files $uri $uri/ =404;
    }
}

النتائج: تم إصلاح كل شيء! ✅

بعد تطبيق جميع الإصلاحات، أظهر اختبار SSL على WhyNoPadlock.com:

✅ اتصال SSL - ناجح ✅ شهادة صالحة - شهادة SSL مثبتة بشكل صحيح ✅ فرض HTTPS - خادم الويب يفرض استخدام SSL ✅ تطابق النطاق - الشهادة تتطابق مع اسم النطاق ✅ التوقيع - يستخدم sha256WithRSAEncryption ✅ تاريخ انتهاء الصلاحية - الشهادة سارية (تنتهي 2026-11-03) ✅ محتوى مختلط - لا يوجد محتوى مختلط

نتيجة مثالية!

أسئلة وأجوبة

س1: لماذا أحتاج إلى شهادة وسيطة؟

ج: تُنشئ الشهادة الوسيطة “سلسلة ثقة” من موقعك الإلكتروني إلى جهة إصدار جذرية موثوقة. بدونها:

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

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

س2: ما الفرق بين `ssl_certificate` و `ssl_trusted_certificate` في nginx؟

ج: سؤال ممتاز!

ssl_certificate: هذا ما يرسله nginx إلى المتصفحات لإثبات هوية موقعك. يجب أن يحتوي على شهادتك والشهادة الوسيطة (السلسلة الكاملة).
ssl_trusted_certificate: يُستخدم لتدبيس OCSP، وهو ميزة أداء. يستخدمه nginx للتحقق من حالة إلغاء الشهادة نيابة عن العملاء. لا يُرسل إلى المتصفحات.

تشبيه:

ssl_certificate = بطاقة هويتك التي تُظهرها للناس
ssl_trusted_certificate = نسختك الشخصية من القواعد التي ترجع إليها بنفسك

س3: لماذا نستخدم `$host` بدلاً من `$server_name` في إعادة التوجيه؟

ج:

$host: النطاق الذي كتبه المستخدم بالضبط في متصفحه (مثل www.shadynagy.com أو shadynagy.com)
$server_name: أول server_name في إعداداتك

سيناريو توضيحي:

إعداداتك تحتوي: server_name shadynagy.com www.shadynagy.com;
المستخدم يزور: http://www.shadynagy.com

مع $server_name: يتم التوجيه إلى https://shadynagy.com (يحذف www) مع $host: يتم التوجيه إلى https://www.shadynagy.com (يحافظ على www)

استخدام $host يحترم ما كتبه المستخدم ويمنع عمليات إعادة توجيه إضافية غير ضرورية.

س4: لماذا عملت إعادة التوجيه مع curl لكنها لم تعمل في متصفحي؟

ج: عادةً ما يكون السبب واحدًا من ثلاثة:

جدار الحماية يحظر المنفذ 80 (مشكلتي!) - إعدادات إعادة التوجيه كانت صحيحة، لكن حركة مرور HTTP الواردة لم تصل أبدًا إلى nginx.
ذاكرة التخزين المؤقت للمتصفح - المتصفحات تُخزّن إعادة التوجيه بقوة. الحل: اختبر في وضع التصفح المتخفي أو امسح ذاكرة التخزين المؤقت.
ذاكرة DNS المؤقتة - قد يحتفظ حاسوبك بسجلات DNS قديمة. الحل: امسح ذاكرة DNS المؤقتة أو انتظر بضع ساعات.

نصيحة: اختبر دائمًا باستخدام curl -I أولاً لأنه يتجاوز جميع طبقات التخزين المؤقت!

س5: هل أستخدم `return` أم `rewrite` لإعادة التوجيه إلى HTTPS؟

ج: استخدم return دائمًا لإعادة التوجيه!

return (مُوصى به):

return 301 https://$host$request_uri;

أسرع (nginx يتوقف عن المعالجة فورًا)
أوضح في القصد
أقل عرضة للأخطاء

rewrite (تجنّبه لإعادة التوجيه البسيطة):

rewrite ^ https://$host$request_uri permanent;

أبطأ (يستخدم محرك التعبيرات النمطية)
أكثر تعقيدًا
سهل إنشاء حلقات لا نهائية

القاعدة العامة: استخدم return لإعادة التوجيه، واستخدم rewrite فقط عندما تحتاج إلى تعديل بنية عنوان URL.

س6: ما الفرق بين `reload` و `restart` لـ nginx؟

ج:

systemctl reload nginx (مُوصى به):

يُطبّق تغييرات الإعدادات بسلاسة
يُبقي الاتصالات الحالية نشطة
لا توقف عن العمل
يختبر الإعدادات قبل التطبيق (لن يُعيد التحميل إذا كانت الإعدادات معطلة)

systemctl restart nginx (استخدمه بحذر):

يوقف nginx بالكامل ثم يُشغّله مجددًا
يقطع جميع الاتصالات النشطة
توقف قصير (عادةً ميلي ثانية إلى ثوانٍ)
مفيد عندما لا تنجح إعادة التحميل

متى تُعيد التشغيل بدلاً من إعادة التحميل:

عند إضافة وحدات جديدة
عندما تفشل إعادة التحميل في التقاط التغييرات
عند تصحيح مشاكل غريبة

س7: كيف أعرف إذا كان جدار الحماية يحظر حركة المرور؟

ج: نفّذ أوامر التشخيص التالية:

# تحقق مما إذا كان nginx يستمع على المنفذ 80
ss -tlnp | grep :80
# إذا رأيت nginx هنا، فهو يستمع

# تحقق من قواعد جدار الحماية
firewall-cmd --list-all
# ابحث عن 'http' في قائمة الخدمات

# اختبر من خارج خادمك
curl -I http://your-domain.com
# إذا انتهت المهلة، فقد يكون جدار الحماية هو المشكلة

إذا كان nginx يستمع لكن curl من الخارج ينتهي بمهلة → جدار الحماية هو المشكلة!

س8: اختبار SSL الخاص بي يُظهر تحذيرات “محتوى مختلط”. ماذا يعني هذا؟

ج: يحدث المحتوى المختلط عندما تُحمّل صفحة HTTPS موارد (صور، نصوص برمجية، CSS) عبر HTTP.

مثال على المشكلة:

<!-- ❌ خطأ - تحميل صورة عبر HTTP في صفحة HTTPS -->
<img src="http://shadynagy.com/image.jpg">

الحلول:

<!-- ✅ جيد - استخدم HTTPS -->
<img src="https://shadynagy.com/image.jpg">

<!-- ✅ جيد - استخدم عنوان URL نسبي للبروتوكول -->
<img src="//shadynagy.com/image.jpg">

<!-- ✅ الأفضل - استخدم عنوان URL نسبي -->
<img src="/image.jpg">

فحص المحتوى المختلط:

افتح موقعك في Chrome
اضغط F12 (أدوات المطور)
ابحث عن التحذيرات في تبويب Console

س9: هل أحتاج إلى القيام بهذا في كل مرة أجدد فيها شهادة SSL؟

ج: جزئيًا، نعم.

ما تحتاج إلى إعادته:

إنشاء شهادة سلسلة كاملة جديدة (دمج الشهادة الجديدة + الوسيطة)
استبدال ملف السلسلة الكاملة القديم

ما لا تحتاج إلى إعادته:

تعديل ملفات إعدادات nginx (ستشير إلى نفس المسارات)
تغيير قواعد جدار الحماية
إعداد إعادة التوجيه

نصيحة: أتمت تجديد الشهادات باستخدام Let’s Encrypt/Certbot، الذي يتولى إنشاء السلسلة الكاملة تلقائيًا!

س10: هل يمكنني اختبار إعدادات SSL قبل تفعيلها؟

ج: بالتأكيد! إليك الطريقة:

1. اختبار صياغة إعدادات nginx:

nginx -t

2. الاختبار محليًا باستخدام curl:

# اختبار إعادة التوجيه
curl -I http://localhost

# اختبار HTTPS (قد تظهر تحذيرات شهادة عند الاختبار محليًا)
curl -Ik https://localhost

3. استخدام أدوات عبر الإنترنت:

SSL Labs - اختبار SSL شامل
WhyNoPadlock - فحص SSL سريع
SSL Shopper - فاحص سلسلة الشهادات

4. الاختبار في بيئة تجريبية: إن أمكن، أنشئ نطاقًا فرعيًا تجريبيًا (مثل staging.shadynagy.com) واختبر هناك أولاً.

س11: ما هو HTTP/2 ولماذا أضفته؟

ج: HTTP/2 هو إصدار أحدث وأسرع من بروتوكول HTTP.

الفوائد:

✅ تعدد الإرسال: تنزيل ملفات متعددة في وقت واحد عبر اتصال واحد
✅ ضغط الترويسات: طلبات واستجابات أصغر
✅ دفع الخادم: يمكن للخادم إرسال ملفات قبل أن يطلبها المتصفح
✅ أداء أفضل على الأجهزة المحمولة

كيفية التفعيل:

listen 443 ssl http2;  # فقط أضف 'http2' هنا!

المتطلبات:

يجب تفعيل HTTPS (HTTP/2 يتطلب SSL)
Nginx 1.9.5 أو أحدث
OpenSSL 1.0.2 أو أحدث

التحقق:

curl -I --http2 https://shadynagy.com
# ابحث عن "HTTP/2 200" في الاستجابة

س12: ماذا يحدث إذا نسيتُ جعل قواعد جدار الحماية دائمة؟

ج: إذا لم تستخدم --permanent، ستختفي قواعد جدار الحماية عند إعادة تشغيل الخادم!

غير دائمة (تُفقد عند إعادة التشغيل):

firewall-cmd --add-service=http  # ❌ تختفي بعد إعادة التشغيل

دائمة (تبقى بعد إعادة التشغيل):

firewall-cmd --permanent --add-service=http  # ✅ تبقى بعد إعادة التشغيل
firewall-cmd --reload  # تطبيق فوري

التحقق مما إذا كانت القاعدة دائمة:

# عرض القواعد الحالية (وقت التشغيل)
firewall-cmd --list-all

# عرض القواعد الدائمة (المحفوظة)
firewall-cmd --permanent --list-all

إذا لم تتطابق، فأنت بحاجة إلى جعل تغييراتك دائمة!

س13: كم مرة يجب أن أفحص شهادة SSL الخاصة بي؟

ج: إليك جدول صيانة جيد:

شهريًا:

فحص تاريخ انتهاء صلاحية الشهادة
إجراء اختبار SSL سريع على WhyNoPadlock.com

قبل انتهاء الصلاحية:

تجديد الشهادة قبل 30 يومًا من انتهائها
اختبار الشهادة الجديدة فورًا
إعداد التجديد التلقائي إن أمكن

بعد تحديثات الخادم:

اختبار SSL بعد أي تحديثات لـ nginx/OpenSSL
التحقق من أن إعادة التوجيه لا تزال تعمل

إعداد المراقبة: العديد من الخدمات تقدم مراقبة SSL مجانية:

UptimeRobot
Pingdom
SSL Labs monitoring

ستُرسل لك بريدًا إلكترونيًا قبل انتهاء صلاحية شهادتك!

س14: ماذا لو كان لديّ نطاقات متعددة على خادم واحد؟

ج: تحتاج إلى كتلة خادم منفصلة لكل نطاق.

مثال لنطاقات متعددة:

# النطاق 1: shadynagy.com
server {
    listen 80;
    server_name shadynagy.com www.shadynagy.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name shadynagy.com www.shadynagy.com;
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    root /var/www/shadynagy.com;
}

# النطاق 2: myotherdomain.com
server {
    listen 80;
    server_name myotherdomain.com www.myotherdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name myotherdomain.com www.myotherdomain.com;
    ssl_certificate /etc/nginx/ssl/myotherdomain.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/myotherdomain.com.key;
    root /var/www/myotherdomain.com;
}

بديل: استخدم شهادة شاملة (wildcard) أو شهادة متعددة النطاقات (SAN) لتغطية عدة نطاقات بشهادة واحدة.

س15: لماذا تظهر شهادتي على أنها “غير آمنة” حتى بعد كل هذه الإصلاحات؟

ج: تحقق من هذه المشاكل الشائعة:

عدم تطابق اسم الشهادة:
- الشهادة صادرة لـ www.shadynagy.com لكنك تزور shadynagy.com
- الحل: احصل على شهادة تغطي كليهما (شهادة SAN)
شهادة منتهية الصلاحية:
- تحقق من تاريخ الانتهاء: openssl x509 -in certificate.crt -noout -dates
- الحل: جدّد الشهادة
محتوى مختلط:
- صفحة HTTPS تُحمّل موارد HTTP
- تحقق من وحدة تحكم المتصفح للتحذيرات
نطاق خاطئ في إعدادات nginx:
- server_name لا يتطابق مع النطاق الذي تزوره
- الحل: أضف جميع أشكال النطاق إلى server_name
شهادة غير موثوقة:
- استخدام شهادة موقّعة ذاتيًا
- الحل: احصل على شهادة من جهة إصدار موثوقة (Let’s Encrypt مجاني!)

تشخيص سريع:

# تحقق من الشهادة المُقدَّمة
openssl s_client -connect shadynagy.com:443 -servername shadynagy.com

أدوات اختبار SSL مفيدة عبر الإنترنت

🔗 SSL Labs - أشمل اختبار SSL، يمنحك تقييمًا من A إلى F

🔗 WhyNoPadlock - فحص بصري سريع لمشاكل SSL الشائعة

🔗 SSL Shopper - يفحص تثبيت الشهادة والسلسلة

🔗 Security Headers - يختبر ترويسات الأمان HTTP

🔗 High-Tech Bridge - تقييم مفصّل لـ SSL/TLS والأمان

النقاط الرئيسية

بالنسبة للشهادات الوسيطة:

✅ أنشئ دائمًا شهادة سلسلة كاملة (الشهادة + حزمة CA) ✅ استخدم توجيه ssl_certificate للسلسلة الكاملة ✅ استخدم ssl_trusted_certificate فقط لتدبيس OCSP ✅ اختبر بالأدوات عبر الإنترنت بعد التثبيت

لإعادة التوجيه إلى HTTPS:

✅ استخدم return 301 لإعادة التوجيه (وليس rewrite) ✅ ضع إعادة التوجيه قبل كتل location ✅ استخدم $host للحفاظ على ما أدخله المستخدم ✅ تذكّر فتح المنفذ 80 في جدار الحماية!

للاختبار:

✅ اختبر دائمًا إعدادات nginx بـ nginx -t قبل إعادة التحميل ✅ استخدم curl لتجاوز ذاكرة التخزين المؤقت للمتصفح ✅ تحقق من قواعد جدار الحماية بـ firewall-cmd --list-all ✅ تحقق من الاستماع على المنافذ بـ ss -tlnp

للصيانة:

✅ أعدّ تنبيهات انتهاء صلاحية الشهادات ✅ اجعل قواعد جدار الحماية دائمة ✅ حافظ على تحديث nginx وOpenSSL ✅ اختبر إعدادات SSL بانتظام

أفكار ختامية

قد يبدو إعداد SSL مُرهقًا في البداية، لكن بمجرد فهم الأجزاء، يصبح منطقيًا للغاية:

سلسلة الشهادات - إثبات هويتك
إعادة التوجيه إلى HTTPS - فرض الاتصالات الآمنة
قواعد جدار الحماية - السماح لحركة المرور بالوصول إلى خادمك

تقسيم المشكلة إلى هذه المكوّنات جعل التشخيص والإصلاح أسهل بكثير.

الدرس الأهم؟ عندما لا يعمل شيء ما، تحقق طبقة بطبقة:

هل إعدادات nginx صحيحة؟ (nginx -t)
هل nginx يستمع؟ (ss -tlnp)
هل جدار الحماية يسمح بحركة المرور؟ (firewall-cmd --list-all)
هل يعمل محليًا؟ (curl -I http://localhost)

هذا النهج المنهجي وفّر عليّ ساعات من الإحباط!

الملاحظات والأسئلة

نودّ سماع ملاحظاتك حول هذا الدليل! إذا كان لديك أي أسئلة أو اقتراحات للتحسين، لا تتردد في التواصل معنا. يمكنك ترك تعليق أدناه، أو التواصل معنا عبر القنوات التالية: