Certbot على Ubuntu 24.04: Apache وLet's Encrypt

ما الذي تبنيه

موقع Apache على Ubuntu 24.04 يستجيب عبر HTTPS بشهادة Let's Encrypt مجانية وموثوقة لدى المتصفحات — يصدرها Certbot، ويجدّدها تلقائيًا مؤقّت (timer) في systemd لن تفكر فيه بعد ذلك أبدًا. الأمر الذي ينجز المهمة سطر واحد. أما كل ما قد يفشل فيفشل قبل ذلك السطر: مضيف افتراضي (vhost) بلا ServerName، أو المنفذ 80 مغلقًا عند جدار حماية المزوّد، أو DNS ما زال يشير إلى الخادم القديم. لذلك يقضي هذا الدليل معظم وقته في الشروط المسبقة، ويذكر نص الخطأ الدقيق الذي تطبعه كل غلطة.

ملاحظتان بخصوص النطاق. إذا كان خادم الويب لديك هو nginx، فالمسار له الشكل نفسه لكن الإضافة (plugin) والإعدادات تختلف — استخدم بدلًا من ذلك نسخة nginx من هذا الدليل. وإذا كان ما تؤمّنه داخليًا محضًا — لوحة إدارة على عنوان خاص، أو جهاز تجريبي لا يزوره أحد غيرك — فأنت لست بحاجة إلى هيئة إصدار شهادات على الإطلاق؛ شهادة موقّعة ذاتيًا تحتاج آلية أبسط وتعمل دون اتصال بالإنترنت.

المتطلبات المسبقة، والطرق الثلاث التي يفشل بها هذا حتى قبل أن يعمل Certbot

• أن يكون Apache يخدم موقعك بالفعل عبر HTTP عادي. إضافة Apache الخاصة بـ Certbot تعدّل موقعًا موجودًا؛ ولا تُنشئ موقعًا جديدًا. إذا كنت تبدأ من خادم VPS خالٍ، فابنِ أولًا حزمة LAMP على Ubuntu 24.04 ثم عد إلى هنا — هذا الدليل هو فصل TLS المفقود منها.
• نطاق عام له سجل A يشير إلى عنوان خادم VPS لديك. تحدي (challenge) HTTP-01 الخاص بـ Let's Encrypt يعني أن خوادم التحقق لديهم تتصل بجهازك من الإنترنت: لا مكان لخادم منزلي خلف NAT بلا إعادة توجيه منفذ، ولا لأسماء .local، ولا لعناوين IP مجرّدة. يجب أن يعيد dig +short example.com عنوان VPS لديك، وإن كنت قد غيّرت DNS خلال الساعة الأخيرة، فانتظر انقضاء TTL للسجل القديم قبل الإصدار.
• إن وُجد سجل AAAA، فيجب أن يكون صحيحًا. تفضّل Let's Encrypt الاتصال عبر IPv6 متى نُشر سجل AAAA، لذلك سجل AAAA قديم يفشل في التحقق حتى وإن نجح curl تمامًا من حاسوبك المحمول — على الأرجح عبر IPv4. انشر سجل AAAA صحيحًا أو لا تنشر سجلًا إطلاقًا.

يجب أن يكون المنفذ 80 و443 مفتوحين في ufw وكذلك في جدار الحماية الشبكي لدى مزوّد الخدمة — فمعظم لوحات الاستضافة لديها جدار حماية ثانٍ لا يراه نظام التشغيل أبدًا. يتحقق HTTP-01 تحديدًا عبر المنفذ 80؛ ولا يمكنك تنفيذ هذا بالاعتماد على المنفذ 443 وحده.

sudo ufw allow "Apache Full"
sudo ufw status

مع توفر ذلك، تستغرق المهمة كلها خمس عشرة دقيقة، عشر منها للقراءة.

Certbot عبر snap أم apt؟ على 24.04، أصبح apt مناسبًا أخيرًا

انتقل Certbot إلى توزيع snap منذ سنوات لسبب وجيه: تجمّدت حزم التوزيعات. جاءت Ubuntu 20.04 بالإصدار Certbot 0.40 ولم تحرّكه أبدًا، وسئم المشروع من ملاحقة أخطاء عمرها خمس سنوات. على 24.04 زال ذلك السبب — يوفّر الأرشيف الإصدار Certbot 2.9.0، وهو إصدار من الجيل الحالي، وتُبقيه unattended-upgrades مُحدَّثًا. توصيتي لهذا النظام: استخدم apt. فأنت تتجنّب برنامج snapd الخفي (daemon)، وتُثبَّت إضافة Apache ضمن المعاملة نفسها، ويندمج مؤقّت التجديد مع systemd بالطريقة الاعتيادية في Debian.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

