Certbot: احصل على شهادات Let's Encrypt وجدّدها بالطريقة الصحيحة

ما هو certbot، وما يفعله فعليًا

Certbot عميل ACME مجاني ومفتوح المصدر تصونه مؤسسة Electronic Frontier Foundation. وACME هو البروتوكول الذي تستخدمه Let's Encrypt (وعدد متزايد من جهات إصدار شهادات أخرى) لإصدار الشهادات بلا إنسان في الحلقة. ويتحدث certbot به نيابةً عنك: ينشئ مفتاح حساب، ويطلب شهادة من جهة الإصدار، ويبرهن أنك تتحكم بالنطاق، ويحفظ الشهادة والمفتاح على القرص، وإن سمحت له، يعدّل ضبط خادم الويب لديك ويجدّد كل شيء قبل انتهاء صلاحيته.

وإثبات التحكم هو تحدٍّ (challenge)، ويدعم certbot نوعين منه. HTTP-01: تطلب جهة الإصدار رمزًا عشوائيًا عند http://example.com/.well-known/acme-challenge/<token> على المنفذ 80، ويتأكد certbot من تقديم ذلك الملف. DNS-01: تبحث جهة الإصدار عن سجل TXT عند _acme-challenge.example.com، وينشره certbot (أو تنشره أنت). HTTP-01 هو الخيار الافتراضي السهل؛ وDNS-01 هو الطريقة الوحيدة للحصول على شهادة واسعة النطاق، والطريقة لإصدار شهادة لخادم لا يمكن الوصول إليه من الإنترنت.

ويحدد نوعان من الملحقات (plugins) من يفعل ماذا. المُوثِّق (authenticator) يجيب عن التحدي (--nginx، --apache، --webroot، --standalone، --manual، أو ملحق DNS مثل --dns-cloudflare). والمُثبِّت (installer) يضع الشهادة في ضبط خادم (nginx أو apache). ويقوم certbot --nginx بكلا الأمرين؛ أما certbot certonly ... فيجلب الشهادة فقط ويترك الضبط لك.

ويحطّ كل شيء تحت /etc/letsencrypt. والملفات التي توجّه إليها الخادم تعيش في /etc/letsencrypt/live/<cert-name>/: fullchain.pem (شهادتك مع الشهادة الوسيطة) وprivkey.pem. وهي روابط رمزية (symlinks) إلى archive/، فالمسارات لا تتغيّر أبدًا عبر التجديدات. وإن أردت خلفية عن ماهية الشهادة ولماذا هي مجانية، اقرأ شهادات SSL المجانية؛ أما هذا الدليل فعن الأداة.

تثبيت certbot: snap أولًا، وحزم التوزيعة ثانيًا

يُوصي مشروع certbot بحزمة snap على لينكس. وهي تتابع الإصدار الحالي (5.x في 2026)، وتحزّم بايثون خاصًا بها، وتثبّت مؤقِّت systemd للتجديد. أزل أي نسخة من التوزيعة أولًا حتى لا يتنازع نسختان من certbot على /etc/letsencrypt: sudo apt remove certbot، أو sudo dnf remove certbot، أو sudo yum remove certbot.

حزم التوزيعة تعمل وهي ما يملكه كثير من الخوادم أصلًا: sudo apt install certbot python3-certbot-nginx (أو python3-certbot-apache) على Debian وUbuntu، والأسماء نفسها من EPEL على RHEL وRocky وAlma. والمقايضة هي القِدَم: فتوزيعة LTS قد تُشحن مع نسخة certbot متأخرة بعدة إصدارات رئيسية، وهذا مهم الآن إذ تُقصّر Let's Encrypt عمر الشهادات (انظر قسم التجديد). وcertbot منشور أيضًا على PyPI وكصور Docker (certbot/certbot وصورة واحدة لكل ملحق DNS) إن فضّلت ذلك.

وبعد التثبيت، يخبرك certbot --version بما حصلت عليه، ويسرد sudo certbot certificates كل شهادة يديرها مع نطاقاتها وتاريخ انتهائها ومسارات ملفاتها.

التثبيت الموصى به على لينكس (snap)

# remove an OS-packaged certbot first, if present
sudo apt remove certbot

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

certbot --version
sudo certbot certificates

إصدار شهادة لـnginx وApache

