شهادة منتهية لا تعني أن المستضيف معطّل
الشهادة المجانية تُجدَّد من تلقاء نفسها دون أن ينقر أحد. وحين تنتهي رغم ذلك، يكون الاستنتاج التلقائي أن الخدمة الآلية فشلت. وهذا نادرًا ما يكون صحيحًا. فالتجديد ليس إجراءً يقوم به المستضيف: إنه حوار بين جهة إصدار الشهادات ونطاقك، يتكرر عند كل استحقاق، ولا ينجح إلا إذا ردّ النطاق كما ردّ في المرة الأولى.
غير أن الموقع يتغيّر مع الوقت. فقد يكون أحدهم بدّل خوادم DNS، أو أضاف قاعدة تحويل في ملف .htaccess، أو فعّل جدار حماية لتطبيقات الويب، أو وضع النطاق خلف CDN، أو نشر سجل CAA. وكل خطوة من هذه مشروعة، وكل منها قد يمنع التحقق بينما يستمر الموقع في الظهور. ويظهر الخطأ بعد أسابيع، عند الاستحقاق، بعيدًا عن التعديل الذي سبّبه. وإعادة طلب الإصدار دون إصلاح شيء لا تنتج سوى الفشل نفسه. المطلوب أن تقرأ الإشارة، وتجد الشرط الذي تغيّر، وتعيده كما كان، ثم تعيد المحاولة مرة واحدة.
ما الذي يتحقق منه التجديد عند كل استحقاق
لإصدار شهادة أو تجديدها، يجب على الجهة المصدِرة أن تتأكد من أن طالبها يتحكم فعلًا في النطاق. وهي تعمل على أربع مراحل، ويقع الفشل دائمًا في إحداها.
أولًا، تحلّ الاسم: يجب أن يستجيب DNS ويعيد عنوان الخادم الصحيح، عبر IPv4 وكذلك IPv6. ثم، في التحقق بالملف، تطلب العنوان http://your-domain.com/.well-known/acme-challenge/ على المنفذ 80 وتنتظر المحتوى الدقيق الذي وضعه عميل ACME. وثالثًا، تطّلع على سجلات CAA الخاصة بالنطاق لتتأكد من أن أيًّا منها لا يمنعها من الإصدار. وأخيرًا تتبع التحويلات إن وُجدت، لكنها ترفض استجابة خطأ أو صفحة حظر.
يفسّر هذا التسلسل شجرة التشخيص: هل يشير النطاق إلى الخادم الصحيح، وهل يمكن الوصول إلى مسار التحدي، وهل يعترضه تحويل أو جدار حماية، وهل يستبعد سجل CAA الجهة المصدِرة، وهل البروكسي في وضع متوافق. وتختبر الخطوات التالية هذه النقاط الخمس بهذا الترتيب.
التشخيص في ست خطوات
اقرأ تاريخ الانتهاء الفعلي
لا تعتمد على رسالة: اقرأ الشهادة التي تُقدَّم فعلًا. الأمر
openssl s_client -connect your-domain.com:443 -servername your-domain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuerيطبع تاريخَي البداية والنهاية والجهة المصدِرة. إذا كان تاريخ النهاية قد مضى، فالتجديد فشل فعلًا. وإذا كان ما زال ساريًا، فالتحذير مصدره شيء آخر: اسم نطاق آخر غير مشمول، أو سلسلة ناقصة.تحقق من وجهة النطاق
يجب أن يعيد
dig +short A your-domain.comثمdig +short AAAA your-domain.comعنوان الخادم الذي يستضيف الموقع. ومن الأسباب الكلاسيكية سجل AAAA منسي يشير إلى خادم قديم: تجرّب الجهة المصدِرة IPv6 أولًا فتصل إلى الجهاز الخطأ. تحقق أيضًا منdig +short NS your-domain.comلتتأكد أن خوادم الأسماء هي نفسها التي تعدّل فيها المنطقة.اختبر مسار التحدي عبر HTTP
ضع ملف اختبار في المجلد
.well-known/acme-challenge/ضمن الجذر العام للموقع، ثم نفّذcurl -I http://your-domain.com/.well-known/acme-challenge/test.txt. المتوقع هو الرمز 200. التحويل 301 إلى HTTPS مقبول، أما 403 أو 404 فلا. أضف-Lلتتبع سلسلة التحويلات وكشف حلقة أو وجهة غير متوقعة.حدّد من يجيب فعلًا
قارن ترويسات الاستجابة: يكشف الحقل
serverأوviaوجود بروكسي أو CDN أو جدار حماية لتطبيقات الويب في المسار. وإذا كانت الاستجابة صفحة تحقق ضد الروبوتات، فلن تجتازها الجهة المصدِرة أبدًا لأنها ليست متصفحًا. أعد قراءة قواعد.htaccessأيضًا: توجيه يمنع الوصول إلى الملفات التي يبدأ اسمها بنقطة يحجب.well-known.اقرأ سجلات CAA
يسرد
dig CAA your-domain.com +shortالجهات المصرّح لها. غياب الرد يعني عدم وجود قيد. أما رد لا يذكر جهتك، مثل0 issue "other-authority.example"، فيمنع الإصدار. اصعد كذلك إلى النطاق الأب: سجل CAA المنشور علىyour-domain.comينطبق على كل نطاقاته الفرعية التي ليس لها سجل خاص.راجع سجل عميل الإصدار
يسمّي السجل السبب الدقيق. على VPS يعطي
certbot certificatesالحالة، ويفصّل/var/log/letsencrypt/letsencrypt.logكل محاولة. وفي cPanel يبيّن سجل AutoSSL في صفحة شهادات SSL النطاق وسبب الفشل. دوّن الرسالة حرفيًا: الجدول التالي يربطها بسببها.
العَرَض والسبب المحتمل والإصلاح
مرّر الجدول أفقيًا
| العَرَض الملاحَظ | السبب المحتمل | الإصلاح |
|---|---|---|
| النطاق لا يُحلّ (NXDOMAIN) | حذف منطقة DNS أو تغيير خوادم الأسماء أو غياب السجل | إعادة سجل A في المنطقة المعتمدة |
| انتهاء المهلة عند الاتصال | المنفذ 80 مغلق أو عنوان AAAA يشير إلى خادم آخر | فتح المنفذ 80 وتصحيح سجل AAAA أو حذفه |
| استجابة 404 على التحدي | جذر ويب مختلف أو قاعدة إعادة كتابة تحرف المسار | تقديم `.well-known/acme-challenge/` من الجذر الصحيح |
| استجابة 403 على التحدي | جدار حماية لتطبيقات الويب أو حجب الملفات المخفية أو مرشّح بلد | استثناء هذا المسار من قواعد الحجب |
| تحويلات كثيرة جدًا | حلقة بين HTTP وHTTPS وwww والنطاق المجرد | تصحيح قاعدة التحويل واختبارها بـ `curl -IL` |
| CAA يمنع الإصدار | سجل CAA لا يذكر الجهة المستخدمة | إضافة الجهة إلى سجل CAA أو حذفه |
| صفحة تحقق بدل الملف | بروكسي CDN أو حماية ضد الروبوتات نشطة على المسار | تعطيل التحدي على `/.well-known/acme-challenge/` |
عندما يشير DNS إلى جهة أخرى
هذا هو السبب الأكثر شيوعًا والأكثر خفاءً. بعد ترحيل أو تغيير مستضيف أو تنظيف للمنطقة، يستمر النطاق في الظهور بفضل الذاكرة المؤقتة أو بفضل سجل A صحيح، بينما يظل سجل AAAA يشير إلى الخادم القديم. تفضّل الجهة المصدِرة IPv6 متى وُجد: فتستعلم من الجهاز القديم الذي لم يعد يعرف ملف التحدي، فيفشل التحقق رغم أن كل شيء يبدو سليمًا من جهازك.
الفحص بسيط: قارن dig +short A your-domain.com وdig +short AAAA your-domain.com بالعنوان الحقيقي للخادم. وإن لم تكن تستخدم IPv6، فاحذف سجل AAAA بدل تركه يشير إلى مكان آخر. تحقق كذلك من أن النطاق يستخدم خوادم الأسماء التي صحّحت فيها المنطقة للتو؛ وتفاصيل تعديل السجل في الدليل الخاص بإضافة سجل DNS أو تعديله. ثم انتظر انقضاء مدة التخزين المؤقت التي كانت تعلنها القيمة القديمة قبل إعادة المحاولة.
عندما يعترض تحويل أو جدار حماية مسار التحدي
التحدي طلب HTTP عادي ترسله الجهة المصدِرة من خوادمها. وكل ما يجيب بدلًا منها، أو يجيبها بغير الملف المتوقع، يُفشل التحقق. وهناك ثلاثة إعدادات تسبب المشكلة بانتظام.
الأول تحويل يغيّر النطاق: قاعدة ترسل كل حركة your-domain.com إلى عنوان آخر، بما فيها مسار التحدي، فتبحث الجهة المصدِرة عن الملف في موقع لا يحتويه. والثاني قاعدة أمنية ترفض الملفات التي يبدأ اسمها بنقطة: فهي تحمي .env أو .git، لكنها تحجب أيضًا .well-known. والثالث جدار حماية تطبيقات الويب أو الترشيح حسب البلد، الذي يعامل الجهة المصدِرة كزائر مجهول ويرد بـ 403.
الحل ليس تعطيل الحماية، بل استثناء المسار /.well-known/acme-challenge/ تحديدًا من قواعد التحويل والحجب. أما التحويل من HTTP إلى HTTPS فيبقى مقبولًا، ما دام يحافظ على المسار المطلوب وينتهي عند النطاق نفسه.
عندما يستبعد سجل CAA الجهة المصدِرة
سجل CAA قائمة بيضاء منشورة في DNS: يعدّد الجهات المسموح لها بالإصدار للنطاق. وهو أداة أمان جيدة، لكنه يتقادم بصمت. ينشر أحدهم 0 issue "an-authority.example" أثناء تدقيق، ثم ينتقل الاستضافة إلى جهة أخرى، أو يغيّر AutoSSL مزوّده، فيُرفض الإصدار برسالة تذكر CAA.
للإصلاح، اقرأ نتيجة dig CAA your-domain.com +short، وحدّد الجهة التي تستخدمها خدمتك (في cPanel، عمود المُصدِر في صفحة شهادات SSL)، ثم أضف سطر issue باسمها. وإن لم تكن بحاجة إلى هذا القيد فاحذف السجل. وتذكّر أن CAA يُقرأ بالصعود في الشجرة: سجل النطاق الرئيسي ينطبق على النطاقات الفرعية. وبالنسبة لشهادة تغطي نطاقًا فرعيًا شاملًا، قد يلزم سطر issuewild مستقل.
عندما يتوسط بروكسي CDN
وضع النطاق خلف CDN بوضع البروكسي يغيّر ما تراه الجهة المصدِرة. فهي لم تعد تخاطب خادمك بل خادم الـ CDN، الذي قد يجيب بدلًا منك بشهادة طرفية أو صفحة تحقق أو قاعدة أمان خاصة به. وبحسب الوضع المختار، ينجح تجديد شهادة الأصل أو لا ينجح.
يهم إعدادان. الأول وضع التشفير بين الـ CDN والأصل: في الوضع المرن يخاطب الـ CDN الأصل دون تشفير، فتنشأ حلقة تحويل إذا كان خادمك يفرض HTTPS؛ وفي الوضع الصارم يشترط شهادة أصل صالحة، فيظهر الانتهاء فورًا في صورة خطأ في الأصل. والثاني الحمايات النشطة على مسار التحدي: يجب رفعها عن /.well-known/acme-challenge/ أو الانتقال إلى التحقق بسجل DNS الذي لا يعتمد على حركة الويب. وخلال التشخيص يمكنك أيضًا تعطيل البروكسي مؤقتًا على السجل المعني وحده، ثم إعادة طلب الإصدار، ثم إعادة تفعيله.
رسائل الخطأ التي تصادفها وأسبابها
DNS problem: NXDOMAIN looking up A— الاسم لا يُحلّ: منطقة غائبة، أو خوادم أسماء معدّلة، أو خطأ مطبعي في النطاق المطلوب.Timeout during connect (likely firewall problem)— لا تصل الجهة المصدِرة إلى المنفذ 80: جدار حماية، أو مجموعة أمان لدى المزوّد، أو سجل AAAA يشير إلى جهاز لا يستمع.Invalid response ... 404— الخادم يجيب لكنه لا يجد الملف: جذر ويب خاطئ، أو إعادة كتابة تحرف المسار، أو موقع يخدمه مضيف افتراضي آخر.Invalid response ... 403— حجب نشط: جدار حماية تطبيقات الويب، أو قاعدة تمنع الملفات المخفية، أو ترشيح حسب البلد، أو حماية ضد الروبوتات.CAA record for your-domain.com prevents issuance— سجل CAA لا يذكر الجهة المستخدمة؛ أضفها أو احذف القيد.- فشل التحقق من التحكم بالنطاق في AutoSSL — يشير السجل إلى أن النطاق لا يشير إلى هذا الخادم أو أن طلب التحقق حُرِف؛ ارجع إلى الخطوات من 2 إلى 4.
أين تعيد المحاولة بعد إصلاح السبب
على استضافة ويب cPanel
افتح صفحة الأمان في cPanel، تبويب شهادات SSL، وأعد تشغيل فحص AutoSSL للنطاق، ثم أعد قراءة عمود الانتهاء. والإجراء خطوة بخطوة موصوف في الدليل الخاص بالتحقق من شهادة SSL وإعادة تشغيلها في cPanel.
على VPS مع certbot
اختبر أولًا دون إصدار أي شيء: يعيد
certbot renew --dry-runتشغيل التحقق في بيئة تجريبية. إذا نجح الاختبار فإنcertbot renewيصدر فعليًا، ثم أعد تحميل خادم الويب ليقدّم الملف الجديد. والإعداد الكامل موصوف في دليل شهادات Let's Encrypt على VPS.مع سلسلة ACME مؤتمتة
إذا كانت أداة تتولى الإصدار نيابةً عنك، فأصلح السبب ثم شغّل تجديدها يدويًا مرة واحدة فقط. ولجعل هذا المسار موثوقًا على المدى الطويل، راجع أتمتة ACME بشهادات قصيرة العمر.
تحقق من النتيجة
أعد تشغيل أمر
openssl s_clientمن الخطوة الأولى: يجب أن يكون تاريخ النهاية قد تغيّر. أعد تحميل الموقع في نافذة تصفح خاص، لأن المتصفح قد يحتفظ بالشهادة القديمة في الذاكرة.
الوقاية بدل التشخيص
كلما عدّلت DNS، أو أضفت تحويلًا، أو فعّلت جدار حماية، أو انتقلت خلف CDN، أعد فورًا اختبار التحدي بـ curl -I. إن مراقبة تاريخ الانتهاء، مع تنبيه عند اقتراب الاستحقاق، تحوّل موقعًا معطوبًا إلى تذكرة بسيطة تُعالج بهدوء. دوّن في ملف الموقع الجهة التي تصدر الشهادة: فهي المعلومة التي تغيب أكثر من غيرها يوم يحجب CAA الإصدار.
أصلح الشرط لا العَرَض
فشل التجديد يدل في الغالب على أن شرطًا من شروط التحقق قد تغيّر: الاسم لم يعد يشير إلى المكان الصحيح، أو مسار التحدي محجوب أو محرَّف، أو استُبعدت جهة مصدِرة، أو تسلّل بروكسي بينها وبين الخادم. وترتيب القراءة ثابت: حلّ DNS، ثم الوصول إلى المنفذ 80، ثم الاستجابة على مسار التحدي، ثم سجل CAA، ثم وضع البروكسي. وبعد إعادة السبب إلى حاله تكفي محاولة واحدة. تتضمن استضافة الويب من ServOrbit.com شهادة SSL مجانية تُجدَّد تلقائيًا؛ وعندما يفشل التحقق، يمكن قراءة السبب في سجل AutoSSL وإصلاحه بالأوامر أعلاه.
