تثبيت Certbot لـ Apache على Ubuntu 24.04

ما الذي ستبنيه

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

ملاحظتان حول النطاق. إذا كان خادم الويب لديك هو nginx، فالتدفق العام مماثل، لكن المكوّن الإضافي وملفات الإعداد يختلفان؛ استخدم نسخة nginx من هذا الدليل بدلاً من ذلك. وإذا كان الشيء الذي تريد تأمينه داخلياً فقط، مثل لوحة إدارة على عنوان خاص أو خادم تجريبي لا يزوره أحد غيرك، فلست بحاجة إلى سلطة شهادات على الإطلاق؛ فـالشهادة الموقعة ذاتياً تتطلب مكونات أقل وتعمل دون اتصال.

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

• يجب أن يكون Apache يقدّم موقعك عبر HTTP العادي. يحرّر مكوّن Apache الإضافي في Certbot موقعاً موجوداً؛ ولا ينشئ موقعاً جديداً. إذا كنت تبدأ من VPS فارغ، فأنشئ حزمة LAMP على Ubuntu 24.04 أولاً ثم عد إلى هنا؛ فهذا الدليل هو فصل TLS المفقود فيها.
• يجب أن يكون لديك نطاق عام يتضمن سجل A يشير إلى عنوان VPS. تعني آلية التحقق 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

بعد استيفاء هذه المتطلبات، تستغرق العملية كاملةً 15 دقيقة، ويذهب 10 منها إلى القراءة.

Snap أم apt لـ Certbot؟ في 24.04 أصبح apt مناسباً أخيراً

انتقل Certbot إلى التوزيع عبر snap منذ سنوات لسبب وجيه: فقدت حزم التوزيعات حداثتها. أطلقت Ubuntu 20.04 الإصدار 0.40 من Certbot ولم تحدّثه بعد ذلك، وسئم المشروع من تصحيح أخطاء عمرها خمس سنوات. في 24.04 زال هذا السبب؛ إذ يحتوي الأرشيف على Certbot 2.9.0، وهو إصدار حديث، كما يحافظ unattended-upgrades على تحديثاته. توصيتي لهذا النظام هي استخدام apt. بذلك تتجنب البرنامج الخفي snapd، ويُثبَّت مكوّن 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 من خلال العثور على virtual host الذي يستمع على المنفذ 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 أربعة أمور خلف تلك الرسالة: فعّل وحدة Apache ‏ssl إذا لم تكن مفعّلة من قبل، وكتب example.com-le-ssl.conf، وهي نسخة من vhost الخاص بك على *:443، مع SSLEngine on ومسارات الشهادة، ثم فعّلها، وأضاف كتلة RewriteRule إلى vhost الأصلي على المنفذ 80 لإعادة توجيه كل شيء إلى HTTPS باستخدام الحالة 301. يُعدَّل ملف vhost الأصلي ولا يُستبدل، وتوجد نسخة SSL المطابقة بجانبه، حيث يمكنك قراءة كل سطر أضافه Certbot.

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

توجد جميع الملفات ضمن /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 فوق ذلك؛ فالجدول الثاني لا يضيف سوى ضوضاء في السجلات ويزيد خطر الوصول إلى حدود المعدل.

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

يعرض الأمر الأول المؤقت على أنه نشط، مع وقت NEXT يقع في الساعات 24 القادمة. ويعمل الجدول مرتين يومياً مع تأخير عشوائي، لذلك يكون الوقت الدقيق غير متوقع عمداً. في تثبيت snap، يكون المؤقت هو snap.certbot.renew.timer بدلاً من ذلك. يجري الاختبار الجاف تجربة كاملة للتجديد باستخدام بيئة Let's Encrypt المرحلية، مع تحدٍّ حقيقي، لكن من دون إصدار شهادة ومن دون استهلاك من حدود المعدل. تنتهي النتيجة الصحيحة بما يلي:

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 من ذلك الأمر، فستسقطه الشهادة الجديدة بصمت.

تحتاج Wildcards إلى DNS-01، وغالباً لا تحتاج إلى wildcard

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

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

يرفض 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 يطبع تمثيل الاستثناء. شغّل 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.

هذا هو فشل missing-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 شهادات مكررة لمجموعة الأسماء نفسها في الأسبوع، فلن تبلغها إلا إذا كان هناك script يعيد الإصدار في حلقة متكررة.

بعد تشغيل 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"؟

لأنه لا توجد virtual host مفعّلة على المنفذ 80 تحتوي على ServerName أو ServerAlias مطابق للنطاق الذي مررته إلى -d. يتضمن Ubuntu ملف virtual host الافتراضي مع تعليق ServerName. شغّل sudo apache2ctl -S، وابحث عن virtual host التي يجب أن تملك هذا الاسم أو أنشئها، وأضف 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؟

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