نصب Certbot برای Apache روی Ubuntu 24.04

آنچه می‌سازید

یک وب‌سایت Apache روی Ubuntu 24.04 که با استفاده از گواهی رایگان و معتبر Let's Encrypt که توسط Certbot صادر شده، به درخواست‌های HTTPS پاسخ می‌دهد. این گواهی توسط یک systemd timer به‌صورت خودکار تمدید می‌شود و دیگر نیازی به نگرانی درباره آن نخواهید داشت. دستوری که این کار را انجام می‌دهد تنها یک خط است. هر مشکلی که رخ دهد، پیش از اجرای آن خط اتفاق می‌افتد: یک vhost بدون ServerName، بسته بودن پورت 80 در فایروال ارائه‌دهنده، یا DNS که هنوز به سرور قدیمی اشاره می‌کند. بنابراین، این راهنما بیشتر وقت خود را صرف پیش‌نیازها می‌کند و رشته خطای دقیق هر اشتباه را ذکر می‌کند.

دو نکته درباره دامنه این راهنما: اگر وب‌سرور شما nginx است، روند کار مشابه است اما پلاگین و تنظیمات تفاوت دارند؛ در این صورت از نسخه nginx این راهنما استفاده کنید. همچنین اگر سرویسی که قصد ایمن‌سازی آن را دارید فقط داخلی است—مانند یک پنل مدیریت روی آدرس خصوصی یا یک محیط staging که کسی به آن دسترسی ندارد—اصلاً نیازی به مرجع صدور گواهی (CA) ندارید؛ یک گواهی خودامضا (self-signed) پیچیدگی کمتری دارد و به‌صورت آفلاین نیز کار می‌کند.

پیش‌نیازها و سه دلیلی که باعث شکست فرآیند پیش از اجرای Certbot می‌شوند

• Apache در حال حاضر سایت شما را از طریق HTTP ساده سرویس‌دهی می‌کند. پلاگین Apache برای Certbot، یک سایت موجود را ویرایش می‌کند؛ این پلاگین سایت جدید نمی‌سازد. اگر کار را از یک VPS خام شروع کرده‌اید، ابتدا LAMP stack on Ubuntu 24.04 را پیاده‌سازی کنید و سپس بازگردید؛ این راهنما فصل گمشده TLS برای آن است.
• یک دامنه عمومی با رکورد A که به آدرس VPS شما اشاره می‌کند. چالش HTTP-01 در Let’s Encrypt به این معناست که سرورهای اعتبارسنجی آن‌ها از طریق اینترنت به سرور شما متصل می‌شوند: هیچ homelab پشت NAT بدون port forward، هیچ نام .local و هیچ IP خامی پذیرفته نیست. dig +short example.com باید آدرس VPS شما را برگرداند و اگر در یک ساعت گذشته DNS را تغییر داده‌اید، پیش از صدور گواهی منتظر بمانید تا TTL رکورد قدیمی منقضی شود.
• اگر رکورد AAAA وجود دارد، باید صحیح باشد. Let’s Encrypt در صورت انتشار رکورد AAAA، پروتکل IPv6 را ترجیح می‌دهد؛ بنابراین یک رکورد AAAA قدیمی باعث شکست اعتبارسنجی می‌شود، حتی اگر curl از لپ‌تاپ شما (که احتمالاً روی IPv4 است) به‌درستی کار کند. یا یک رکورد AAAA صحیح منتشر کنید یا اصلاً رکوردی قرار ندهید.

پورت‌های 80 و 443 باید هم در ufw و هم در فایروال شبکه ارائه‌دهنده شما باز باشند؛ اکثر پنل‌های میزبانی یک فایروال دوم دارند که سیستم‌عامل آن را نمی‌بیند. چالش HTTP-01 به‌طور خاص از طریق پورت 80 اعتبارسنجی می‌شود؛ شما نمی‌توانید این فرآیند را فقط با پورت 443 اجرا کنید.

sudo ufw allow "Apache Full"
sudo ufw status

با رعایت این موارد، کل کار پانزده دقیقه زمان می‌برد که ده دقیقه آن صرف مطالعه می‌شود.

استفاده از Snap یا apt برای Certbot؟ در نسخه 24.04، استفاده از apt بالاخره مناسب است

