مانیتورینگ SSL و انقضای گواهی؛ آموزش OpenSSL و Let’s Encrypt

سایت در تمام تست‌های HTTP سالم است؛ اما صبح روز بعد، مرورگر کاربران هشدار گواهی نامعتبر نشان می‌دهد. CPU و RAM تغییری نکرده‌اند و وب‌سرور هم روشن است. مشکل می‌تواند انقضای گواهی، زنجیره ناقص اعتماد، نام دامنه اشتباه یا تمدید انجام‌شده‌ای باشد که هنوز در Nginx بارگذاری نشده است. مانیتورینگ SSL و تاریخ انقضای گواهی امنیتی باید همه این حالت‌ها را بسنجد، نه اینکه فقط تعداد روز باقی‌مانده یک فایل محلی را نمایش دهد.

این راهنما برای مدیران Linux، صاحبان وب‌سایت و تیم‌های DevOps نوشته شده است: چطور گواهی عمومی را با OpenSSL بررسی کنیم، چرا اعتبار زنجیره و SNI مهم است، چگونه تمدید خودکار Let's Encrypt را پایش کنیم و چه هشدارهایی قبل از بروز اختلال لازم‌اند. مطالب کلی سلامت HTTP در راهنمای قطعی سایت و مسیر شبکه آمده است؛ این مقاله به‌طور خاص بر چرخه عمر TLS و جلوگیری از خطای گواهی تمرکز دارد.

مانیتورینگ گواهی SSL دقیقاً باید چه چیزهایی را بررسی کند؟

نام رایج «SSL» در این بحث معمولاً به گواهی X.509 مورد استفاده در اتصال TLS اشاره دارد؛ SSL قدیمی پروتکل پیشنهادی امنیتی نیست. هنگام ورود به https://example.com، کلاینت باید علاوه بر اعتبار زمانی گواهی، نام میزبان، مسیر اعتماد تا Root معتبر و سازگاری کلید و سیاست امنیتی را بررسی کند. بنابراین داشتن فایل .pem با تاریخ انقضای آینده، به‌تنهایی نشان نمی‌دهد مرورگر اتصال را معتبر می‌داند.

کنترل	نمونه مشکل	راه بررسی
اعتبار زمانی	notAfter گذشته یا notBefore در آینده است	خواندن تاریخ گواهی ارائه‌شده از سرور
نام دامنه / SAN	گواهی برای دامنه دیگری صادر شده است	بررسی Hostname با SNI و Verify
زنجیره اعتماد	Intermediate ارسال نشده است	اعتبارسنجی کامل با Trust Store مناسب
نصب نسخه تازه	فایل تمدید شده ولی Web Server گواهی قبلی را می‌دهد	مقایسه گواهی روی اتصال بیرونی با فایل
دامنه‌ها و Edgeها	CDN، Load Balancer یا IPv6 گواهی دیگری دارد	بررسی هر مسیر تحویل و هر نام مقصد
عملکرد تمدید	Timer اجرا نمی‌شود یا Challenge شکست می‌خورد	بررسی Log و آزمون تمدید کنترل‌شده

گام اول: گواهی واقعی روی دامنه را با OpenSSL بخوانید

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

# Read-only TLS verification. Keep the hostname and SNI identical.
openssl s_client -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error -brief < /dev/null

گزینه -servername نام دامنه را برای SNI می‌فرستد تا سرور در صورت داشتن چند گواهی، نسخه مربوط به Host را ارائه کند. -verify_return_error برخلاف رفتار صرفاً گزارش‌دهی برخی حالت‌های s_client، خطای اعتبارسنجی را به شکست اتصال تبدیل می‌کند. در گزارش، نتیجه Verify و کد خروج را بررسی کنید؛ موفق‌شدن یک دستور که فقط گواهی را نمایش می‌دهد، معادل معتبر بودن زنجیره نیست. مرجع: مستند رسمی openssl s_client.

چگونه notBefore و notAfter گواهی بیرونی را ببینیم؟

set -o pipefail
openssl s_client -connect example.com:443 \
  -servername example.com -verify_return_error \
  < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

این Pipeline تاریخ آغاز و پایان اعتبار و صادرکننده گواهی ارائه‌شده را نشان می‌دهد. گزینه pipefail در Bash کمک می‌کند خطای دستور ابتدایی در وضعیت نهایی پنهان نماند؛ خروجی خطای TLS را باید در صورت شکست جدا بررسی کرد. فیلد issuer فقط نام صادرکننده را چاپ می‌کند و اثبات نمی‌کند زنجیره مورد اعتماد کاربر کامل است.

