شهادة بدل واحدة لعدة خوادم: تجديد لا يتعطل

شهادة البدل (wildcard) على خادم واحد أمر سهل. تنتقل إلى تحدي DNS-01، فيجددها certbot كل شهرين تقريبًا، وتنسى وجودها. تبدأ المشكلة حين يجب أن تعيش *.example.com نفسها على جهاز ثانٍ، ثم على NAS، ثم على خادم سحابي أمام كل شيء. ينجح التجديد على جهاز واحد ويفشل بصمت على البقية، وتكتشف ذلك حين يعرض المتصفح تحذيرًا أحمر.

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

لماذا يفشل تجديد كل خادم بمفرده

لا شيء في Let's Encrypt يمنع عدة خوادم من طلب شهادة البدل نفسها. المشكلات حول ذلك.

حدود المعدل. تسمح Let's Encrypt بحد أقصى 5 شهادات لكل مجموعة معرّفات متطابقة كل 7 أيام، والحد عام: تُحسب طلبات كل الحسابات. ثلاثة خوادم، أُعيد تثبيت كل منها أو اختباره مرتين، قد تستهلك ذلك في ساعات.

تفويض التحدي. هذا هو السبب وراء «آخر خادم فقط يتجدد». في acme-dns يعيد كل تسجيل نطاقًا فرعيًا عشوائيًا خاصًا به، وتوجّه _acme-challenge.example.com إليه بسجل CNAME. ولا يمكن للاسم أن يحمل إلا CNAME واحدًا. حين يسجّل الخادم الثالث وتحدّث السجل، يواصل الخادمان الأولان كتابة قيم TXT في نطاقات فرعية لم تعد الجهة المصدرة تنظر إليها، فيفشل تجديدهما بخطأ تحقق DNS.

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

HTTP-01 لا يتوسع أيضًا. خلف موجّه منزلي أو عنوان IP عام واحد، لا يمكن تمرير المنفذ 80 إلا إلى جهاز واحد. في إحدى شبكاتنا كان المنفذ 80 الوارد محجوبًا في المصدر، وفشل تجديد HTTP-01 لأسابيع قبل أن ينتبه أحد. لا يعتمد DNS-01 على أي منفذ وارد، ولهذا هو الأساس الصحيح هنا.

النمط: جهة إصدار واحدة، ثم الدفع

اختر جهازًا واحدًا يملك الشهادة. يحمل رمز DNS API، ويشغّل certbot أو acme.sh، وهو الوحيد الذي يتواصل مع الجهة المصدرة. بقية الخوادم تستقبل الملفات فقط.

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

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

استخدم خطاف النشر لا خطاف ما بعد التجديد

لدى certbot ثلاثة أنواع من الخطافات، ووثائق certbot واضحة في توقيت كل منها:

لا تعمل الخطافات إلا حين تستحق الشهادة التجديد، لذا يمكن لمهمة cron أو مؤقت systemd تشغيل certbot renew كثيرًا دون آثار جانبية. الفرق في ما يحدث عند فشل التجديد. خطاف ما بعد التجديد يعمل رغم ذلك. إذا وضعت سكربت النسخ فيه، فإن تجديدًا فاشلًا يدفع الملفات القديمة ويعيد تحميل كل الخوادم، وتقول سجلاتك «تم النشر» بينما تقترب الشهادة من الانتهاء. أما خطاف النشر فلا يعمل إلا بعد تجديد ناجح.

يحصل خطاف النشر أيضًا على متغيرين: $RENEWED_LINEAGE، وهو مجلد live الذي يحوي الملفات الجديدة (مثل /etc/letsencrypt/live/example.com)، و$RENEWED_DOMAINS، وهي الأسماء على الشهادة المجددة. وأي ملف تنفيذي في /etc/letsencrypt/renewal-hooks/deploy/ يعمل كخطاف نشر، فلا تحتاج إلى تذكّر الخيار.

نسخة مبسطة:

