تمدید SSL در قطعی اینترنت؛ جلوگیری از انقضای گواهی سایت

گواهی رایگان Let’s Encrypt ۹۰ روز اعتبار دارد و توصیه رسمی، تمدید در روز ۶۰ است؛ این فاصله ۳۰ روزه کل فرصت شما برای تمدید SSL در قطعی اینترنت است. اگر اختلال از این بافر طولانی‌تر شود، مرورگر پیش از نمایش صفحه هشدار امنیتی می‌دهد. جدول زیر بر اساس زمان باقی‌مانده تا انقضا چیده شده است.

زمان باقی‌مانده تا انقضا	وضعیت	کاری که همین حالا باید کرد
کمتر از ۷۲ ساعت	اضطراری	چالش را به DNS-01 ببرید؛ اگر مسیر خروجی قطع است، روی ماشین دیگر صادر کنید
۳ تا ۱۴ روز	پرخطر	یک dry-run بگیرید، رکورد TXT را با dig بسنجید، بعد تمدید واقعی
۱۴ تا ۳۰ روز	در پنجره تمدید	تایمر تمدید و هوک ری‌لود سرویس را تنظیم کنید
بیش از ۳۰ روز	امن	هشدار روزانه انقضا بسازید و مسیر جایگزین را تمرین کنید

ترتیب این راهنما همان ترتیب واقعی یک تمدید است: عمر گواهی و پنجره امن، انتخاب چالش اعتبارسنجی، زمان‌بندی و هوک‌ها، و آخر مانیتورینگ و نقشه جایگزین.

عمر گواهی و پنجره‌ای که برای تمدید SSL در قطعی اینترنت دارید

گواهی پیش‌فرض Let’s Encrypt ۹۰ روز اعتبار دارد و در پرسش‌های متداول رسمی این سرویس، تمدید هر ۶۰ روز توصیه شده است. پس از روز ۶۰ تا روز ۹۰، یک بافر ۳۰ روزه در اختیار دارید. طول همین بافر تعیین می‌کند که یک اختلال چندروزه را رد می‌کنید یا به تاریخ انقضا می‌رسید.

همان سند می‌گوید این طول عمر به هیچ شکلی قابل تغییر نیست؛ تنها متغیر در دست شما، زودتر تمدید کردن است.

آستانه تمدید در Certbot و معنای پیام «گواهی هنوز منقضی نشده»

وقتی Certbot می‌گوید گواهی تازه است، به آستانه داخلی خودش نگاه کرده است. طبق مستندات Certbot، از نسخه 4.0.0 گواهی وقتی آماده تمدید است که کمتر از یک‌سوم عمرش مانده باشد؛ برای گواهی ۹۰ روزه یعنی روز ۶۰. پیش از آن نسخه، این عدد ثابت و ۳۰ روز بود. برای گواهی ۱۰ روز و کمتر، آستانه نیمه عمر است.

گواهی کوتاه‌عمر شش روزه و دلیل نامناسب بودنش در شبکه ناپایدار

مستندات Let’s Encrypt می‌گوید مشترکان می‌توانند گواهی کوتاه‌عمر شش روزه را انتخاب کنند و توصیه تمدید آن هر سه روز است. روی سروری که هر چند هفته اختلال چندروزه دارد، بافر سه روزه حاشیه امنی باقی نمی‌گذارد.

چالش HTTP-01، DNS-01 و TLS-ALPN-01؛ کدام به اینترنت بین‌الملل وابسته است

هر سه چالش ACME یک چیز را اثبات می‌کنند: کنترل شما بر دامنه. تفاوتشان در مسیر شبکه است. در HTTP-01 و TLS-ALPN-01، سرور Let’s Encrypt باید از بیرون به پورت 80 یا 443 سرور شما وصل شود. در DNS-01 فقط یک رکورد TXT از سیستم DNS خوانده می‌شود.

در مستندات انواع چالش Let’s Encrypt آمده که DNS-01 می‌تواند دامنه‌ای را اعتبارسنجی کند که وب‌سرورش روی اینترنت عمومی در دسترس نیست. برای تمدید SSL در قطعی اینترنت همین ویژگی تعیین‌کننده است، چون اتصال ورودی به IP سرور از مسیر اعتبارسنجی حذف می‌شود.