ملحقا nginx وApache هما الطريق الأقصر. sudo certbot --nginx -d example.com -d www.example.com يجد كتلة server التي يطابق server_name فيها، ويجيب عن HTTP-01 من خلالها، ويكتب ssl_certificate وssl_certificate_key في تلك الكتلة، ويعيد تحميل nginx. وتضيف الإصدارات الحديثة إعادة التوجيه من HTTP إلى HTTPS افتراضيًا؛ ويعطّل --no-redirect ذلك. ويفعل --apache الشيء نفسه مع المضيفات الافتراضية (virtual hosts). ويحتاج كلاهما server_name / ServerName يطابق النطاق، وإلا لا يستطيع certbot معرفة أي كتلة يعدّل. جديد على الخادم نفسه؟ ابدأ بـما هو nginx.

Webroot هو الخيار حين تريد أن يبقى certbot بعيد اليد عن ضبطك: فهو يكتب ملف التحدي في مجلد يقدّمه خادمك العامل أصلًا. ويعني certonly أنك تضيف سطري ssl_ بنفسك، مرة واحدة؛ ثم تستبدل التجديدات الملفات خلف المسارات نفسها فقط.

Standalone يُشغّل خادم ويب صغيرًا خاصًا به على المنفذ 80. وهو للأجهزة التي لا تملك خادم ويب، أو التي تملك خادمًا ليس nginx أو Apache. ويجب أن يكون المنفذ 80 حرًّا خلال الإصدار وكل تجديد، فأوقف الخادم الآخر في خطّاف: --pre-hook "systemctl stop haproxy" --post-hook "systemctl start haproxy".

وكل -d يضيف اسمًا إلى الشهادة نفسها، ويصبح الاسم الأول اسم الشهادة. ولإضافة اسم لاحقًا، شغّل الأمر من جديد بالقائمة الكاملة مع --cert-name example.com؛ ويستبدل certbot الشهادة القديمة بدل إنشاء شهادة ثانية.

الطرق الأربع الشائعة للإصدار (اختر واحدة)

# nginx: issue and install
sudo certbot --nginx -d example.com -d www.example.com

# Apache: issue and install
sudo certbot --apache -d example.com -d www.example.com

# webroot: issue only; your server keeps serving /.well-known/acme-challenge/
sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com

# standalone: certbot listens on :80 itself
sudo certbot certonly --standalone -d example.com

# then, in nginx, for the webroot/standalone case:
#   ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
#   ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

الشهادات الواسعة النطاق مع DNS-01

تُصدِر Let's Encrypt شهادة *.example.com فقط عبر DNS-01. وتغطي الشهادة الواسعة النطاق مستوى واحدًا (shop.example.com، لا a.shop.example.com) ولا تغطي النطاق العاري، فاطلب كليهما: -d example.com -d '*.example.com'. ضع النجمة بين علامتي تنصيص حتى لا يوسّعها الصدفة (shell).

مع ملحق DNS ينشئ certbot سجلات TXT ويحذفها عبر واجهة برمجة مزوّد DNS لديك، وهذا ما يجعل التجديد تلقائيًا. وثمة ملحقات رسمية لـCloudflare وRoute 53 وGoogle Cloud DNS وDigitalOcean وLinode وOVH وخوادم RFC 2136 وغيرها، وملحقات من جهات خارجية لكثير غيرها. ومع snap تسمح أولًا للملحقات بالعمل بصلاحيات root (sudo snap set certbot trust-plugin-with-root=ok) ثم تثبّت snap الملحق. احتفظ بملف بيانات الاعتماد عند الصلاحية 600، وأعطِ رمز واجهة البرمجة أضيق نطاق يقدّمه مزوّدك (لـCloudflare، *Zone: DNS: Edit* على تلك المنطقة فقط).

ومع --manual، يطبع certbot قيمة TXT وينتظر حتى تضيفها يدويًا. وطلب example.com و*.example.com معًا يتطلب قيمتين لـTXT تحت الاسم نفسه _acme-challenge.example.com؛ انشر كلتيهما كسجلين منفصلين. تحقق بـdig +short TXT _acme-challenge.example.com قبل الضغط على Enter. والمشكلة: الشهادة اليدوية لا تتجدد تلقائيًا إلا إن قدّمت نصوص --manual-auth-hook و--manual-cleanup-hook تنفّذ عمل DNS، فاستخدم ملحقًا من أجل أي شيء طويل الأمد.

وإن لم يكن لمزوّد DNS لديك واجهة برمجة، يمكنك توجيه _acme-challenge.example.com بسجل CNAME إلى منطقة تتحكم بها؛ فتتبع جهة الإصدار CNAME وتقرأ سجل TXT هناك.

الشهادة الواسعة النطاق مع الجذر عبر ملحق Cloudflare لـDNS (snap)

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

