فشل تجديد SSL تلقائياً قد يحدث في الجدولة، أو إثبات ملكية النطاق، أو إصدار الشهادة، أو تركيبها على نقطة الاتصال. وقد تنجح عملية التجديد بينما يستمر الخادم في تقديم شهادة قديمة. لذلك ابدأ بالشهادة التي يراها الزائر فعلياً، ثم ارجع عبر سلسلة التشغيل لتحديد موضع الانقطاع. شراء شهادة أخرى لا يعالج تلقائياً مشكلة DNS أو مهمة متوقفة أو إعداد تحميل خاطئ.
تحقق من الشهادة المقدمة للزائر
سجل اسم النطاق الذي يظهر فيه التحذير والمنفذ وتاريخ انتهاء الشهادة واسم مصدرها والأسماء التي تغطيها. افصل انتهاء الصلاحية عن عدم تطابق الاسم أو نقص سلسلة الثقة أو ساعة جهاز غير صحيحة. قد يبدو للمستخدم أنها مشكلة SSL واحدة، لكن علاج كل حالة مختلف.
حدد أين ينتهي TLS: لدى CDN، أم موازن حمل، أم خادم الويب نفسه. يمكن أن تكون هناك شهادة بين الزائر والواجهة وأخرى بين الواجهة والخادم الأصلي. نجاح إحداهما لا يثبت صحة الأخرى. وفي عدة خوادم خلف عنوان واحد، افحص كل نقطة مع اسم النطاق الصحيح لأن عقدة واحدة تحمل شهادة قديمة قد تسبب عطلاً متقطعاً.
تتبع سلسلة التجديد مرحلة بمرحلة
| المرحلة | الدليل المطلوب | سبب محتمل للفشل |
|---|---|---|
| تشغيل المهمة | وقت آخر محاولة ونتيجتها | مؤقت متوقف أو بيئة تنفيذ مختلفة |
| التحقق من الملكية | رد التحدي والخطأ التفصيلي | DNS أو مسار HTTP أو صلاحية API |
| الإصدار | شهادة جديدة صالحة للأسماء المطلوبة | سياسة CAA أو حدود جهة الإصدار |
| التركيب | مسار الملف والربط بالخدمة الصحيحة | نسخ إلى مكان غير مستخدم |
| تحميل الخدمة | نجاح فحص الإعداد وإعادة التحميل | hook فاشل أو صلاحيات غير مناسبة |
| التحقق الخارجي | الشهادة التي تعرضها كل واجهة | عقدة أو واجهة لم تحدث |
احتفظ بسجل آخر نجاح وأول فشل، وطابقهما مع نقل DNS أو تغيير الجدار الناري أو تحديث عميل ACME. وجود علامة «تجديد تلقائي» في اللوحة لا يغني عن نتيجة المحاولات؛ وقد تكون الشهادة غير مستحقة للتجديد فيمر أمر الفحص دون إصدار جديد.
إذا كان التحقق عبر HTTP-01
يعتمد HTTP-01 لدى Let’s Encrypt على إتاحة قيمة التحدي في مسار محدد عبر المنفذ 80. افحص وصول هذا المسار من الخارج، وتأكد أن التحويلات وقواعد التطبيق والمصادقة لا تمنع قراءته. وفي بيئة متعددة الخوادم يجب أن تصل جهة التحقق إلى القيمة الصحيحة مهما كانت العقدة المختارة.
توضح وثائق أنواع تحديات Let’s Encrypt الفرق بين HTTP-01 وDNS-01، ومنها أن HTTP-01 لا يصدر شهادات wildcard. اختر الطريقة التي يمكن تشغيلها باستمرار ضمن البنية، ولا تعالج فشل مسار التحقق بتعطيل حماية الموقع بالكامل أو فتح لوحة الإدارة للإنترنت.
إذا كان التحقق عبر DNS-01
راجع أن سجل TXT للتحدي يضاف إلى المنطقة الفعالة، وأن مفتاح API لم تنته صلاحيته أو تتغير أذوناته. قد يكون عميل التجديد ما زال يتصل بمزود DNS قديم بعد النقل. وإذا فوضت سجل التحدي إلى منطقة أخرى، تحقق من سلسلة التفويض ومن صلاحية الكتابة في المكان المقصود.
أعط التكامل أقل صلاحية لازمة وفق إمكانات المزود، واحفظ السر خارج محتوى الموقع والسجلات العامة. انتظر ظهور القيمة الصحيحة لدى الخوادم المعنية وفق آلية العميل، ثم راجع تنظيف سجلات التحدي القديمة. التعديل اليدوي كل مرة قد ينجح كإصدار مؤقت، لكنه لا يحقق تجديداً آلياً موثوقاً للشركة.
افحص IPv6 وCAA وأخطاء DNS
قد يشير A إلى الخادم الصحيح بينما يشير AAAA إلى خادم قديم. توثق Let’s Encrypt تفضيل IPv6 في الاتصال الأول للتحقق عند وجوده، وأن سجل AAAA غير الصحيح يؤثر في العملية. لا تعتبر نجاح الموقع من اتصال IPv4 إثباتاً لصحة المسارين؛ صحح إعداد الخدمة المنشور وفق ما تدعمه فعلياً.
وتتحكم سجلات CAA في الجهات المسموح لها بالإصدار عندما تكون مضبوطة. تشرح وثائق CAA أن أخطاء الاستعلام قد تمنع الإصدار حتى عند عدم إنشاء سجل CAA صراحة. ميز منعاً مقصوداً لجهة الإصدار عن خلل DNS أو DNSSEC؛ لا تحذف السياسة عشوائياً قبل فهم السبب.
الشهادة تجددت لكن الموقع ما زال يعرض القديمة
قارن الشهادة الجديدة بالمسار المستخدم في إعداد الخدمة، وافحص الروابط والنسخ داخل الحاويات أو وحدات التخزين. قد يقرأ خادم الويب ملفاً منسوخاً لا يتحدث عند تجديد الأصل، أو قد تكون صلاحيات القراءة غير مناسبة. اختبر صحة إعداد الخدمة قبل إعادة تحميله وفق إجراءاتها، ثم تحقق خارجياً من النتيجة.
يوضح دليل Certbot استخدام deploy hook لتنفيذ إجراء بعد تجديد ناجح، والفرق بين نجاح الأمر وحدوث تجديد فعلي. راجع hooks الحالية قبل اختبار dry-run؛ الاختبار ليس بالضرورة خالياً من آثار السكربتات المحيطة. بيئة الاختبار وشهاداتها لا تستبدل شهادة موثوقة للمستخدمين في الإنتاج.
استعد الخدمة ثم أصلح دورة التشغيل
في مثال افتراضي، شركة نقلت التطبيق إلى عقدتين وبقيت مهمة التجديد على الأولى فقط؛ إعادة إصدار الشهادة لا تحدث الثانية إن لم توجد آلية توزيع. شركة أخرى غيرت DNS فانقطعت صلاحية API القديمة. الأولى تحتاج ضبط نشر الشهادة، والثانية تحتاج إصلاح التحقق. لا تعالج الحالتين بزيادة موارد الاستضافة.
إذا لزم نقل الخدمة أو إعادة تهيئتها، راجع دليل نقل الاستضافة لتوثيق التبعيات. واحفظ إعدادات الخدمة ومعلومات الاستعادة وفق ما يناسب حساسيتها؛ يناقش مقال أخطاء النسخ الاحتياطي أهمية اختبار الرجوع. لا تعمم توزيع المفتاح الخاص على خوادم لا تحتاجه.
متى تحتاج إدارة شهادات احترافية؟
تزيد الحاجة عندما تتعدد النطاقات والمزودون ونقاط إنهاء TLS أو يغيب مالك واضح للتجديد. اطلب نطاق خدمة يشمل جرد الشهادات، واختبار الإصدار والتركيب، وتنبيهاً مبكراً، ومسؤولية استجابة عند الفشل. قيمة الإدارة في اكتمال هذه السلسلة، وليست في وعد مبهم بأن الشهادة «مدى الحياة».
- سجل كل اسم وخدمة ونقطة اتصال وشهادة مستخدمة.
- حدد عميل التجديد ومؤقته وصلاحياته ومصدر الأسرار.
- راقب الشهادة المقدمة خارجياً، لا الملف المحلي فقط.
- اختبر نشر الشهادة على جميع العقد بعد نجاح الإصدار.
- وثق استجابة التنبيه وخطة الرجوع قبل انتهاء الصلاحية.
أسئلة شائعة عن التجديد الآلي
هل يكفي تشغيل أمر التجديد يدوياً؟
قد يستعيد الإصدار، لكنه لا يثبت عمل المؤقت أو التركيب لاحقاً. تحقق من المسار الآلي بالكامل ومن الشهادة المقدمة للزائر.
هل أدفع لشهادة أخرى لتجنب المشكلة؟
اختر نوع الشهادة حسب الحاجة، لكن الدفع لا يحل خطأ الجدولة أو DNS أو تركيبها على الخدمة. أصلح السبب التشغيلي أولاً.
هل أكرر طلب الإصدار بلا توقف؟
لا؛ اقرأ الخطأ وعالجه واستخدم بيئة الاختبار المناسبة. التكرار غير المدروس قد يصطدم بحدود الإصدار ويؤخر المعالجة.
اطلب فحص دورة الشهادة كاملة
أرسل الأسماء المتأثرة ونوع لوحة الإدارة وتوقيت آخر تجديد ناجح عبر طلب تقييم SSL دون مفاتيح خاصة. اطلب ضمن خدمة شهادات SSL فحص الإصدار والتركيب والتنبيه، مع إثبات أن جميع نقاط الخدمة تقدم شهادة صحيحة بعد الإصلاح.