پورت 80 و مسیری که Let’s Encrypt از بیرون طی می‌کند

چالش HTTP-01 فقط روی پورت 80 انجام می‌شود. Let’s Encrypt فایل کوچکی را از نشانی http://example.com/.well-known/acme-challenge/ می‌خواند و ریدایرکت به پورت 80 یا 443 را دنبال می‌کند. اگر پورت 80 از بیرون بسته باشد، این چالش شکست می‌خورد. گواهی وایلدکارد هم با آن صادر نمی‌شود.

رکورد TXT و شرط‌های واقعی چالش DNS-01

در DNS-01 کلاینت شما یک رکورد TXT روی نام _acme-challenge.example.com می‌سازد و Let’s Encrypt همان را می‌خواند. این چالش تنها راه گرفتن وایلدکارد است. مستندات رسمی دو هشدار می‌دهد: خودکارسازی آن فقط با API سرویس DNS معنا دارد، و نگه داشتن کلید کامل API روی وب‌سرور اثر هک شدن آن را بزرگ می‌کند. اعتبارسنجی آدرس IP هم با آن ممکن نیست.

• شرط اول: نیم‌سرورهای دامنه باید از بیرون پاسخ بدهند، چون پرس‌وجوی TXT از سمت Let’s Encrypt انجام می‌شود.
• شرط دوم: توکن API را فقط به ویرایش رکورد همان دامنه محدود کنید و رکوردهای TXT قدیمی را پاک کنید.

پیش از هر اجرای واقعی، دیده شدن رکورد را از یک ریزالور بیرونی بسنجید؛ همین یک قدم بیشترین سهم را در نسوزاندن سهمیه خطا دارد.

# رکورد TXT را از دو ریزالور عمومی ببینید
dig +short TXT _acme-challenge.example.com @1.1.1.1
dig +short TXT _acme-challenge.example.com @8.8.8.8

دسترسی خروجی سرور به سرویس ACME، شرطی که هیچ چالشی حذفش نمی‌کند

انتخاب چالش، مسیر ورودی را عوض می‌کند، نه مسیر خروجی. کلاینت شما در همه حالت‌ها باید به دایرکتوری ACME وصل شود؛ پیش‌فرض Certbot نشانی https://acme-v02.api.letsencrypt.org/directory است و با سوئیچ --server عوض می‌شود. اگر این مسیر قطع باشد، باید سراغ صدور روی ماشین دیگر بروید.

چالش	مسیر اعتبارسنجی	وایلدکارد	مناسب وقتی
چالش HTTP-01	اتصال ورودی به پورت 80	ندارد	پورت 80 از بیرون باز و پایدار است
چالش DNS-01	خواندن رکورد TXT از سیستم DNS	دارد	اتصال ورودی به سرور قابل اتکا نیست
چالش TLS-ALPN-01	اتصال ورودی TLS روی پورت 443	ندارد	پورت 80 در اختیار شما نیست؛ منبع رسمی آن را برای بیشتر کاربران مناسب نمی‌داند

زمان‌بندی تمدید زودهنگام و هوک‌ها در Certbot

تمدید خودکار با دستور certbot renew انجام می‌شود و فقط گواهی‌هایی را تازه می‌کند که به آستانه تمدید رسیده باشند. طبق مستندات Certbot، بیشتر نصب‌ها یک تسک زمان‌بندی‌شده دارند که همین دستور را دوره‌ای اجرا می‌کند. هوک‌ها فقط وقتی اجرا می‌شوند که گواهی موعد تمدید داشته باشد.

مهم‌ترین کار برای تمدید SSL در قطعی اینترنت، اجرای مرتب همین تایمر و انتخاب چالشی است که به مسیر ورودی وابستگی ندارد.

تایمر و کران؛ بررسی اینکه تمدید واقعاً اجرا می‌شود