# /root/.secrets/cloudflare.ini  (chmod 600)
#   dns_cloudflare_api_token = <token with Zone:DNS:Edit>

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

# by hand (no automatic renewal without hooks)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'

التجديد التلقائي: المؤقِّتات، والخطّافات، و--dry-run

لن تكتب مهمة cron لـcertbot؛ فالحزمة فعلت ذلك أصلًا. يثبّت snap مؤقِّت systemd باسم snap.certbot.renew.timer، وتثبّت حزم Debian وUbuntu certbot.timer، وتستخدم بعض الحزم ملفًا في /etc/cron.d/. وتشغّل المهمة certbot renew مرتين يوميًا، وهي تجدّد فقط الشهادات المستحقة وتخرج بصمت فيما عدا ذلك. شاهدها بـsystemctl list-timers | grep certbot.

متى تكون الشهادة مستحقة؟ منذ certbot 4.0، حين يبقى أقل من ثلث عمرها (أو نصفه، للشهادات التي مدتها 10 أيام أو أقل)، ويتبع certbot أيضًا تلميحات ACME Renewal Info (ARI) من جهة الإصدار. وهذا مهم لأن Let's Encrypt تُقصّر أعمار الشهادات: يتحول الملف الافتراضي من 90 إلى 64 يومًا في 10 فبراير 2027، وإلى 45 يومًا في فبراير 2028. وضبط يجدّد من سطر cron ثابت بـ"كل 60 يومًا" سينكسر؛ أما الضبط الذي يشغّل certbot renew يوميًا فلن ينكسر. وتوقفت Let's Encrypt أيضًا عن إرسال رسائل تذكير بانتهاء الصلاحية في 2025، فلن يحذّرك أحد إن فشل التجديد بصمت: راقب تاريخ انتهاء الشهادة بنفسك.

أعِد تحميل الخادم بعد التجديد. يُعيد مُثبِّتا nginx وApache التحميل نيابةً عنك. ومع webroot أو standalone أو ملحق DNS، أضف خطّاف نشر (deploy hook)، لا يعمل إلا حين تُجدَّد شهادة فعلًا. ضعه في الأمر عند الإصدار (--deploy-hook، يُحفظ في /etc/letsencrypt/renewal/<name>.conf) أو ضع نصًا قابلًا للتنفيذ في /etc/letsencrypt/renewal-hooks/deploy/.

اختبر دائمًا بـsudo certbot renew --dry-run. فهو يشغّل التجديد كاملًا مقابل بيئة تجريبية (staging) لـLet's Encrypt، بتحديات حقيقية، دون لمس شهاداتك الفعلية أو استخدام حدود المعدل الخاصة بالإنتاج.

تحقق من المؤقِّت، واختبر التجديد، وأعد تحميل nginx بعد كل تجديد

systemctl list-timers | grep certbot

sudo certbot renew --dry-run

# reload nginx whenever any certificate is renewed
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

# when does each certificate expire?
sudo certbot certificates

حدود المعدل في Let's Encrypt التي قد تصادفها فعليًا

حدود Let's Encrypt سخيّة للاستخدام العادي، ومؤلمة خلال جلسة تصحيح أخطاء. وهذه هي الحدود التي تلدغ:

5 شهادات لكل مجموعة أسماء مطابقة تمامًا خلال 7 أيام. فإصدار example.com + www.example.com خمس مرات في أسبوع، مثلًا بإعادة تشغيل نص تهيئة أو مسح /etc/letsencrypt عند كل بدء حاوية، يقفل تلك المجموعة بالضبط لأيام. ويقول الخطأ *too many certificates already issued for this exact set of identifiers* ويعطي وقت إعادة المحاولة. ولا يوجد تجاوز لهذا الحد. وتغيير مجموعة الأسماء (إضافة اسم واحد آخر) يحصل على حد جديد، لكن الحل الحقيقي هو الاحتفاظ بـ/etc/letsencrypt على تخزين دائم.

5 عمليات تحقق فاشلة لكل اسم مضيف لكل حساب في الساعة. سجل DNS خاطئ مع حلقة إعادة محاولة يستهلك هذا في دقائق.

50 شهادة لكل نطاق مسجَّل خلال 7 أيام، تُحسَب عبر كل النطاقات الفرعية لـexample.com، و300 طلب جديد لكل حساب خلال 3 ساعات. ومنصات الاستضافة ذات النطاقات الفرعية الكثيرة تصادف هذه أولًا.