النتيجة الصحيحة: certbot 2.9.0. حزمة python3-certbot-apache هي الإضافة التي تقرأ إعدادات Apache لديك وتعدّلها — فبدونها، يفشل certbot --apache بالرسالة The requested apache plugin does not appear to be installed.

يبقى snap الخيار الصحيح في حالتين: أن تريد أحدث إصدار من Certbot في يوم صدوره، أو أن تحتاج إلى إضافة DNS لا تُوزَّع إلا كـ snap (والعديد من إضافات المزوّدين من عائلة certbot-dns-* كذلك). إن اتجهت هذا الاتجاه:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

أيًّا كان اختيارك، لا تُشغّل الاثنين معًا أبدًا. فتثبيتان يعنيان مجدولَي تجديد يتنازعان على /etc/letsencrypt، وقد لا يكون certbot الذي يجده الـ shell لديك ضمن PATH هو نفسه الذي يملك شهاداتك. سطر apt remove أعلاه ليس زخرفة اختيارية.

يجب أن يكون الـ vhost الذي يعدّله Certbot موجودًا بالفعل: ServerName هو كل ما في الأمر

يعمل certbot --apache عبر إيجاد المضيف الافتراضي على المنفذ 80 الذي يطابق ServerName أو ServerAlias الخاص به مع كل نطاق -d تمرره، ثم إثبات التحكم بالنطاق من خلاله، ثم كتابة توأم SSL لذلك الـ vhost. لا ServerName مطابق، لا تطابق — وملف 000-default.conf الافتراضي في Ubuntu يأتي مع ServerName معطّلًا بعلامة تعليق. هذا السطر المُعلَّق الوحيد هو السبب الأكثر شيوعًا لفشل الأمر الكبير الوحيد في هذا الدليل.

لذلك، قبل أن تلمس Certbot، امنح الموقع vhost حقيقيًا قائمًا على الاسم. أنشئ /etc/apache2/sites-available/example.com.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

فعّله وتأكد أن Apache يحلّله ويوجّه الاسم إليه معًا:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

يجب أن يطبع configtest عبارة Syntax OK. وإن طبع أيضًا AH00558: apache2: Could not reliably determine the server's fully qualified domain name، فهذا تحذير بشأن الـ ServerName العام، لا الخاص بالـ vhost لديك — غير ضار هنا، ويُسكَت بالأمر echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

مخرجات -S هي الفحص المهم. تريد رؤية سطر يشبه port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) مع alias www.example.com تحته — يُبلغ Apache عن رابط sites-enabled الرمزي الذي قرأه فعلًا، لا الملف الذي عدّلته في sites-available. إن لم يكن example.com مُدرجًا أمام المنفذ 80، فلن يجده Certbot أيضًا.

إصدار الشهادة: certbot --apache

sudo certbot --apache -d example.com -d www.example.com