سوئیچ --all را جا نگذارید: فهرست پیش‌فرض تایمرها، تایمر غیرفعال را نشان نمی‌دهد و شما نتیجه می‌گیرید که تایمری وجود ندارد. کران کاربر را هم جداگانه بسنجید. اجرای آزمایشی با --dry-run انجام می‌شود که طبق مستندات، گواهی را روی دیسک ذخیره نمی‌کند و سرور staging را صدا می‌زند.

systemctl list-timers --all | grep -i certbot
crontab -l | grep -i certbot
grep -ri certbot /etc/cron.d /etc/crontab /lib/systemd/system

# تست مسیر صدور، بدون ذخیره گواهی روی دیسک
certbot renew --dry-run

پلاگین DNS، هوک دستی و ترتیب درست اجرا

پلاگین‌های DNS در نصب پیش‌فرض Certbot نیستند و جداگانه نصب می‌شوند، مثلاً بسته python3-certbot-dns-cloudflare. اگر سرویس DNS شما پلاگین آماده دارد همان را انتخاب کنید، چون کلیدها را خودش نگه می‌دارد و تمدید خودکار می‌ماند. یک تله مهم در راهنمای استفاده از Certbot ذکر شده است: گواهی ساخته‌شده با --manual تمدید خودکار ندارد، مگر اینکه هوک ساخت و پاک کردن رکورد را تعیین کنید.

• سوئیچ --manual-auth-hook و --manual-cleanup-hook: ساخت و پاک کردن رکورد TXT.
• سوئیچ --deploy-hook: فقط بعد از تمدید موفق اجرا می‌شود و جای درست تست و ری‌لود nginx است.
• سوئیچ --cert-name: وقتی چند گواهی روی سرور دارید و یکی را هدف می‌گیرید.

# ۱) اول dry-run، بدون مصرف سهمیه گواهی واقعی
certbot certonly --dry-run \
  --preferred-challenges dns --manual \
  --manual-auth-hook /usr/local/bin/acme-txt-add.sh \
  --manual-cleanup-hook /usr/local/bin/acme-txt-del.sh \
  -d example.com -d '*.example.com'

# ۲) اجرای واقعی: غیرتعاملی، با ایمیل حساب و ری‌لود بعد از موفقیت
certbot certonly -n --agree-tos -m admin@example.com \
  --preferred-challenges dns --manual \
  --manual-auth-hook /usr/local/bin/acme-txt-add.sh \
  --manual-cleanup-hook /usr/local/bin/acme-txt-del.sh \
  --deploy-hook 'nginx -t && nginx -s reload' \
  -d example.com -d '*.example.com'

# با پلاگین آماده، هوک دستی لازم نیست
certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cf.ini -d example.com

هوک باید پیش از خروج، منتظر انتشار رکورد بماند. اگر این انتظار نباشد، چالش شکست می‌خورد و سهمیه خطا می‌سوزد. در هوک، نام دامنه و رشته اعتبارسنجی را Certbot در متغیرهای CERTBOT_IDENTIFIER و CERTBOT_VALIDATION می‌گذارد، و در deploy hook مسیر گواهی تازه در RENEWED_LINEAGE است.

# /usr/local/bin/acme-txt-add.sh
#!/bin/bash
set -eu
REC="_acme-challenge.$CERTBOT_IDENTIFIER"
# این خط را با دستور سرویس DNS خودتان عوض کنید
dns-cli add-txt "$REC" "$CERTBOT_VALIDATION"
until dig +short TXT "$REC" @1.1.1.1 | grep -q "$CERTBOT_VALIDATION"; do sleep 10; done

# /usr/local/bin/acme-txt-del.sh
#!/bin/bash
set -eu
dns-cli del-txt "_acme-challenge.$CERTBOT_IDENTIFIER" "$CERTBOT_VALIDATION"

کلاینت acme.sh هم همین کار را با فلگ dns انجام می‌دهد و متغیرهای API را در فایل پیکربندی حساب ذخیره می‌کند تا در تمدیدهای بعدی خودش استفاده کند. اگر تازه نصب را شروع کرده‌اید، آموزش نصب گواهی رایگان Let’s Encrypt مسیر پایه را نشان می‌دهد.

محدودیت نرخ صدور و هزینه واقعی تلاش‌های ناموفق