گام دوم: چطور انقضای گواهی را قبل از موعد تشخیص دهیم؟

برای بررسی یک گواهی ذخیره‌شده روی دیسک، OpenSSL امکان آزمون «در N ثانیه آینده منقضی می‌شود؟» را فراهم می‌کند. برای مثال ۷ روز برابر ۶۰۴۸۰۰ ثانیه است:

# Exit code 0: certificate remains valid beyond the requested interval.
# Exit code 1: certificate expires within that interval (or already expired).
openssl x509 -in /path/to/cert.pem -noout -checkend 604800

echo "certificate_check_exit=$?"

این فرمان فایل محلی را بررسی می‌کند؛ اگر Nginx هنوز نسخه قدیمی را به کاربران ارائه دهد، نتیجه به‌تنهایی کافی نیست. برای بررسی روزهای باقی‌مانده می‌توان notAfter را پارس کرد، اما Parser باید منطقه زمانی، شکست فرمان و Clock سرور را درست مدیریت کند. در سیستم اعلان بهتر است تاریخ گواهی روی اتصال واقعی نیز جدا پایش شود.

آستانه ۳۰ روز برای همه گواهی‌ها مناسب است؟

نه لزوماً. Let's Encrypt برنامه کاهش تدریجی طول عمر گواهی‌های پیش‌فرض از ۹۰ روز به ۶۴ و سپس ۴۵ روز را طی سال‌های ۲۰۲۶ تا ۲۰۲۸ اعلام کرده است. بنابراین طراحی یک هشدار صرفاً براساس «۳۰ روز مانده» بدون شناخت چرخه تمدید و نسخه Certbot می‌تواند دیرهنگام یا پرنویز باشد. بهتر است تاریخ پایان، نسبت زمان باقیمانده، آخرین تمدید موفق و سلامت آزمون تمدید را کنار هم ببینید. منبع: اطلاعیه رسمی Let's Encrypt درباره گواهی کوتاه‌عمر.

گام سوم: چرا زنجیره اعتماد و Intermediate مهم‌اند؟

گواهی یک سایت معمولاً به‌وسیله یک CA واسط امضا می‌شود و کلاینت باید مسیر اعتماد تا Root مورد قبول خودش را بسازد. اگر وب‌سرور Intermediate لازم را ارائه نکند، ممکن است برخی مرورگرها با Cache قبلی وصل شوند اما کلاینت تازه یا ابزار API شکست بخورد. openssl s_client -showcerts گواهی‌های ارسالی سرور را نشان می‌دهد، ولی به‌تنهایی زنجیره را Verify نمی‌کند.

openssl s_client -connect example.com:443 \
  -servername example.com -showcerts \
  -verify_hostname example.com -verify_return_error \
  < /dev/null

اگر خطا مشاهده شد، نام دامنه، فایل Full Chain، سیاست Trust Store و تاریخ سیستم را بررسی کنید. به جای غیر‌فعال‌کردن Verify یا استفاده دائمی از curl -k، علت واقعی را اصلاح کنید. گواهی نامعتبر در یک سیستم پرداخت یا Webhook می‌تواند ارتباط را کاملاً قطع کند.

گام چهارم: تمدید خودکار Let's Encrypt با Certbot چگونه پایش شود؟

در بسیاری از نصب‌ها، Certbot وظیفه renew را از قبل با systemd Timer یا Cron زمان‌بندی می‌کند. اضافه‌کردن بدون بررسی یک Cron تکراری می‌تواند عملیات اضافی بسازد. قبل از هر تغییر، ببینید چه چیزی روی میزبان فعال است:

systemctl list-timers --all | grep -i certbot
systemctl status certbot.timer --no-pager
sudo certbot certificates
# Also review system cron locations if the timer does not exist.

وجود Timer فعال تضمین نمی‌کند تمدید واقعاً موفق می‌شود. برای یک آزمون برنامه‌ریزی‌شده، Certbot از renew --dry-run استفاده می‌کند؛ ولی این آزمون ممکن است به ACME Staging متصل شود، موقتاً پیکربندی سرویس را تغییر دهد یا Hook اجرا کند، پس **کاملاً Read-only نیست** و روی محیط Production باید در پنجره نگهداری و با مجوز انجام شود:

