نصب 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 روی Ubuntu 24.04 را پیاده‌سازی کنید و سپس بازگردید؛ این راهنما در واقع فصل گمشده TLS برای آن است.
• یک دامنه عمومی با رکورد A که به آدرس VPS شما اشاره می‌کند. چالش HTTP-01 در Let’s Encrypt به این معناست که سرورهای اعتبارسنجی آن‌ها از طریق اینترنت به سرور شما متصل می‌شوند: بنابراین هیچ homelab پشت NAT بدون port forward کار نخواهد کرد و نام‌های .local نیز پشتیبانی نمی‌شوند. HTTP-01 می‌تواند یک IP خام را اعتبارسنجی کند، اما Let’s Encrypt گواهی‌های IP را فقط در پروفایل انتخابی shortlived (با طول عمر 160 ساعت) صادر می‌کند و Certbot نسخه 2.9.0 در apt، نه قابلیت درخواست پروفایل‌های ACME را دارد و نه آدرس‌های IP را می‌پذیرد؛ بنابراین این راهنما به یک نام دامنه نیاز دارد. dig +short example.com باید آدرس VPS شما را بازگرداند و اگر در یک ساعت گذشته DNS را تغییر داده‌اید، پیش از صدور گواهی منتظر بمانید تا TTL رکورد قدیمی منقضی شود.
• اگر رکورد AAAA وجود دارد، باید صحیح باشد. Let’s Encrypt همیشه در صورت انتشار رکورد AAAA، ابتدا IPv6 را امتحان می‌کند. اگر آن اتصال با timeout مواجه شود، دوباره از طریق IPv4 تلاش می‌کند، اما هیچ خطای دیگری شانس دوباره نخواهد داشت: وجود یک 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 از Certbot را ارائه می‌دهند که مربوط به فوریه 2024 و از سری مدرن 2.x است و unattended-upgrades هرگونه به‌روزرسانی امنیتی که اوبونتو برای آن منتشر کند را نصب می‌کند. اگرچه نسخه اصلی پروژه اکنون به سری 5.x رسیده است، اما هیچ‌کدام از مراحل این راهنما به آن نیاز ندارند. توصیه من برای این سیستم‌عامل: از apt استفاده کنید. با این کار نیازی به سرویس 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 که در PATH توسط shell شما پیدا می‌شود، همان نسخه‌ای نباشد که مالک گواهی‌های شماست. خط 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

اولین اجرا سه مورد را می‌پرسد: یک آدرس ایمیل (Let's Encrypt دیگر آن را در حساب ACME شما ذخیره نمی‌کند و هشدارهای انقضا را ارسال نمی‌کند، بنابراین نظارت بر تمدید گواهی بر عهده شماست)، موافقت با شرایط Let's Encrypt، و اینکه آیا مایل به اشتراک‌گذاری ایمیل خود با EFF هستید یا خیر. دیگر سوالی درباره تغییر مسیر (redirect) پرسیده نمی‌شود: از زمان Certbot 1.0، نصب‌کننده Apache به‌طور پیش‌فرض HTTP را به HTTPS تغییر مسیر می‌دهد (خود این سوال در نسخه 1.4 حذف شد)، که این همان چیزی است که شما می‌خواهید. اگر واقعاً برای ارائه محتوا به 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 2027-01-09.

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) قرار گرفتن، فایده‌ای ندارد. Let’s Encrypt اعلام کرده است که از تاریخ 10 فوریه 2027، گواهی‌های جدید به‌طور پیش‌فرض دارای اعتبار 64 روزه خواهند بود. بازه 30 روزه همچنان با این گواهی‌ها کار می‌کند و تمدید به‌جای روز 60، در حدود روز 34 انجام می‌شود، بنابراین نیازی به تغییر در این سرور نیست.

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 بازگرداند. سومین مورد صادرکننده (issuer) را چاپ می‌کند، یک خط O = Let's Encrypt با یک CN کوتاه مانند YE1 یا YE2 (کلیدهای ECDSA) یا YR1 یا YR2 (کلیدهای RSA) و notAfter که تقریباً 90 روز اعتبار دارد. گواهی‌ای که پیش از بازنشستگی واسط‌های قدیمی Let’s Encrypt صادر شده باشد، ممکن است تا زمان تمدید بعدی همچنان CNهایی مانند R12 یا E7 را نشان دهد؛ این یک خطا نیست. در مرورگر، شما آیکون قفل را دریافت می‌کنید و کلیک روی آن، همان صادرکننده را نشان می‌دهد. اگر curl به‌درستی کار می‌کند اما مرورگر هشدار می‌دهد، تقریباً مطمئن باشید که با یک صفحه کش‌شده یا نام میزبان (hostname) اشتباه مواجه هستید، نه یک مشکل در گواهی.

چندین سایت: یک گواهی 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 که هنوز به سرور قبلی اشاره دارد. معمولاً یک رکورد AAAA قدیمی به تنهایی باعث این مشکل نمی‌شود، زیرا وقتی تلاش از طریق IPv6 با timeout مواجه می‌شود، Let’s Encrypt دوباره از طریق IPv4 تلاش می‌کند؛ مشکلات AAAA معمولاً به صورت خطای Connection refused یا Invalid response از سمت سرور اشتباه ظاهر می‌شوند. از خارج از VPS تست کنید: دستور curl -I http://example.com از روی لپ‌تاپ شما، دقیقاً همان چیزی را شبیه‌سازی می‌کند که اعتبارسنج Let’s Encrypt می‌بیند.

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

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

سرویس Let’s Encrypt اجازه 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 را نمایش می‌دهد. اجرای آزمایشی (dry run) در محیط staging انجام می‌شود که محدودیت‌های بسیار بازتری دارد و گواهی واقعی صادر نمی‌کند، بنابراین می‌توانید تمام بعدازظهر را در آنجا با خطا مواجه شوید. تنها زمانی دستور اصلی را دوباره اجرا کنید که تست در محیط staging با موفقیت انجام شود. سایر محدودیت‌ها، یعنی 50 گواهی برای هر دامنه ثبت‌شده در هفته و 5 گواهی تکراری برای یک مجموعه نام در هفته، تنها در صورتی رخ می‌دهند که یک اسکریپت در حال صدور مجدد گواهی در یک حلقه بی‌نهایت باشد.

هنگامی که HTTPS فعال شد، به یاد داشته باشید که گواهی فقط امنیت انتقال را تأمین می‌کند، نه امنیت سرور: پورت 22 همچنان در معرض حدس زدن رمز عبور است. ترکیب این مورد با Fail2ban روی اوبونتو 24.04، گام منطقی بعدی برای سی دقیقه آینده شماست.

FAQ

آیا باید Certbot را با snap نصب کنم یا apt برای Apache روی Ubuntu 24.04؟

از apt استفاده کنید. Ubuntu 24.04 نسخه Certbot 2.9.0 را ارائه می‌دهد که برای تمام موارد این راهنما به‌اندازه کافی جدید است، به‌روزرسانی‌های امنیتی منتشرشده توسط Ubuntu را از طریق 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 را امتحان می‌کند و تنها پس از timeout به IPv4 بازمی‌گردد. رفع مشکل را از خارج سرور با 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 را از سرور دور نگه می‌دارد.