شب اختلال، وسوسه می‌شوید دستور تمدید را پشت سر هم اجرا کنید. سند محدودیت‌های نرخ Let’s Encrypt نشان می‌دهد چرا این کار گران است. سهمیه خطای اعتبارسنجی برای هر نام دامنه و هر حساب، پنج خطا در ساعت است و هر دوازده دقیقه یک واحد از آن برمی‌گردد.

محدودیت	سقف	بازگشت ظرفیت
گواهی تازه هر دامنه ثبت‌شده (New Certificates per Registered Domain)	۵۰ در ۷ روز	هر ۲۰۲ دقیقه یکی
مجموعه نام‌های یکسان (New Certificates per Exact Set of Identifiers)	۵ در ۷ روز	هر ۳۴ ساعت یکی
خطای اعتبارسنجی (Authorization Failures per Identifier)	۵ در ساعت	هر ۱۲ دقیقه یکی

اگر همین حالا پنج خطا زده‌اید، برای یک تلاش تازه حدود دوازده دقیقه و برای کل سهمیه حدود یک ساعت صبر کنید. در همین فاصله اشکال را با --dry-run روی staging پیدا کنید که سهمیه واقعی مصرف نمی‌کند.

تمدید با همان مجموعه نام‌های قبلی از سهمیه سفارش جدید و سهمیه هفتگی هر دامنه معاف است. معافیت کامل مخصوص تمدید مبتنی بر ARI است؛ یعنی ACME Renewal Information در RFC 9773، که با آن کلاینت از CA می‌پرسد چه زمانی تمدید کند. شرطش این است که سفارش تازه حداقل یکی از نام‌های گواهی قبلی را داشته باشد و آن گواهی پیش‌تر با ARI جایگزین نشده باشد. سهمیه خطا و سهمیه گواهی تکراری همیشه اعمال می‌شود.

مانیتورینگ انقضا و نقشه جایگزین وقتی تمدید SSL در قطعی اینترنت ممکن نیست

اول تاریخ انقضا را بسنجید، بعد تصمیم بگیرید. با openssl می‌توانید تاریخ انقضای گواهی را از دیسک و از سمت شبکه بخوانید و همان را به یک هشدار روزانه وصل کنید. زیر ۱۴ روز، مسیر جایگزین را فعال کنید و منتظر برگشتن شبکه نمانید.

خواندن تاریخ انقضا و ساختن هشدار روزانه

دستور دوم مهم‌تر از اولی است، چون نشان می‌دهد کاربر واقعاً چه گواهی‌ای می‌گیرد. برای هشدار هم مقایسه دستی تاریخ لازم نیست: سوئیچ -checkend در openssl همین کار را با ثانیه انجام می‌دهد.

# گواهی روی دیسک
openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/cert.pem

# گواهی‌ای که کاربر واقعاً می‌گیرد
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -subject

# هشدار روزانه: کمتر از ۲۱ روز (1814400 ثانیه)
if ! openssl x509 -checkend 1814400 -noout \
     -in /etc/letsencrypt/live/example.com/cert.pem; then
  echo "cert expires in under 21 days" | mail -s "SSL alert" admin@example.com
fi

این اسکریپت را در کران روزانه بگذارید و مقصد هشدار را جایی بگذارید که در اختلال هم به دست شما می‌رسد.

صدور گواهی روی ماشینی که به CA دسترسی دارد و نصب آن روی سرور

اگر خود سرور نمی‌تواند به سرویس ACME وصل شود، صدور را جابه‌جا کنید. چون DNS-01 به IP سرور کاری ندارد، هر ماشینی که به دایرکتوری ACME و به رکورد DNS دسترسی دارد، گواهی را می‌گیرد.

1. روی ماشین دوم، گواهی را با چالش DNS-01 و همان نام دامنه صادر کنید.
2. فایل‌های fullchain.pem و privkey.pem را امن منتقل کنید؛ مالکیت root:root و دسترسی کلید 600.
3. مسیر را در دایرکتیوهای ssl_certificate و ssl_certificate_key بنویسید.
4. با nginx -t تست کنید و تنها در صورت سالم بودن ری‌لود کنید.
5. انقضای گواهی تازه را با s_client تأیید و تمدید بعدی را در تقویم ثبت کنید.