وتُعامَل التجديدات بلطف: فالتجديد الذي يستخدم ARI، كما يفعل certbot الحالي، معفى من كل الحدود، والتجديد العادي لمجموعة الأسماء نفسها معفى من حدَّي النطاق والطلب.

والقاعدة للتجارب: أضف --test-cert (ويُسمى أيضًا --staging) أو استخدم --dry-run. وللبيئة التجريبية حدود أعلى بكثير، وتُصدِر شهادات لا تثق بها المتصفحات، وهذا بالضبط ما تريده أثناء إنجاح التحدي.

أخطاء certbot الشائعة وكيفية إصلاحها

انتهاء المهلة أثناء الاتصال / رفض الاتصال على المنفذ 80. يبدأ HTTP-01 دائمًا على المنفذ 80، حتى لو كان موقعك يقدّم HTTPS فقط. افتح المنفذ 80 في الجدار الناري ومجموعة الأمان السحابية؛ وإعادة توجيهه إلى HTTPS أمر مقبول، لأن جهة الإصدار تتبع إعادات التوجيه. وإن تعذّر فتح المنفذ 80، انتقل إلى DNS-01.

استجابة غير صالحة / 404 عند /.well-known/acme-challenge/. وصل الطلب إلى خادم، لكن ليس الصحيح أو ليس المجلد الصحيح. الأسباب النمطية: سجل A ما زال يشير إلى مضيف قديم، أو موازن تحميل يرسل الطلب إلى عقدة أخرى، أو كتلة location أو إعادة كتابة (rewrite) تلتقط المسار، أو -w يشير إلى webroot خاطئ. اختبره بنفسك: أنشئ ملفًا تحت .well-known/acme-challenge/ وجرّب curl عليه عبر HTTP العادي من الخارج.

سجل AAAA يشير إلى مكان آخر. إن كان للاسم عنوان IPv6، تتحقق Let's Encrypt عبر IPv6 أولًا. وسجل AAAA قديم يجيب من خادم مختلف يجعل التحقق يفشل حتى لو كان IPv4 سليمًا. أصلح سجل AAAA أو احذفه؛ يُظهره dig AAAA example.com.

مشكلة DNS: NXDOMAIN / لا توجد سجلات A صالحة. الاسم لا يُحلَّل بعد. انتظر الانتشار، وتحقق من السجل عند محلل خارجي، لا من جهازك فقط.

سجل CAA يمنع الإصدار. سجل CAA على النطاق (أو أحد آبائه) يسرد جهات الإصدار المسموح لها، وLet's Encrypt غير موجودة فيه. أضف example.com. CAA 0 issue "letsencrypt.org"، وissuewild أيضًا إن ضبطت واحدًا للشهادات الواسعة النطاق. خلفية في ما هو DNS.

سجل TXT غير صحيح / لم يُعثر على سجل TXT. فُحِص DNS-01 قبل أن ينتشر السجل، أو نُشرت قيمة واحدة فقط من قيمتي الشهادة الواسعة النطاق. ارفع قيمة --dns-<provider>-propagation-seconds الخاصة بالملحق أو انتظر أطول في النمط اليدوي.

تعذّر العثور تلقائيًا على كتلة خادم مطابقة. يحتاج ملحق nginx إلى server_name يطابق الاسم المطلوب. أضفه، وشغّل nginx -t، وأعد المحاولة.

تم إصدار شهادات كثيرة جدًا أصلًا. حد التكرار أعلاه. استخدم الشهادة التي تملكها أصلًا (certbot certificates)، واختبر بـ--staging من الآن فصاعدًا.

Certbot على ويندوز: استخدم عميل ACME أصيلًا لويندوز

أوقف certbot دعم ويندوز. آخر مُثبِّت لويندوز شُحن مع certbot 2.9.0 في فبراير 2024، ويوجّه موقع certbot الآن مستخدمي ويندوز إلى بدائل مدرجة من المجتمع. والمُثبِّتات القديمة التي لا تزال توجد في مواقع التنزيل متأخرة بسنوات ولن تحصل على تغييرات التجديد التي تطرحها Let's Encrypt، فلا تبنِ عليها.

وما تستخدمه بدلًا منها يعتمد على الخادم:

IIS أو أي خادم ويندوز: كان win-acme الخيار المعتاد: أداة سطر أوامر تربط الشهادة في IIS، وتكتبها في متجر شهادات ويندوز أو في ملفات PEM/PFX، وتنشئ مهمة مجدولة للتجديد. ويطوّر صائنها الآن simple-acme، الموصوف بأنه بديل متوافق مع الإصدارات السابقة يُستبدَل مباشرة، فتحقق من ذلك المشروع قبل نشر جديد.