#!/bin/sh
# /etc/letsencrypt/renewal-hooks/deploy/push-certs.sh
set -e
for host in web2 nas vm-proxy; do
  rsync -aL "$RENEWED_LINEAGE/" "certsync@$host:/etc/ssl/wildcard/"
  ssh "certsync@$host" 'sudo nginx -t && sudo systemctl reload nginx'
done

ثلاثة تفاصيل مهمة. يَنسخ rsync -L الملفات الحقيقية، لأن مجلد live/ يحوي روابط رمزية إلى archive/. ويجب أن يملك المستخدم certsync على كل خادم مفتاح SSH مقيدًا بهذه المهمة، وصلاحية sudo فقط لاختبار nginx وإعادة تحميله. ويعمل nginx -t قبل إعادة التحميل، فلا يُسقط إعداد معطوب على خادم واحد الموقع.

خوادم البريد تحتاج المعاملة نفسها. Postfix وDovecot ومعظم غيرها تحمّل الشهادة عند البدء، فتستمر في تقديم القديمة حتى إعادة التحميل. إذا كان خادم بريدك يستخدم شهادة البدل أيضًا، أضف أمر إعادة تحميله إلى الحلقة. تناولنا جانب منظومة البريد في مقارنة Mailcow وStalwart وMailu في بيئة الإنتاج.

اختبره دون انتظار شهرين

شغّل certbot renew --dry-run -v على جهة الإصدار أولًا. يتواصل مع خادم الاختبار ويعرض خطأ التحدي الحقيقي إن وُجد. السجل الكامل في /var/log/letsencrypt/letsencrypt.log. لكن انتبه: بحسب وثائق certbot، لا تعمل خطافات النشر أثناء التشغيل التجريبي إلا إذا أضفت --run-deploy-hooks. من دونه تكون قد اختبرت التجديد لا التوزيع.

ثم افحص ما يقدّمه كل خادم فعلًا، لا ما على قرصه:

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

إذا اختلفت التواريخ بين الخوادم، فقد فشل النسخ أو إعادة التحميل على ذلك الخادم. ضع هذا الفحص في المراقبة مع تنبيه عند بقاء 14 يومًا. لا يكلف شيئًا ويلتقط الأعطال التي لا يراها الخطاف. وإذا كانت الخوادم تعمل في حاويات، فأرسل مخرجات الخطاف إلى stdout لتصل مع بقية سجلاتك، كما شرحنا في لماذا يجب أن تذهب سجلات الحاويات إلى stdout.

الشهادات الأقصر تجعل هذا ضروريًا

أعلنت Let's Encrypt الجدول الزمني لتقصير مدة الشهادات، تماشيًا مع المتطلبات الأساسية لمنتدى CA/Browser. في 10 فبراير 2027 ينتقل الملف الافتراضي من شهادات 90 يومًا إلى 64 يومًا. وفي 16 فبراير 2028 ينتقل إلى 45 يومًا، وتنخفض مدة إعادة استخدام التحقق من النطاق من 30 يومًا إلى 7 ساعات. ويُصدر الملف الاختياري tlsserver شهادات 45 يومًا اعتبارًا من 13 مايو 2026 بحسب الجدول.

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

قائمة تحقق

• خادم واحد يطلب شهادة البدل ويجددها. رمز DNS موجود هناك فقط.
• إذا استخدمت acme-dns، فتسجيل واحد وCNAME واحد لكل اسم.
• سكربت النسخ وإعادة التحميل في renewal-hooks/deploy/، لا في خطاف ما بعد التجديد.
• مفتاح SSH مقيد لكل خادم، وsudo فقط للاختبار وإعادة التحميل.
• nginx -t (أو فحص خادم البريد) قبل كل إعادة تحميل.
• تشغيل تجريبي مع --run-deploy-hooks مرة بعد الإعداد.
• فحص خارجي لانتهاء الصلاحية على كل اسم مضيف، مع تنبيه عند 14 يومًا.

الأسئلة الشائعة