یک میان‌بر هم دارید: گواهی وایلدکارد. با پوشش ده زیردامنه در یک گواهی، تعداد تمدیدهای موفقی که در پنجره اختلال لازم دارید از ده به یک می‌رسد.

گواهی تجاری و سقف اعتباری که دیگر یک‌ساله نیست

خرید گواهی یک‌ساله امروز ممکن نیست. طبق الزامات پایه فروم CA/Browser، سقف ۳۹۸ روز در ۱۵ مارس ۲۰۲۶ منقضی شد و سقف فعلی ۲۰۰ روز است. این عدد در ۱۵ مارس ۲۰۲۷ به ۱۰۰ روز و در ۱۵ مارس ۲۰۲۹ به ۴۷ روز می‌رسد. بازه استفاده مجدد از داده اعتبارسنجی دامنه هم همین پله‌ها را دارد.

تاریخ اعمال	سقف اعتبار گواهی	سقف استفاده مجدد از داده اعتبارسنجی دامنه
پیش از ۱۵ مارس ۲۰۲۶	۳۹۸ روز	۳۹۸ روز
از ۱۵ مارس ۲۰۲۶ (وضعیت فعلی)	۲۰۰ روز	۲۰۰ روز
از ۱۵ مارس ۲۰۲۷	۱۰۰ روز	۱۰۰ روز
از ۱۵ مارس ۲۰۲۹	۴۷ روز	۱۰ روز

پس گواهی تجاری هم حداکثر چند ماه پنجره می‌دهد و این پنجره کوچک‌تر می‌شود. هر چه سقف کوتاه‌تر شود، تمدید خودکار و یک مسیر DNS-01 سالم اهمیت بیشتری پیدا می‌کند.

سوال‌هایی که کاربران وب‌داده و جست‌وجوکننده‌ها درباره تمدید گواهی و اختلال شبکه بیشتر می‌پرسند:

جمع‌بندی؛ پنجره ۳۰ روزه را هدر ندهید همه ماجرای تمدید SSL در قطعی اینترنت در یک محاسبه ساده خلاصه می‌شود. گواهی ۹۰ روز اعتبار دارد، توصیه رسمی تمدید در روز ۶۰ است و شما ۳۰ روز حاشیه دارید. کاری که این حاشیه را قابل استفاده می‌کند، بردن اعتبارسنجی به DNS-01 است؛ آن وقت لازم نیست Let’s Encrypt از بیرون به پورت 80 سرور شما برسد.
سه کار را همین امروز انجام دهید. اول، تایمر تمدید را با --all ببینید و یک --dry-run بگیرید. دوم، یک هشدار روزانه با -checkend بسازید که زیر ۲۱ روز خبر می‌دهد. سوم، مشخص کنید برای روز قطعی دسترسی خروجی، گواهی را روی کدام ماشین صادر می‌کنید. پیش از هر اجرای واقعی رکورد TXT را با dig بسنجید، چون سهمیه پنج خطا در ساعت زود تمام می‌شود. و روی گواهی بلندمدت حساب نکنید: سقف اعتبار از مارس ۲۰۲۶ برابر ۲۰۰ روز است و تا مارس ۲۰۲۹ به ۴۷ روز می‌رسد، پس خودکارسازی درست برای هر سایتی اجباری می‌شود.

اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.

• پرسش‌های متداول Let’s Encrypt (طول عمر و زمان تمدید): letsencrypt.org/docs/faq
• انواع چالش Let’s Encrypt (HTTP-01، DNS-01، TLS-ALPN-01): letsencrypt.org/docs/challenge-types
• محدودیت‌های نرخ Let’s Encrypt (سهمیه و معافیت ARI): letsencrypt.org/docs/rate-limits
• راهنمای Certbot (آستانه تمدید، هوک‌ها، پلاگین DNS): eff-certbot.readthedocs.io
• الزامات پایه فروم CA/Browser (سقف اعتبار گواهی): cabforum.org