تصدر Let’s Encrypt الشهادات لتسعين يومًا وتجدّدها تلقائيًا، ولهذا يتوقف الناس عن التفكير فيها بعد أسبوع من الإعداد. والمشكلة أن التجديد التلقائي يتعطّل بصمت: فلا أحد يرى الأخطاء، وبعد ثلاثة أشهر يستقبل الموقع زوّاره بتحذير من المتصفح. ومنذ 2025 توقفت Let’s Encrypt عن إرسال رسائل التنبيه بانتهاء الصلاحية، فاختفى آخر تذكير خارجي أيضًا.
وفي ما يلي أسباب توقف التجديد عن العمل، بترتيب تنازلي للتكرار.
1. جُدِّدت الشهادة ولم تعِد الخدمة قراءتها قط
الأشيع. عمل certbot renew، والملف الجديد على القرص، بينما يحتفظ nginx أو Apache بالقديم في الذاكرة — ويقدّمه للزوّار حتى يُعاد تحميل الإعداد. شكليًا كل شيء على ما يرام؛ وفعليًا للموقع شهادة منتهية.
والعلاج خطاف يُنفَّذ بعد تجديد ناجح:
sudo certbot renew --deploy-hook "systemctl reload nginx"ويُكتب هذا مرة واحدة في ملف التجديد (/etc/letsencrypt/renewal/example.com.conf، القسم [renewalparams]، السطر renew_hook) ثم يعمل من تلقاء نفسه.
2. تغيّر خادم الويب ولم يتغيّر التحدي
يتطلب تحدي HTTP-01 أن يُقدَّم ملف من /.well-known/acme-challenge/ عبر HTTP عادي. ويتعطّل ذلك عادة هكذا:
- أُضيف إلى الإعداد إعادة توجيه غير مشروطة من HTTP إلى HTTPS — فيتبع التحدي إعادة التوجيه ويفشل؛
- ظهرت قاعدة
location ~ /\.معdeny allفأغلقت كل دليل فيه نقطة، ومنها.well-known؛ - انتقل جذر الموقع بينما احتفظت إعدادات certbot بـ
--webroot-pathالقديم؛ - فُعِّل الحجب حسب الدولة أو المصادقة الأساسية فطالت خادم التحقق مع الجميع.
والترتيب الصحيح في الإعداد: أولًا location مخصص لـ /.well-known/acme-challenge/، وبعده فقط إعادة التوجيه العامة.
3. المؤقّت معطَّل
يعمل التجديد من مؤقّت systemd أو من مهمة cron، وكلاهما قد يُعطَّل خطأً أثناء تتبّع الأخطاء أو يُفقد عند نقل الخادم.
systemctl list-timers | grep certbot
sudo certbot renew --dry-runينفّذ الأمر الثاني دورة تجديد كاملة في وضع اختباري دون استهلاك حصتك. وهو الفحص الوحيد الذي يجيب مسبقًا عن سؤال «هل سيتجدد هذا بعد شهر» بدل الإجابة بأثر رجعي.
4. لم يعد نطاق يشير إلى هنا
تغطي الشهادة خمسة نطاقات، وانتقل أحدها إلى مضيف آخر، وتغيّر DNS. فيتوقف التحقق لذلك النطاق عن النجاح، ولا يجدّد certbot الشهادة بأكملها — بما في ذلك النطاقات الأربعة العاملة. والنطاقات الزائدة يجب إزالتها من الشهادة لا تجاهلها مع الرسالة.
5. بلغت حدود المعدّل
تحدّ Let’s Encrypt عدد الشهادات لكل نطاق أسبوعيًا. وهذا عادة نتيجة حلقة «لم ينجح، سأحاول مجددًا» أثناء تتبّع الأخطاء. وثمة خادم تجريبي للتجارب (--dry-run أو --test-cert)، وينبغي استخدامه قبل استنفاد الحد لا بعده.
افحص ما يُقدَّم لا ما هو مخزَّن
لكل فحص يعتمد على ملفات القرص عيب واحد: فقد يكون الملف جديدًا بينما يتلقى الزائر الشهادة القديمة. انظر من جانب العميل:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -subject -issuerوالخيار -servername إلزامي: فبدونه تحصل على خادم فيه عدة مواقع على شهادة المضيف الافتراضي الذي يأتي أولًا، لا التي قصدتها. وفي المخرج يكون notAfter هو تاريخ الانتهاء الحقيقي.
وما دمت هناك، افحص السلسلة:
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'وإن كانت هناك شهادة واحدة فقط، فالشهادة الوسيطة لا تُقدَّم. وتتسامح المتصفحات عادة مع هذا الإعداد — فهي تبني السلسلة بنفسها — لكن curl وتطبيقات الهاتف وعملاء Java سيفشلون في التحقق. وهذه هي الحالة الكلاسيكية «عندي يفتح بشكل ممتاز وعند العميل لا يعمل».
كم يومًا من التحذير
ثلاثون يومًا تحذير أول معقول: فهذا هو ما يتبقى حين يبدأ certbot محاولات التجديد أيضًا، فإن لم يحدث شيء حتى ذلك الحين فالآلية معطَّلة. وأربعة عشر يومًا هي التحذير الثاني، وهو يستوجب تصرفًا اليوم. وسبعة أيام حالة طارئة.
والمهم مراقبة كل الشهادات دفعة واحدة، بما فيها التي لم تأتِ من Let’s Encrypt: فالمشتراة لسنة تُنسى بأكثر موثوقية من غيرها، لأن الجميع ينسى خلال سنة أمرها وأمر صندوق البريد الذي تذهب إليه الإشعارات. وصفحة واحدة فيها النطاقات والتواريخ والأيام المتبقية تغلق الملف تمامًا — كما في العرض التوضيحي أدناه.