رفع خطای انقضای SSL با بررسی تاریخ سیستم و گواهی‌ای شروع می‌شود که واقعاً به بازدیدکننده ارائه شده است. اگر ساعت دستگاه درست است، تاریخ اعتبار، نام‌های تحت پوشش و محل نصب گواهی را بررسی کنید. تمدید موفق در کنترل‌پنل یا Certbot کافی نیست؛ وب‌سرور یا CDN باید گواهی جدید را ارائه کند و مسیر تمدید بعدی هم سالم باشد.
این راهنما برای مدیر سایت و مدیر سروری است که پیام‌هایی مانند ERR_CERT_DATE_INVALID یا هشدار پایان اعتبار گواهی را می‌بیند. هدف، برگرداندن HTTPS معتبر و جلوگیری از تکرار مشکل است. اگر فقط بازدیدکننده هستید، ساعت و به‌روزرسانی دستگاه را بررسی کنید و خطا را به مالک سایت اطلاع دهید؛ واردکردن رمز و اطلاعات پرداخت روی ارتباطی با هشدار هویت، روش عیب‌یابی نیست.
ابتدا نوع خطا را درست تشخیص دهید
هر هشدار امنیتی به معنی منقضی‌شدن گواهی نیست. نام دامنه ممکن است در گواهی نباشد، زنجیره اعتماد ناقص باشد یا نرم‌افزار دستگاه گواهی را نشناسد. تاریخ نادرست سیستم نیز می‌تواند یک گواهی معتبر را خارج از بازه اعتبار نشان دهد. متن کامل خطا، نشانی دقیق شامل www و زمان مشاهده را ثبت کنید تا بررسی روی حدس بنا نشود.
| نشانه | چه چیزی را بررسی کنیم؟ | اقدام هدفمند |
|---|---|---|
| خطای تاریخ فقط روی یک دستگاه | ساعت، منطقه زمانی و به‌روزرسانی‌ها | اصلاح ساعت دستگاه و آزمون مجدد |
| تاریخ پایان گواهی گذشته است | فرایند تمدید و گواهی ارائه‌شده | رفع علت شکست و تمدید در همان سامانه |
| گواهی برای نام دیگری صادر شده | SAN و تنظیم میزبان مجازی | نصب گواهی شامل نام درست |
| تمدید موفق، مرورگر هنوز گواهی قدیمی دارد | مسیر فایل، reload و لایه CDN | فعال‌کردن گواهی در لایه درست |
| دامنه و www رفتار متفاوت دارند | پوشش نام‌ها و مسیر هر دو اتصال | اصلاح پوشش و تنظیمات هر دو نام |
۱. گواهی ارائه‌شده در مرورگر را ببینید
از بخش اطلاعات اتصال مرورگر، جزئیات گواهی را باز کنید. نام صادرکننده، بازه اعتبار و نام‌های دامنه را یادداشت کنید. رابط مرورگرها متفاوت است؛ لازم نیست برای مشاهده مشخصات، هشدار امنیتی را دور بزنید و صفحه را باز کنید. اگر جزئیات در دسترس نیست، از مدیر فنی بخواهید گواهی را با ابزار مناسب بررسی کند.
همان نام را از یک دستگاه به‌روز و شبکه مستقل نیز بسنجید. اگر سایت پشت CDN است، مرورگر معمولاً گواهی لبه CDN را می‌بیند؛ گواهی بین CDN و سرور مبدأ موضوع جداگانه‌ای است. در معماری دارای چند سرور، فقط یکی از مسیرها ممکن است گواهی قدیمی داشته باشد. بنابراین نتیجه یک اتصال موفق به معنی یکسان‌بودن همه نودها نیست.
۲. محل مدیریت گواهی را پیدا کنید
در هاست اشتراکی، معمولاً گواهی از کنترل‌پنل میزبان مدیریت می‌شود. در VPS ممکن است Certbot، ابزار دیگری برای ACME یا گواهی خریداری‌شده داشته باشید. قبل از اجرا، مشخص کنید کدام ابزار مسئول تمدید است. نصب هم‌زمان چند ابزار روی یک دامنه می‌تواند مسیر فایل‌ها و زمان‌بندی‌ها را مبهم کند و رفع خطا را دشوارتر سازد.
اگر کنترل‌پنل دارید، وضعیت SSL همان دامنه و گزارش آخرین تمدید خودکار را بررسی کنید. پیام موفقیت یک دامنه دیگر یا نسخه بدون www برای نتیجه‌گیری کافی نیست. اگر دسترسی مدیریتی ندارید، نام دامنه، زمان هشدار و مشخصات گواهی دیده‌شده را به میزبان بفرستید و درخواست کنید گزارش صدور و نصب همان نام بررسی شود.
۳. در سرور دارای Certbot، وضعیت را پیش از تغییر بخوانید
فرمان‌های زیر برای سروری هستند که از قبل Certbot روی آن نصب و پیکربندی شده است. آن‌ها را روی هاست اشتراکی یا سیستمی با ابزار متفاوت کپی نکنید. فرمان نخست موجودی گواهی‌ها را نشان می‌دهد. نام certificate، دامنه‌های داخل آن، تاریخ انقضا و مسیر فایل را با تنظیم وب‌سرور تطبیق دهید.
sudo certbot certificates
sudo certbot renew --dry-runآزمون dry-run برای سنجیدن فرایند تمدید است و گواهی فعال سایت را مانند تمدید عادی جایگزین نمی‌کند. اگر شکست خورد، متن دقیق خطا و نام challenge را ثبت کنید. تکرار بی‌وقفه صدور واقعی به‌جای تشخیص علت، روش مناسبی نیست. در نصب‌های بسته‌بندی‌شده، گزارش و زمان‌بندی ممکن است با سرویس یا timer همان بسته مدیریت شود؛ روش نصب را هم در گزارش نگه دارید.
۴. شکست اعتبارسنجی HTTP یا DNS را برطرف کنید
در HTTP-01، سرویس صادرکننده باید فایل challenge را از مسیر مشخص روی HTTP دریافت کند. اگر DNS به سرور قبلی اشاره کند، مسیر به برنامه دیگری منتقل شود یا قواعد دسترسی آن را مسدود کنند، اعتبارسنجی شکست می‌خورد. اجازه موردنیاز را به همان مسیر و معماری محدود کنید؛ خاموش‌کردن کامل محافظت سایت برای رفع یک خطای نامشخص لازم نیست.
در DNS-01، رکورد TXT مربوط به challenge باید در DNS authoritative قابل مشاهده باشد. ممکن است کاربر رکورد را در پنل قدیمی بسازد یا توکن API مجوز لازم برای زون درست نداشته باشد. نتیجه resolver عمومی و authoritative را مقایسه کنید. اطلاعات ورود DNS و کلید خصوصی را در تیکت عمومی قرار ندهید و برای خودکارسازی از دسترسی محدود به نیاز همان زون استفاده کنید.
برای گواهی wildcard، نوع اعتبارسنجی و پوشش نام‌ها را از مستندات صادرکننده بررسی کنید. ستاره یک جایگزین عمومی برای هر نام و هر سطح زیردامنه نیست. اگر example.com و www.example.com را ارائه می‌کنید، پوشش واقعی هر دو را در SAN ببینید؛ ظاهر نام فایل گواهی کافی نیست.
۵. بعد از تمدید، نصب و reload را بررسی کنید
وقتی آزمون و علت شکست روشن شد، تمدید واقعی را با ابزار فعلی انجام دهید. در نصب Certbot، فرمان renew گواهی‌های واجد شرایط را پردازش می‌کند؛ اجراشدن فرمان الزاماً به معنی تمدید همه موارد نیست. سپس مطمئن شوید سرویس مصرف‌کننده، فایل‌های درست را می‌خواند. مسیرهای ساختگی را جایگزین تنظیمات فعال نکنید.
sudo certbot renew
sudo nginx -tفرمان دوم فقط برای سرور Nginx است و صحت تنظیمات آن را می‌آزماید. اگر پیکربندی معتبر بود و سرویس شما به reload نیاز داشت، مدیر سرور می‌تواند روش مناسب همان سرویس را اجرا کند؛ مثلاً در نصب systemd متداول، sudo systemctl reload nginx. خروجی خطا را نادیده نگیرید. restart گسترده برای اصلاح یک مسیر گواهی اشتباه، علت را پنهان می‌کند و می‌تواند اختلال دیگری ایجاد کند.
چطور گواهی بیرونی را با OpenSSL بررسی کنیم؟
اگر OpenSSL روی سیستم شما نصب است، فرمان زیر یک اتصال TLS با نام SNI مشخص ایجاد می‌کند و مشخصات گواهی نخست را نمایش می‌دهد. example.com را در هر دو قسمت جایگزین کنید. این بررسی برای دیدن نام و تاریخ مفید است و به‌تنهایی جای اعتبارسنجی کامل مرورگر، زنجیره اعتماد یا آزمون همه نودها را نمی‌گیرد.
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuerسپس www و زیردامنه‌های مهم را جدا بررسی کنید. برای سایتی پشت CDN، نتیجه همین فرمان نیز ممکن است گواهی CDN باشد. مقایسه مبدأ باید با نام صحیح، مجوز دسترسی و اطلاعات معماری انجام شود. استفاده از IP خام بدون SNI مناسب ممکن است گواهی پیش‌فرض میزبان دیگری را نشان دهد.
جلوگیری از تکرار: اعتبار را از بیرون پایش کنید
یک هشدار مستقل برای نزدیک‌شدن پایان اعتبار تنظیم کنید و گیرنده‌ای تعیین کنید که واقعاً آن را پیگیری کند. علاوه بر وجود timer، نتیجه اجرای آخر و آزمون تمدید را بررسی کنید. اگر challenge به رکورد دستی وابسته است، صرف فعال‌بودن cron به معنی تمدید بدون دخالت نیست. مسئولیت نگهداری گواهی لبه و مبدأ را نیز مشخص کنید.
پس از رفع، صفحه ورود و مسیرهای اصلی را با HTTPS آزمایش کنید و تاریخ جدید را ثبت کنید. خطای TLS می‌تواند دسترسی کاربر و خزنده را مختل کند، اما برای هر رخداد نمی‌توان افت رتبه ثابتی اعلام کرد. حفظ دسترسی معتبر و کوتاه‌کردن اختلال، اقدام کاربردی‌تر است. برای بررسی اولیه از ابزار سلامت سایت و برای رسیدگی مستمر از خدمات مدیریت سرور آفاق هاست کمک بگیرید.
پرسش‌های رایج درباره رفع خطای انقضای SSL
آیا تمدید دامنه، SSL را هم تمدید می‌کند؟
این دو فرایند جدا هستند. وضعیت ثبت دامنه، صدور گواهی و نصب آن را مستقل بررسی کنید؛ حتی اگر در یک پنل مدیریت می‌شوند.
آیا پاک‌کردن کش مرورگر کافی است؟
اگر سرور گواهی منقضی ارائه کند، خیر. ابتدا تاریخ گواهی مشاهده‌شده را بسنجید و بعد اختلاف دستگاه‌ها یا مسیرهای شبکه را پیگیری کنید.
چرا بعد از تمدید هنوز هشدار داریم؟
ممکن است فایل جدید در سرویس بارگذاری نشده، نام موردنظر پوشش داده نشده یا لایه دیگری گواهی قدیمی ارائه کند. هر لایه را با نشانی و نام دقیق خودش بررسی کنید.
منابع رسمی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.