پروژه Certbot سال‌ها پیش به دلایل موجهی به توزیع از طریق snap روی آورد: بسته‌های توزیع‌های لینوکسی قدیمی می‌شدند. اوبونتو 20.04 نسخه 0.40 از Certbot را ارائه می‌داد و هرگز آن را به‌روز نکرد؛ تیم توسعه از عیب‌یابی باگ‌های پنج‌ساله خسته شده بود. در نسخه 24.04 این مشکل برطرف شده است؛ مخازن رسمی نسخه 2.9.0 را ارائه می‌دهند که یک نسخه مدرن است و unattended-upgrades آن را به‌روز نگه می‌دارد. پیشنهاد من برای این سیستم‌عامل: از apt استفاده کنید. با این کار از daemon مربوط به snapd بی‌نیاز می‌شوید، افزونه Apache در همان تراکنش نصب می‌شود و زمان‌بند تمدید گواهی‌ها به روش استاندارد دبیان با systemd یکپارچه می‌گردد.

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 مبتنی بر نام (name-based) مناسب بدهید. فایل /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 در اینجا مسیر symlink مربوط به sites-enabled که واقعاً خوانده است را گزارش می‌دهد، نه فایلی که در sites-available ویرایش کرده‌اید. اگر example.com برای پورت 80 لیست نشده باشد، Certbot نیز آن را پیدا نخواهد کرد.

صدور گواهی: certbot --apache

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

