نصب certbot برای آپاچی در اوبونتو 24.04

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

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

دو نکته درباره دامنه. اگر وب سرور شما nginx است، روند کار به همان شکل است اما افزونه و پیکربندی‌ها متفاوت هستند، به جای آن از نسخه nginx این راهنما استفاده کنید. و اگر چیزی که ایمن می‌کنید فقط داخلی است، یک پنل مدیریت روی یک آدرس خصوصی، یک جعبه مرحله‌بندی که هیچ‌کس دیگری از آن بازدید نمی‌کند، اصلاً به یک مرجع صدور گواهی نیاز ندارید؛ یک گواهی خودامضا پیچیدگی کمتری دارد و به صورت آفلاین کار می‌کند.

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

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

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

sudo ufw allow "Apache Full"
sudo ufw status

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

اسنپ یا apt برای Certbot؟ روی 24.04، apt بالاخره گزینهٔ مناسبی است

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

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

نتیجهٔ صحیح: certbot 2.9.0. بستهٔ python3-certbot-apache افزونه‌ای است که پیکربندی‌های آپاچی شما را می‌خواند و ویرایش می‌کند، بدون آن، certbot --apache با خطای The requested apache plugin does not appear to be installed شکست می‌خورد.

اسنپ همچنان در دو مورد انتخاب درستی است: شما جدیدترین Certbot را در همان روز انتشار می‌خواهید، یا به یک افزونهٔ DNS نیاز دارید که فقط به‌صورت اسنپ توزیع می‌شود (چندین افزونه از ارائه‌دهندگان 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 که پوستهٔ شما در PATH پیدا می‌کند ممکن است همانی نباشد که مالک گواهی‌های شماست. خط apt remove بالا تزئین اختیاری نیست.

هاست مجازی‌ای که Certbot ویرایش می‌کند باید از قبل وجود داشته باشد؛ ServerName کل ماجرا است

certbot --apache به این صورت کار می‌کند: هاست مجازی پورت 80 را پیدا می‌کند که ServerName یا ServerAlias آن با هر دامنه‌ای که به -d می‌دهید مطابقت دارد، کنترل دامنه را از طریق آن اثبات می‌کند، سپس یک نسخهٔ SSL از آن هاست مجازی می‌نویسد. اگر ServerName مطابقی وجود نداشته باشد، تطابقی در کار نیست، و 000-default.conf پیش‌فرض اوبونتو با ServerName کامنت‌شده عرضه می‌شود. همین یک خط کامنت‌شده رایج‌ترین دلیلی است که فرمان بزرگ این راهنما با شکست مواجه می‌شود.

بنابراین پیش از آنکه به Certbot دست بزنید، یک هاست مجازی مبتنی بر نام مناسب برای سایت بسازید. /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>

آن را فعال کنید و تأیید کنید که آپاچی هم آن را تجزیه می‌کند و هم نام را به آن مسیردهی می‌کند:

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 سراسری است، نه هاست مجازی شما، و در اینجا بی‌ضرر است و با 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 زیر آن باشد؛ آپاچی لینک نمادین 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 تغییر مسیر می‌دهد، که همان چیزی است که می‌خواهید. اگر واقعاً نیاز دارید 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 آپاچی را فعال کرد، فایل example.com-le-ssl.conf را نوشت، که یک کپی از میزبان مجازی شما روی *:443 است با SSLEngine on و مسیرهای گواهی، آن را فعال کرد، و یک بلوک RewriteRule به فایل اصلی میزبان مجازی پورت 80 اضافه کرد که همه چیز را با کد 301 به HTTPS تغییر مسیر می‌دهد. فایل اصلی میزبان مجازی شما ویرایش شده، جایگزین نشده، و همتای 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 روی آن اضافه نکنید؛ یک زمان‌بند دوم چیزی جز نویز لاگ و قرار گرفتن در معرض محدودیت نرخ اضافه نمی‌کند.

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

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

هر دو روش کار می‌کنند؛ تمدید آن‌ها نیز به یک شکل انجام می‌شود. برای سایت‌های نامرتبط روی یک سرور، دستور issue را یک بار برای هر سایت اجرا کنید. هر سایت دایرکتوری مخصوص خود را در مسیر 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 صادر کند، زیرا قرار دادن یک فایل روی وب‌سرور کنترل یک نام میزبان را اثبات می‌کند، نه یک فضای نام کامل را. وایلدکاردها به چالش 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 را دوباره اجرا کنید.

هیچ میزبان مجازی با دامنه مطابقت ندارد.

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

این همان خطای مربوط به گم شدن ServerName است که قبلاً توضیح داده شد و در زمان صدور گواهی رخ می‌دهد. Certbot تمام میزبان‌های مجازی فعال روی پورت 80 را برای یافتن یک ServerName/ServerAlias که با -d شما مطابقت داشته باشد جستجو کرد و چیزی پیدا نکرد. sudo apache2ctl -S نشان می‌دهد که Apache واقعاً درخواست‌ها را به کجا مسیردهی می‌کند؛ خط ServerName را به میزبان مجازی صحیح اضافه کنید، بارگذاری مجدد کنید و دوباره تلاش کنید. یک مشکل مشابه زمانی است که اعتبارسنجی به میزبان مجازی اشتباهی می‌رسد، پاسخ چالش به صورت 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 از زمان بازنگری محدودیت نرخ در سال 2025، 5 اعتبارسنجی ناموفق به ازای هر نام میزبان، هر حساب کاربری و هر ساعت مجاز می‌داند. این یک سطل قابل پر شدن مجدد است که تقریباً هر 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 را می‌گوید. اجرای آزمایشی در برابر محیط مرحله‌بندی اعتبارسنجی می‌کند، که محدودیت‌های سخاوتمندانه خود را دارد و هیچ گواهی واقعی صادر نمی‌کند، بنابراین می‌توانید تمام بعدازظهر در آنجا شکست بخورید. فقط زمانی دستور واقعی را دوباره اجرا کنید که مرحله‌بندی با موفقیت گذرانده شود. محدودیت‌های دیگر، 50 گواهی به ازای هر دامنه ثبت‌شده در هفته و 5 نمونه تکراری از همان مجموعه نام در هفته، فقط زمانی به آن‌ها برخورد می‌کنید که یک اسکریپت در یک حلقه در حال صدور مجدد باشد.

هنگامی که HTTPS راه‌اندازی شد، به یاد داشته باشید که گواهی، انتقال داده را ایمن می‌کند، نه خود سرور را: پورت 22 همچنان تمام روز در معرض حدس زدن رمز عبور است. ترکیب این کار با Fail2ban روی اوبونتو 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"؟

زیرا هیچ میزبان مجازی فعال روی پورت 80 دارای ServerName یا ServerAlias منطبق با دامنه‌ای که با -d ارسال کرده‌اید نیست، میزبان مجازی پیش‌فرض Ubuntu با ServerName که کامنت شده است ارائه می‌شود. sudo apache2ctl -S را اجرا کنید، میزبان مجازی‌ای که باید مالک آن نام باشد را پیدا (یا ایجاد) کنید، 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 job خودتان را روی آن اضافه نکنید.

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

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