# Controlled maintenance test, not a read-only probe:
sudo certbot renew --dry-run

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

گام پنجم: پس از تمدید، گواهی نصب‌شده را دوباره بررسی کنید

موفقیت ACME یا جایگزین‌شدن فایل Certificate به معنی بارگذاری آن در همه سرویس‌ها نیست. در بعضی معماری‌ها، وب‌سرور باید پیکربندی را به‌صورت کنترل‌شده Reload کند و در پشت Load Balancer یا CDN نیز محل ارائه گواهی ممکن است مستقل باشد. پس از هر تمدید، باید از بیرون با SNI، نام دامنه و زنجیره کامل آزمون بگیرید؛ در صورت داشتن چند مقصد یا IPv4/IPv6، همان مسیرهایی را که کاربران تجربه می‌کنند کنترل کنید.

در سامانه دارای چند Container یا Node، بررسی یک فایل محلی نمی‌تواند ناسازگاری نودها را نشان دهد. برای پیگیری، شناسه گواهی ارائه‌شده و تاریخ انقضای بیرونی را با داده صادرشده مقایسه کنید. اجرای Reload خودکار بدون بررسی پیکربندی ممکن است سرویس را مختل کند؛ در Production پیش از تغییر، اعتبار پیکربندی و روش بازگشت باید مشخص باشد.

چگونه هشدار پیشگیرانه SSL را طراحی کنیم؟

رویداد	شدت پیشنهادی	اقدام
تاریخ انقضا نزدیک است ولی تمدید سالم بوده	Warning قابل تنظیم	بررسی زمان برنامه‌ریزی و نسخه نصب‌شده
آزمون تمدید شکست خورده	Critical یا Warning بر اساس فاصله باقی‌مانده	بررسی ACME Challenge، DNS و مجوز فایل
گواهی بیرونی منقضی یا نامعتبر است	Critical فوری	تأیید از مسیر دوم و آغاز Runbook اصلاح
نام دامنه با SAN سازگار نیست	Critical برای همان Host	بررسی SNI، دامنه و Virtual Host
فقط یک Edge گواهی قدیمی دارد	Critical منطقه‌ای	بررسی CDN، Load Balancer و Node

یک آستانه نمونه برای شروع می‌تواند هشدارهای ۲۱، ۷ و ۳ روز مانده باشد؛ این‌ها **اعداد پیشنهادی، نه استاندارد همگانی** هستند. در گواهی کوتاه‌عمر بهتر است عدم موفقیت تمدید، آخرین زمان اجرا و نسبت عمر باقی‌مانده نیز معیار باشند. برای گواهی‌های حساس، هشدار باید به مسئول مشخص با مسیر جایگزین برسد.

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

فرض کنید در فایل /etc/letsencrypt/live/example.com/fullchain.pem تاریخ انقضا تازه ثبت شده، اما دامنه از بیرون هشدار قدیمی دارد. ابتدا با s_client نسخه ارائه‌شده در TLS را بخوانید. اگر تاریخ بیرونی هنوز قدیمی است، ممکن است وب‌سرور Reload نشده باشد یا Proxy دیگری گواهی را ارائه دهد. اگر تاریخ بیرونی درست است ولی Verify شکست می‌خورد، نام Host و زنجیره Intermediate را بررسی کنید؛ مشکل الزاماً تاریخ نیست.

1. نتیجه TLS از بیرون با نام دامنه دقیق و SNI صحیح را ثبت کنید.
2. تاریخ و Subject گواهی روی سرویس و فایل محلی را جدا مقایسه کنید.
3. لاگ تمدید Certbot و وضعیت Timer یا Cron را بخوانید.
4. Virtual Host و مسیر فایل گواهی را بدون تغییر ناگهانی بررسی کنید.
5. فقط پس از تأیید تنظیمات، Reload یا اصلاح سرویس را در روند استقرار امن انجام دهید.
6. از چند مسیر مجاز، تاریخ و Verify را دوباره تأیید و Incident را ثبت کنید.

گواهی‌های چنددامنه، Wildcard و CDN چه پیچیدگی‌هایی دارند؟