در اجرای نخست، سه مورد پرسیده می‌شود: یک آدرس ایمیل (که برای حساب ACME و اطلاعیه‌های فوری مرجع صدور گواهی استفاده می‌شود؛ Let's Encrypt دیگر هشدارهای انقضا ارسال نمی‌کند، بنابراین نظارت بر تمدید گواهی‌ها بر عهده شماست)، موافقت با شرایط Let's Encrypt، و اینکه آیا مایل به اشتراک‌گذاری ایمیل خود با EFF هستید یا خیر. دیگر سوالی درباره تغییر مسیر (redirect) پرسیده نمی‌شود: از نسخه 2.0 به بعد Certbot، نصب‌کننده Apache به‌طور پیش‌فرض ترافیک HTTP را به HTTPS هدایت می‌کند که همان رفتار مطلوب است. اگر واقعاً نیاز دارید که محتوا را از طریق HTTP ساده ارائه دهید، از فلگ --no-redirect استفاده کنید.

پیام موفقیت‌آمیز به شکل زیر است و توصیه می‌شود آن را با دقت بخوانید:

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 برای نرم‌افزارهایی که به این قطعات به‌صورت جداگانه نیاز دارند. این موارد در واقع symlinkهایی به مسیر /etc/letsencrypt/archive/ هستند و این لایهٔ واسط، همان مکانیزم تمدید است: فرآیند تمدید، فایل‌های جدید را در archive/ می‌نویسد و symlinkها را به‌روزرسانی می‌کند. هر نرم‌افزار دیگری را به مسیرهای live/ ارجاع دهید تا تمدیدها را به‌صورت خودکار دریافت کند؛ اگر فایل‌ها را به جای دیگری کپی کنید، عملاً یک قطعی سرویس برای 90 روز آینده ایجاد کرده‌اید.

فایل دیگری که دانستن آن اهمیت دارد /etc/letsencrypt/renewal/example.com.conf است که نحوه صدور این گواهی، authenticator = apache، installer = apache و دامنه‌ها را ثبت می‌کند تا تمدید بتواند فرآیند را بدون دخالت دست تکرار کند، که این شامل reload کردن Apache پس از آن نیز می‌شود.

تمدید از قبل زمان‌بندی شده است، آن را تأیید کنید، نه اینکه دوباره بسازید

گواهی‌های Let’s Encrypt طبق طراحی 90 روز اعتبار دارند و بسته apt از قبل مکانیزم لازم را نصب کرده است: یک systemd timer که Certbot را دو بار در روز در زمان‌های تصادفی اجرا می‌کند و هر گواهی که کمتر از 30 روز تا انقضای آن باقی مانده باشد را تمدید می‌کند. هیچ cron job اضافی اضافه نکنید؛ زمان‌بند دوم جز ایجاد نویز در لاگ‌ها و در معرض قرار گرفتن محدودیت نرخ (rate-limit)، هیچ فایده‌ای ندارد.

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

دستور اول فعال بودن تایمر را نشان می‌دهد، با یک زمان NEXT که در 24 ساعت آینده قرار دارد. زمان‌بندی به صورت دو بار در روز با تأخیر تصادفی است، بنابراین زمان دقیق عمداً غیرقابل پیش‌بینی است (در نصب snap، تایمر به صورت snap.certbot.renew.timer است). اجرای آزمایشی (dry run) یک تمرین کامل تمدید در محیط staging شرکت 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/ بازگرداند؛ این همان تغییر مسیری (redirect) است که 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 را از آن دستور حذف کنید، گواهی جدید به‌طور خودکار آن دامنه را حذف خواهد کرد.

گواهی‌های Wildcard به DNS-01 نیاز دارند و معمولاً نیازی به Wildcard ندارید

چالش HTTP-01 نمی‌تواند *.example.com صادر کند؛ قرار دادن یک فایل روی وب‌سرور، کنترل یک نام میزبان (hostname) را اثبات می‌کند، نه کل یک فضای نام (namespace) را. گواهی‌های Wildcard به چالش DNS-01 نیاز دارند: Certbot یک رکورد TXT در _acme-challenge.example.com تنظیم می‌کند که در عمل به معنای استفاده از یک پلاگین certbot-dns-* با اعتبارنامه‌های API برای ارائه‌دهنده DNS شما، یا ویرایش دستی رکوردهای TXT در هر بار تمدید با --manual است (که بسیار دشوار است و نباید روی آن برنامه‌ریزی کنید). راهنمای کامل، از مکانیسم رکورد TXT تا پلاگینی که تمدید را به‌صورت خودکار انجام می‌دهد، در گواهی‌های wildcard با Certbot از طریق DNS-01 موجود است. توصیه صادقانه: اگر 4 زیردامنه مشخص دارید، یک گواهی SAN که هر 4 مورد را لیست کند، ساده‌تر از یک گواهی Wildcard است و نیازی به نگهداری کلیدهای 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 از خروجی exception چاپ می‌کند. دستور 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 مناسب اضافه کنید، سرویس را reload کرده و دوباره تلاش کنید. یک مورد مشابه این است که درخواست اعتبارسنجی به vhost اشتباهی می‌رسد و پاسخ چالش با خطای Invalid response ... 404 مواجه می‌شود، زیرا سایت دیگری درخواست را دریافت کرده است. تشخیص و ابزار رفع این مشکل نیز همان است: apache2ctl -S.

وقفه (Timeout) در اعتبارسنجی.

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 که هنوز به سرور قبلی اشاره دارد، یا مشکل IPv6 قدیمی (سرورهای آن‌ها IPv6 را امتحان کرده‌اند، اما سرور شما فقط روی IPv4 پاسخ می‌دهد). از خارج از VPS تست کنید: دستور curl -I http://example.com از روی لپ‌تاپ شما، دقیقاً همان چیزی را شبیه‌سازی می‌کند که اعتبارسنج آن‌ها می‌بیند.

رسیدن به محدودیت نرخ (Rate Limit) به دلیل تلاش‌های مکرر.

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 را نمایش می‌دهد. اجرای آزمایشی (dry run) در برابر محیط 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 را reload کنید و دوباره 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 timer که دو بار در روز اجرا می‌شود و هر گواهی که کمتر از 30 روز تا انقضای آن باقی مانده باشد را تمدید کرده و پس از آن Apache را reload می‌کند؛ نسخه snap از snap.certbot.renew.timer برای همین کار استفاده می‌کند. با systemctl list-timers certbot.timer وضعیت را بررسی کنید و با sudo certbot renew --dry-run تست کنید؛ نیازی به افزودن cron job شخصی نیست.

چگونه می‌توانم با Certbot و Apache یک گواهی wildcard دریافت کنم؟

گواهی‌های wildcard به چالش DNS-01 نیاز دارند: Certbot باید یک رکورد TXT در _acme-challenge.example.com قرار دهد، که این امر مستلزم یک پلاگین certbot-dns-* با اعتبارنامه‌های API برای ارائه‌دهنده DNS شماست (جایگزین --manual نیازمند ویرایش دستی رکوردهای TXT در هر بار تمدید است). اگر فقط تعداد کمی زیردامنه مشخص دارید، یک گواهی SAN که آن‌ها را به‌صراحت لیست می‌کند ساده‌تر است و کلیدهای API مربوط به DNS را از سرور دور نگه می‌دارد.