يسأل التشغيل الأول عن ثلاثة أمور: عنوان بريد إلكتروني (يُستخدم لحساب ACME الخاص بك ولإشعارات الجهة المُصدِرة (CA) العاجلة؛ لم تعد Let's Encrypt ترسل تنبيهات انتهاء الصلاحية، لذا مراقبة التجديدات مسؤوليتك أنت)، والموافقة على شروط Let's Encrypt، وما إذا كنت تريد مشاركة بريدك الإلكتروني مع EFF. لم يعد هناك سؤال عن إعادة التوجيه: فمنذ Certbot 2.0 يعيد مثبّت Apache توجيه HTTP إلى HTTPS افتراضيًا، وهذا ما تريده. مرّر --no-redirect إن كنت فعلًا بحاجة إلى أن يظل HTTP العادي يخدم المحتوى.

يبدو النجاح هكذا، وينبغي أن تقرأه لا أن تتصفحه سريعًا:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

خلف هذه الرسالة، نفّذ Certbot أربعة أمور: فعّل وحدة ssl في Apache إن لم تكن مفعّلة بالفعل، وكتب example.com-le-ssl.conf — نسخة من الـ vhost لديك على *:443 مع SSLEngine on ومسارات الشهادة — وفعّله، وأضاف كتلة RewriteRule إلى الـ vhost الأصلي على المنفذ 80 تعيد توجيه كل شيء بالكود 301 إلى HTTPS. ملف الـ vhost الأصلي لديك يُعدَّل لا يُستبدَل، ويقف توأم SSL بجانبه حيث يمكنك قراءة كل سطر أضافه.

أين تقيم الشهادة فعليًا، ولماذا لا تنسخها أبدًا

يستقر كل شيء تحت /etc/letsencrypt/live/example.com/: fullchain.pem (الشهادة مع السلسلة الوسيطة — ما ينبغي أن تشير إليه الخوادم)، وprivkey.pem (المفتاح الخاص، قابل للقراءة من root فقط)، بالإضافة إلى cert.pem وchain.pem للبرمجيات التي تريد الأجزاء منفصلة. هذه روابط رمزية إلى /etc/letsencrypt/archive/، وهذا التوجيه غير المباشر هو آلية التجديد: يكتب التجديد ملفات جديدة في archive/ ويعيد توجيه الروابط الرمزية إليها. وجّه أي برنامج آخر إلى مسارات live/ وسيحصل على التجديدات مجانًا؛ وانسخ الملفات إلى مكان آخر وتكون قد بنيت لنفسك عطلًا بعد 90 يومًا.

الملف الآخر الجدير بالمعرفة هو /etc/letsencrypt/renewal/example.com.conf، الذي يسجّل كيف صدرت هذه الشهادة — authenticator = apache، وinstaller = apache، والنطاقات — بحيث يستطيع التجديد تكرار العملية دون إشراف، بما في ذلك إعادة تحميل Apache بعد ذلك.

التجديد مجدوَل بالفعل: تحقق منه، لا تبنه

تدوم شهادات Let's Encrypt 90 يومًا بحكم التصميم، وقد ثبّتت حزمة apt الآلية بالفعل: مؤقّت systemd يشغّل Certbot مرتين يوميًا في أوقات عشوائية، ويجدّد أي شهادة تبعد أقل من 30 يومًا عن انتهاء صلاحيتها. لا تُضِف مهمة cron فوق ذلك؛ فمجدوِل ثانٍ لا يضيف شيئًا سوى ضجيج في السجلّات وتعرّضًا لحدود المعدل (rate limit).

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

يُظهر الأمر الأول أن المؤقّت نشط، بوقت NEXT في مكان ما خلال الساعات الـ24 القادمة — الجدولة مرتين يوميًا بتأخير عشوائي، لذا فالوقت الدقيق غير متوقَّع عمدًا (في تثبيت snap، المؤقّت هو snap.certbot.renew.timer بدلًا من ذلك). ينفّذ التنفيذ التجريبي (dry run) محاكاة تجديد كاملة مقابل بيئة Let's Encrypt التجريبية (staging): تحدٍ حقيقي، ولا شهادة تُصدَر، ولا تكلفة على حدود المعدل. النتيجة الصحيحة تنتهي بـ:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

إن فشل التنفيذ التجريبي، فسيفشل التجديد الحقيقي بعد نحو 60 يومًا بالطريقة نفسها — أصلحه الآن، بينما لا تزال الشهادة الحالية أمامها كامل عمرها. المتهم المعتاد قاعدة جدار حماية أُضيفت بعد الإصدار فأغلقت المنفذ 80 من جديد.

تحقق باستخدام curl، وما ينبغي أن تقوله القفلة

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

ينبغي أن يعيد الأمر الأول HTTP/1.1 301 Moved Permanently مع ترويسة Location: https://example.com/ — وهذه هي إعادة التوجيه التي ثبّتها Certbot. وينبغي أن يعيد الثاني HTTP/1.1 200 OK دون أي شكوى TLS من curl. ويطبع الثالث الجهة المُصدِرة — سطر O = Let's Encrypt مع اسم شائع (CN) قصير مثل R12 أو E7 — وقيمة notAfter تبعد نحو 90 يومًا. في المتصفح تحصل على القفلة، والنقر عليها يُظهر الجهة المُصدِرة نفسها. إن نجح curl وحذّر المتصفح، فأنت شبه متأكد من أنك تنظر إلى صفحة مخزَّنة مؤقتًا أو اسم مضيف خاطئ، لا مشكلة في الشهادة.

مواقع متعددة: شهادة SAN واحدة أم شهادة لكل موقع

كلا الخيارين يعمل ويتجدد بالطريقة نفسها. للمواقع غير المرتبطة على الجهاز نفسه، شغّل أمر الإصدار مرة لكل موقع — يحصل كل واحد على دليله الخاص تحت live/ وإعداد تجديده الخاص، ومشكلة في نطاق واحد لا تعطّل تجديد البقية أبدًا. هذا خياري الافتراضي.

لموقع واحد بعدة أسماء، ضعها على شهادة SAN واحدة — يمكن للشهادة الواحدة أن تضم حتى 100 اسم. لقد فعلت هذا بالفعل أعلاه مع example.com وwww.example.com. لإضافة اسم إلى شهادة موجودة لاحقًا، أعد الإصدار باسم الشهادة والقائمة الكاملة الجديدة:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

يلاحظ Certbot تغيّر مجموعة النطاقات، ويطلب منك تأكيد التوسيع، ويستبدل الشهادة في مكانها — نفس مسار live/، فلا شيء آخر يحتاج إلى لمسه. لاحظ أن القائمة استبدال لا إضافة: احذف www من هذا الأمر وستُسقطه الشهادة الجديدة بصمت.

الشهادات الشاملة تحتاج DNS-01، وعادةً لا تحتاج إلى شهادة شاملة

لا يستطيع HTTP-01 إصدار *.example.com — فوضع ملف على خادم ويب يثبت التحكم باسم مضيف واحد، لا بفضاء أسماء كامل. تتطلب الشهادات الشاملة (wildcard) تحدي DNS-01: يضع Certbot سجل TXT عند _acme-challenge.example.com، وهو ما يعني عمليًا إضافة من عائلة certbot-dns-* تعتمد على بيانات اعتماد API لمزوّد DNS لديك، أو تعديل سجلات TXT يدويًا عند كل تجديد بخيار --manual (أمر مضنٍ — لا تجعله جزءًا من خطتك). الشرح الكامل، من آلية سجل TXT إلى إضافة تجدّد دون إشراف، موجود في الشهادات الشاملة مع Certbot عبر DNS-01. نصيحة صادقة: إن كان لديك أربعة نطاقات فرعية معروفة، فشهادة SAN تسردها كلها أبسط من شهادة شاملة ولا تحتاج مفاتيح API لـ DNS جالسة على الخادم.

أنماط الفشل، مع النصوص التي سترى

يرفض Certbot البدء لأن إعدادات Apache معطوبة.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

تشغّل الإضافة configtest قبل أن تلمس أي شيء وتتوقف إن كان Apache نفسه غير راضٍ — الـ\n حرفية لأن Certbot يطبع تمثيل (repr) الاستثناء. شغّل sudo apache2ctl configtest بنفسك: فهو يذكر الملف والسطر — عادة خطأ كتابي من التعديل اليدوي، أو SSLCertificateFile يشير إلى مسار لم يعد موجودًا، أو وحدة مذكورة لكن غير مفعّلة. أصلح حتى تحصل على Syntax OK، ثم أعد تشغيل Certbot.

لا يطابق أي vhost النطاق.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

هذا هو فشل ServerName المفقود المذكور آنفًا، يظهر عند وقت الإصدار. بحث Certbot في كل vhost مفعّل على المنفذ 80 عن ServerName/ServerAlias يطابق -d لديك ولم يجد شيئًا. يُظهر sudo apache2ctl -S ما يوجّهه Apache فعليًا؛ أضف سطر ServerName إلى الـ vhost الصحيح، أعد التحميل، وحاول مجددًا. وهناك حالة قريبة هي وصول التحقق إلى الـ vhost الخطأ — تعود استجابة التحدي بـ Invalid response ... 404 لأن موقعًا آخر اعترض الطلب. التشخيص نفسه، الأداة نفسها: apache2ctl -S.

تنتهي مهلة التحقق.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

لم تستطع Let's Encrypt فتح اتصال TCP بالمنفذ 80 عند العنوان الذي يعلنه DNS لديك. بترتيب الاحتمال: جدار الحماية الشبكي لدى مزوّد الخدمة (منفصل عن ufw، ويُضبط في لوحة الاستضافة)، أو قواعد ufw التي لا تسمح إلا بالمنفذ 443 أو SSH فقط، أو DNS ما زال يشير إلى خادم سابق، أو مشكلة AAAA القديم — إذ حاولت خوادمهم الاتصال عبر IPv6 بينما يجيب خادمك عبر IPv4 فقط. اختبر من خارج الـ VPS: يعيد curl -I http://example.com من حاسوبك المحمول إنتاج ما يراه المتحقق لديهم.

أوقعتك إعادة المحاولة في حدّ للمعدل.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

تسمح Let's Encrypt بـ 5 تحققات فاشلة لكل اسم مضيف لكل حساب في الساعة — ومنذ إعادة صياغة حدود المعدل لديهم عام 2025 أصبح هذا "دلوًا" يمتلئ من جديد، يستعيد نحو محاولة واحدة كل 12 دقيقة تقريبًا — وقرع إعادة المحاولة على جدار حماية معطوب يستنفده بسرعة. الانتظار يفلح، لكن الإصلاح الحقيقي سلوكي: بعد أي فشل، صحّح الخلل باستخدام البيئة التجريبية (staging) حتى ينجح.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

لاحظ certonly: لا يُقبَل --dry-run إلا في الأمرين الفرعيين certonly وrenew، والصيغة المجردة certbot --apache --dry-run ترفض العمل إطلاقًا، وتخبرك بأن --dry-run currently only works with the 'certonly' or 'renew' subcommands. يتحقق التنفيذ التجريبي مقابل البيئة التجريبية (staging)، التي لها حدودها السخية الخاصة ولا تصدر أي شهادة حقيقية، فيمكنك أن تفشل هناك طوال بعد الظهر. لا تُعِد تشغيل الأمر الحقيقي إلا بعد أن ينجح في staging. أما الحدود الأخرى — 50 شهادة لكل نطاق مسجَّل أسبوعيًا، و5 نسخ مكررة من مجموعة الأسماء نفسها أسبوعيًا — فلن تبلغها إلا إذا كان سكربت يعيد الإصدار في حلقة.

بمجرد أن يعمل HTTPS، تذكّر أن الشهادة تؤمّن النقل، لا الخادم نفسه: ما زال المنفذ 22 يتلقى تخمينات كلمات مرور طوال اليوم. اقتران هذا بـFail2ban على Ubuntu 24.04 هو الدقائق الثلاثون الطبيعية التالية.

FAQ

هل أثبّت Certbot بـ snap أم apt لـ Apache على Ubuntu 24.04؟

استخدم apt. توفّر Ubuntu 24.04 الإصدار Certbot 2.9.0، وهو حديث بما يكفي لكل ما في هذا الدليل، ويحصل على تصحيحات أمنية عبر unattended-upgrades، ولا يحتاج snapd. اختر snap فقط إن كنت بحاجة إلى أحدث إصدار فورًا أو إلى إضافة DNS تُوزَّع حصريًا كـ snap — وإن انتقلت، فنفّذ apt remove certbot python3-certbot-apache أولًا حتى لا يتعايش مجدولا تجديد أبدًا.

لماذا يقول Certbot "Unable to find a virtual host listening on port 80"؟

لأن لا vhost مفعّلًا على المنفذ 80 يملك ServerName أو ServerAlias يطابق النطاق الذي مررته مع -d — الـ vhost الافتراضي في Ubuntu يأتي مع ServerName معطّلًا بعلامة تعليق. شغّل sudo apache2ctl -S، واعثر على (أو أنشئ) الـ vhost الذي ينبغي أن يملك الاسم، وأضف ServerName example.com، وأعد تحميل Apache، وأعد تشغيل Certbot.

كيف أصلح "Timeout during connect (likely firewall problem)"؟

لم تستطع Let's Encrypt الوصول إلى المنفذ 80 عند العنوان الذي ينشره DNS لديك. تحقق من جدار الحماية الشبكي على مستوى لوحة مزوّد الخدمة إلى جانب ufw، وتأكد أن dig +short example.com يعيد عنوان هذا الـ VPS، واحذف أو صحّح أي سجل AAAA قديم — فالتحقق يفضّل IPv6 متى وُجد. تأكد من الإصلاح من خارج الخادم بـ curl -I http://example.com، ثم جرّب بـ sudo certbot certonly --apache --dry-run -d example.com قبل الإصدار الحقيقي.

هل يجدّد Certbot الشهادات تلقائيًا على Ubuntu 24.04؟

نعم. تثبّت حزمة apt الملف certbot.timer، وهو مؤقّت systemd يعمل مرتين يوميًا ويجدّد أي شهادة تبعد أقل من 30 يومًا عن انتهاء صلاحيتها، ويعيد تحميل Apache بعد ذلك؛ ويستخدم snap الملف snap.certbot.renew.timer للمهمة نفسها. تحقق بـ systemctl list-timers certbot.timer وجرّب بـ sudo certbot renew --dry-run — ولا تُضِف مهمة cron خاصة بك فوق ذلك.

كيف أحصل على شهادة شاملة (wildcard) مع Certbot وApache؟

تتطلب الشهادات الشاملة تحدي DNS-01: يجب أن يضع Certbot سجل TXT عند _acme-challenge.example.com، وهو ما يعني إضافة من عائلة certbot-dns-* تعتمد على بيانات اعتماد API لمزوّد DNS لديك (البديل --manual يحتاج سجلات TXT مُعدَّلة يدويًا عند كل تجديد). إن كان لديك حفنة فقط من النطاقات الفرعية المعروفة، فشهادة SAN تسردها صراحة أبسط وتُبقي مفاتيح API لـ DNS بعيدة عن الخادم.