گواهی چنددامنه باید SAN مناسب برای نام‌های مورد استفاده داشته باشد. Wildcard نیز همه ساختارهای زیردامنه را پوشش نمی‌دهد؛ مثلاً یک سطح با چند سطح عمیق‌تر یکسان نیست. اگر سایت پشت CDN قرار دارد، مرورگر ممکن است گواهی Edge را ببیند، در حالی که بین CDN و Origin گواهی دیگری استفاده می‌شود. برای سلامت واقعی، هر دو مسیر باید مطابق معماری و سطح دسترسی بررسی شوند.

وجود HTTPS روی صفحه اصلی به معنی سلامت گواهی Endpointهای api.، webhook. یا پورت دیگر نیست. فهرست همه Hostهای حیاتی را در مانیتورینگ نگه دارید و هنگام اضافه‌شدن سرویس تازه، مالک گواهی و سیاست تمدید آن را مشخص کنید.

Avaztek Monitoring برای بررسی SSL چه کاربردی دارد؟

Avaztek Monitoring طبق مستندات فعلی محصول، بخش بررسی SSL/TLS و تاریخ انقضای گواهی و همچنین Network Check و اعلان دارد. برای تیمی که چند دامنه و سرور را اداره می‌کند، پایش تاریخ انقضا در کنار وضعیت سرویس کمک می‌کند پیش از قطعی، نزدیک‌شدن به موعد را مشاهده کند. بااین‌حال، پوشش دقیق زنجیره اعتماد، همه مسیرهای CDN و نحوه تنظیم اعلان را باید در قابلیت‌های فعال محصول بررسی کرد؛ صرف وجود بخش SSL معادل آزمون همه مشتری‌ها نیست.

برای بررسی امکانات موجود، به صفحه پلن‌های مانیتورینگ آوازتک بروید و برای شروع از ثبت‌نام رسمی سامانه استفاده کنید. بعد از اتصال، نخست تاریخ بیرونی یک گواهی را با OpenSSL مقایسه کنید تا از تفسیر یکسان داده‌ها مطمئن شوید.

پرسش‌های متداول مانیتورینگ گواهی SSL

چطور تاریخ انقضای SSL سایت را از ترمینال ببینیم؟

از openssl s_client با -servername برای دریافت گواهی بیرونی و از openssl x509 -noout -dates برای مشاهده تاریخ آن استفاده کنید. نتیجه Verify زنجیره را نیز جدا بررسی کنید.

آیا داشتن گواهی منقضی‌نشده برای امن‌بودن TLS کافی است؟

خیر. نام میزبان، زنجیره مورد اعتماد، تنظیمات TLS و گواهی‌ای که واقعاً به کلاینت ارائه می‌شود هم اهمیت دارند.

آیا certbot renew --dry-run هیچ تغییری در سرور نمی‌دهد؟

خیر. این آزمون معمولاً از ACME Staging استفاده می‌کند، اما بسته به پلاگین و Hook می‌تواند اثر موقت روی پیکربندی یا سرویس بگذارد؛ فقط با مجوز و در زمان کنترل‌شده اجرا شود.

چرا پس از تمدید Let’s Encrypt مرورگر همچنان خطای گواهی می‌دهد؟

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

آستانه هشدار SSL را روی چند روز بگذاریم؟

بر اساس عمر واقعی گواهی، سیاست تمدید، اهمیت سرویس و آخرین آزمون موفق تنظیم کنید. کوتاه‌شدن طول عمر گواهی‌ها باعث می‌شود یک عدد ثابت همیشه مناسب نباشد.

آیا Avaztek Monitoring تمدید گواهی را خودکار تضمین می‌کند؟

سامانه قابلیت پایش SSL و انقضا را معرفی می‌کند؛ تمدید موفق به تنظیمات ACME، دسترسی DNS/HTTP و نحوه نصب گواهی وابسته است و با مانیتورینگ به‌تنهایی تضمین نمی‌شود.

جمع‌بندی: انقضا فقط یکی از دلایل خرابی HTTPS است

برای مانیتورینگ SSL، گواهی بیرونی را با SNI و Verify معتبر کنترل کنید، زمان تمدید Certbot را زیر نظر بگیرید و بعد از هر تمدید مطمئن شوید نسخه تازه واقعاً در تمام مسیرهای مهم ارائه می‌شود. برای پایش منظم چند دامنه و سرویس، Avaztek Monitoring گزینه‌ای برای بررسی است؛ خطای زنجیره و پیکربندی همچنان باید با ابزارهای تخصصی و آزمون واقعی تحلیل شوند.