نصب گواهی Let’s Encrypt فقط اجرای یک فرمان نیست. دامنه باید به سرور درست برسد، challenge از مسیر لازم قابل اعتبارسنجی باشد، کلید خصوصی محافظت شود و تمدید خودکار واقعاً آزمون شود. گواهی‌ای که امروز کار می‌کند اما timer، DNS یا reload آن خراب است، چند هفته بعد می‌تواند سایت production را از دسترس خارج کند.
پاسخ سریع: ابتدا دامنه، A/AAAA، وب‌سرور و portهای 80/443 را بررسی کنید؛ سپس روش ACME مناسب را انتخاب کنید. برای دامنه معمولی HTTP-01 اغلب ساده است، اما wildcard به DNS-01 نیاز دارد. client را از منبع معتبر نصب، صدور را انجام، chain و hostname را آزمون و در پایان renewal dry-run و reload سرویس را تأیید کنید.
Let’s Encrypt و ACME چه می‌کنند؟
Let’s Encrypt یک مرجع صدور گواهی است و ACME پروتکلی برای اثبات کنترل دامنه و خودکارسازی صدور و تمدید است. رایگان بودن گواهی به معنی بی‌نیازی از عملیات نیست؛ DNS، client، credential، timer، storage کلید و مانیتورینگ همچنان مسئولیت مدیر سرور است.
پیش‌نیازهای قبل از صدور
- دامنه و تمام نام‌های درخواستی دقیقاً مشخص باشند
- رکوردهای A و AAAA به مسیر فعال اشاره کنند
- ساعت سرور و NTP صحیح باشد
- port challenge از اینترنت قابل دسترسی باشد
- وب‌سرور و virtual host درست شناسایی شده باشد
- backup از config و rollback آماده باشد
- مالک تمدید و alert انقضا تعیین شود
وجود رکورد AAAA خراب ممکن است باعث شود بخشی از اعتبارسنجی یا کاربران از مسیر IPv6 ناموفق شوند. حذف عجولانه رکورد راه‌حل دائمی نیست؛ مسیر موردنیاز را درست کنید یا DNS را آگاهانه تغییر دهید.
انتخاب روش Challenge
HTTP-01
CA یک فایل موقت را از مسیر مشخص روی HTTP دامنه می‌خواند. port 80 و route challenge باید از اینترنت به همان client برسد. redirect به HTTPS معمولاً قابل مدیریت است، اما proxy، CDN یا rewrite نباید مسیر challenge را به login یا backend اشتباه بفرستد.
DNS-01
با رکورد TXT کنترل DNS اثبات می‌شود و برای wildcard لازم است. خودکارسازی امن به API DNS و credential محدود نیاز دارد. token با دسترسی کامل حساب و نگهداری در repository ریسک بالایی دارد؛ scope، permission، rotation و محل secret را طراحی کنید.
TLS-ALPN-01
اعتبارسنجی روی TLS و port 443 انجام می‌شود و پشتیبانی آن به client و معماری edge وابسته است. اگر load balancer یا CDN termination را انجام می‌دهد، challenge باید به محل درست برسد. روش را فقط به‌دلیل بسته بودن port دیگر انتخاب نکنید؛ مسیر end-to-end را بررسی کنید.
Wildcard چه تفاوتی دارد؟
گواهی *.example.com زیردامنه‌های یک سطح را پوشش می‌دهد، اما معمولاً نام apex مانند example.com باید جدا در درخواست باشد. wildcard با DNS-01 صادر می‌شود. اگر فقط دو hostname دارید، گواهی نام‌دار ممکن است automation ساده‌تر و credential DNS کمتری بخواهد.
Client ACME را از منبع معتبر بگیرید
Certbot یکی از clientهای شناخته‌شده است، اما روش نصب به توزیع و چرخه package بستگی دارد. script ناشناخته را با root اجرا نکنید. نسخه، plugin وب‌سرور یا DNS، مسیر config و روش update را ثبت کنید. دو نصب موازی از package managerهای متفاوت می‌تواند timer و path را مبهم کند.
Automatic Installer یا Certonly؟
plugin وب‌سرور می‌تواند config را خودکار تغییر دهد؛ حالت cert-only فقط گواهی را می‌گیرد و اتصال آن به Nginx را به مدیر می‌سپارد. در config ساده، automation راحت است. در reverse proxy پیچیده یا template مدیریت‌شده، تغییر دستی نسخه‌دار کنترل بیشتری می‌دهد. قبل و بعد diff config را بررسی کنید.
Nginx را پیش از صدور آماده کنید
server_name، document root و route HTTP باید صحیح باشد. اگر catch-all همه domainها را redirect یا reject می‌کند، challenge را جدا آزمایش کنید. config را پیش از reload با sudo nginx -t اعتبارسنجی کنید. راهنمای کانفیگ Nginx برای وردپرس ساختار virtual host را توضیح می‌دهد.
Firewall و شبکه
برای HTTP-01، درخواست عمومی باید به port 80 برسد؛ برای روش TLS مسیر 443 لازم است. cloud firewall، host firewall، NAT و CDN را هم‌زمان ببینید. باز کردن موقت یک port برای کل اینترنت بدون owner و expiration ریسک دارد. راهنمای Firewall لینوکس flow و آزمون بیرونی را پوشش می‌دهد.
صدور در محیط Production
دامنه‌ها و روش challenge را صریح انتخاب کنید و ایمیل عملیاتی معتبر برای اعلان‌ها داشته باشید. rate limit صدور وجود دارد؛ آزمون و خطای تکراری با دامنه production انجام ندهید و در صورت پشتیبانی client از محیط staging CA برای آزمایش استفاده کنید. خروجی فرمان را برای انتشار عمومی پاک‌سازی کنید.
Full Chain و Private Key
وب‌سرور معمولاً به certificate chain کامل و private key متناظر نیاز دارد. ارائه ناقص chain ممکن است روی بعضی clientها خطا دهد. private key نباید در Git، backup بدون رمز یا دسترس user برنامه باشد. permission باید فقط به فرایند و مدیر لازم اجازه دهد؛ chmod 777 ممنوع است.
Canonical HTTPS Redirect
پس از سالم بودن HTTPS، HTTP را به hostname canonical هدایت کنید. redirect باید query/path را درست نگه دارد و loop نسازد. پشت CDN یا reverse proxy، scheme واقعی را فقط از proxy مورد اعتماد بپذیرید. اعتماد به header هر client می‌تواند spoofing یا loop ایجاد کند.
HSTS را دیرتر فعال کنید
HSTS مرورگر را مجبور می‌کند فقط HTTPS استفاده کند و خطای گواهی را نمی‌توان با HTTP دور زد. ابتدا صدور، renewal و تمام زیردامنه‌های مشمول را پایدار کنید. افزودن subdomain یا preload تصمیم پراثر و دیرقابل‌بازگشت است؛ آن را صرفاً از یک snippet عمومی کپی نکنید.
آزمون فنی پس از نصب
- hostname و SANهای گواهی
- بازه اعتبار و ساعت سیستم
- chain کامل و کلید متناظر
- صفحه اصلی، asset و endpoint dynamic
- redirect HTTP و alias دامنه
- اتصال از چند client و شبکه
- reload موفق و log بدون خطا
نمایش قفل مرورگر به‌تنهایی کافی نیست. دامنه اشتباه ممکن است به گواهی default برسد و فقط برخی SNIها خراب باشند. مسیر IPv4 و IPv6 را جدا آزمایش کنید.
تمدید خودکار را همان روز تست کنید
sudo certbot certificates
sudo certbot renew --dry-runاین فرمان‌ها برای نصب Certbot استانداردند، اما اگر client دیگری یا container دارید از دستور همان ابزار استفاده کنید. dry-run باید challenge، renewal config و hookها را بسنجد. موفق بودن timer بدون اجرای dry-run ثابت نمی‌کند تمدید end-to-end کار می‌کند.
Reload پس از تمدید
گواهی روی disk ممکن است تازه شود اما process وب‌سرور هنوز نسخه قبلی را در حافظه ارائه دهد. deploy hook یا مکانیزم رسمی باید پس از renewal موفق، syntax را بررسی و reload کنترل‌شده انجام دهد. restart کامل بدون نیاز می‌تواند connectionها را قطع کند. شکست reload باید alert مستقل داشته باشد.
Certificate در Docker یا Load Balancer
مشخص کنید TLS کجا terminate می‌شود. اگر certificate روی host صادر و داخل container mount می‌شود، permission، symlink و reload container اهمیت دارد. کپی دستی فایل به image با هر renewal stale می‌شود. در load balancer مدیریت‌شده شاید صدور و تمدید خارج سرور انجام شود؛ دو source of truth نسازید.
مانیتورینگ انقضا
فقط job renewal را مانیتور نکنید؛ گواهی‌ای را که واقعاً از اینترنت ارائه می‌شود بررسی کنید. alert باید چند مرحله پیش از انقضا فرصت اقدام بدهد و hostname، issuer و expiry را گزارش کند. کانال هشدار نباید به همان سایتی وابسته باشد که ممکن است به‌دلیل TLS قطع شود.
اشتباه‌های رایج
- نادیده گرفتن رکورد AAAA
- درخواست wildcard با HTTP-01
- ذخیره token DNS در Git
- تغییر خودکار Nginx بدون بررسی diff
- ارائه certificate به‌جای full chain مناسب
- فعال‌کردن HSTS پیش از renewal پایدار
- فرض موفقیت از روی timer بدون dry-run
- تمدید فایل بدون reload سرویس
چه زمانی کمک تخصصی لازم است؟
اگر CDN، Docker، wildcard یا چند reverse proxy دارید، challenge و reload ممکن است در لایه اشتباه اجرا شود. نصب و کانفیگ سرور لینوکس می‌تواند صدور، نگهداری secret، renewal، monitoring و rollback TLS را متناسب با معماری واقعی پیاده کند.
پرسش‌های متداول
آیا SSL رایگان امنیت کمتری دارد؟
نوع اعتبارسنجی و مدت گواهی با محصولات دیگر فرق دارد، اما امنیت اتصال به کلید، config TLS، patch و نگهداری درست وابسته است؛ رایگان بودن به‌تنهایی ضعف رمزنگاری نیست.
برای wildcard چه روشی لازم است؟
DNS-01؛ credential DNS باید حداقل دسترسی لازم و automation امن داشته باشد.
آیا port 80 باید همیشه باز باشد؟
به روش renewal وابسته است. برای HTTP-01 مسیر باید هنگام اعتبارسنجی قابل دسترسی باشد؛ طراحی موقت/دائمی باید مستند و آزموده شود.
چرا گواهی جدید روی سایت دیده نمی‌شود؟
ممکن است سرویس reload نشده، TLS در لایه دیگری terminate شود یا virtual host اشتباه پاسخ دهد.