أتمتة PowerShell: Posh-ACME وحدة PowerShell بمجموعة كبيرة من ملحقات DNS للشهادات الواسعة النطاق.

إن فضّلت واجهة رسومية: Certify The Web عميل رسومي لـIIS.

وإن أردت certbot فعلًا: شغّله داخل WSL 2 من أجل الإصدار، ثم صدّر الملفات إلى ويندوز. وهذا عملي لشهادات DNS-01 التي تنسخها إلى مكان آخر، وأقل عملية لموقع IIS يحتاج ربطًا تلقائيًا.

ولا شيء من هذا تزكية: فكلها مشاريع من جهات خارجية، فاقرأ وثائقها الحالية قبل الاعتماد عليها.

إلغاء الشهادات وحذفها

ألغِ (revoke) الشهادة حين يحتمل تسرّب المفتاح الخاص، أو حين لا تتحكم بالنطاق بعد الآن. يحتاج certbot إلى اسم الشهادة أو ملفها، وسببًا: keycompromise أو superseded أو cessationofoperation أو affiliationchanged أو unspecified (الافتراضي). وبعد الإلغاء، يعرض certbot حذف الملفات المحلية؛ أجب بنعم، وإلا سيستمر بمحاولة تجديد شهادة مُلغاة. وإن تسرّب المفتاح، أصدِر الشهادة البديلة بمفتاح جديد، وهذا ما يفعله certbot افتراضيًا.

واحذف بلا إلغاء حين تتوقف فقط عن استخدام شهادة، مثلًا بعد نقل موقع: certbot delete --cert-name example.com يزيلها من /etc/letsencrypt ومن التجديد. أزل سطور ssl_ المطابقة من ضبط الخادم أولًا، وإلا سيفشل nginx في البدء عند إعادة التحميل التالية.

وتوقفت Let's Encrypt عن تشغيل OCSP؛ وتتعرف المتصفحات على الإلغاءات عبر CRLs، فالإلغاء لا يكون مرئيًا في كل مكان فورًا. وهذا سبب آخر لإبقاء المفاتيح الخاصة قابلة للقراءة من root فقط.

ألغِ شهادة مُخترَقة، أو أزل شهادة لا تحتاجها بعد الآن

sudo certbot revoke --cert-name example.com --reason keycompromise

sudo certbot delete --cert-name example.com

خلف CDN: من يحمل الشهادة

حين يقف موقع خلف CDN أو وكيل عكسي آخر، لا يرى الزوّار شهادة أصلك (origin) بعد الآن. فالحافة (edge) تُنهي TLS بشهادتها الخاصة، والاتصال من الحافة إلى أصلك مصافحة منفصلة. يمكنك الاحتفاظ بـcertbot على الأصل لتأمين تلك القفزة الثانية، لكن الشهادة التي يفحصها المتصفح هي شهادة الحافة.

على CDN.com.tr، تتولى Auto SSL شهادة الحافة: فكل شهادة هي شهادة Let's Encrypt مُتحقَّقة النطاق بلا رسم منفصل. وجّه اسم مضيف إلى الحافة بـCNAME وسيحصل ذلك الاسم على شهادته الخاصة، مُتحقَّقة عبر HTTP. وفوّض DNS إلى CDN.com.tr وسيحصل النطاق الجذر على شهادة واسعة النطاق تغطي الجذر وكل نطاق فرعي من المستوى الأول، مُتحقَّقة بسجل DNS. وتُطلَب الشهادة بمجرد أن يُتحقَّق من النطاق ويشير DNS الخاص به إلينا، وتُجدَّد تلقائيًا 30 يومًا قبل انتهاء صلاحيتها، فلا يوجد مؤقِّت certbot لمراقبته.

تنقل موقعًا حيًّا؟ يُصدِر معالج الانتقال بلا توقف الشهادة الواسعة النطاق عبر سجل TXT عند مزوّد DNS الحالي قبل التبديل، تمامًا كتشغيل certbot --manual لـDNS-01، وكذلك التشغيل، لا تتجدد تلقائيًا ما دام DNS خارج CDN.com.tr. وإن كنت تملك شهادة OV أو EV من جهة إصدار أخرى، يمكنك رفعها وإرفاقها باسم مضيف؛ وتحصل على سياسة TLS نفسها التي تحصل عليها الشهادة التلقائية. يشرح دليل TLS ما تتفاوض عليه الحافة، وHSTS هو الخطوة التالية بعد أن تصبح HTTPS موثوقة.