وقتی SSL در پنل تمدید شده ولی کاربر هنوز گواهی قدیمی را می‌بیند، باید مشخص کنید گواهی جدید کجا صادر، کجا نصب و از کدام مقصد تحویل داده می‌شود. گواهی ذخیره‌شده در هاست، گواهی فعالِ وب‌سرور و گواهی لبهٔ CDN ممکن است یکسان نباشند. پاک‌کردن کش افزونهٔ وردپرس به‌تنهایی این اختلاف را توضیح نمی‌دهد.
در این راهنما «قدیمی» یعنی تفاوت قابل‌اندازه‌گیری در گواهی، مانند سریال، اثرانگشت یا بازهٔ اعتبار؛ نه صرف قدیمی‌بودن ظاهر صفحه. اگر هنوز صدور موفقی ندارید، ابتدا وضعیت AutoSSL و صادرنشدن گواهی را بررسی کنید.
۱. ثابت کنید چه چیزی تمدید شده است
سه رخداد را جدا ثبت کنید: درخواست تمدید پذیرفته شده؛ گواهی جدید صادر و در پنل موجود است؛ گواهی جدید روی مسیر سرویس‌دهی فعال است. رسید پرداخت، شروع فرایند AutoSSL یا وجود یک فایل CRT به‌تنهایی مرحلهٔ سوم را ثابت نمی‌کند.
- نام دقیق سایت و همهٔ نام‌های درخواست را مشخص کنید؛ نام اصلی و
wwwجدا بررسی شوند. - تاریخ آغاز و پایان اعتبار را با منطقهٔ زمانی ثبت کنید. تاریخ UTC پنل را بی‌تبدیل با ساعت محلی مقایسه نکنید.
- سریال را همراه صادرکننده یا اثرانگشت SHA-۲۵۶ ثبت کنید؛ سریال به‌تنهایی شناسهٔ جهانی نیست.
- اگر خطا فقط در یک دستگاه است، ساعت و منطقهٔ زمانی آن را هم بررسی کنید.
نام صادرکننده الزاماً پس از تمدید تغییر نمی‌کند. برعکس، تفاوت صادرکننده یا سریال در سرویس‌های توزیع‌شده همیشه خطا نیست؛ بعضی سرویس‌ها چند گواهی معتبر برای الگوریتم‌ها یا نقاط مختلف دارند. معیار اصلی، اعتبار و پوشش نام در مسیر واقعیِ همان کاربر است.
۲. وضعیت و فایل ذخیره‌شده را در سی‌پنل تفکیک کنید
- در Security → SSL/TLS Certificates → Status نام دقیق دامنه را پیدا کنید. در رابط قدیمی، نام صفحه SSL/TLS Status است.
- متن وضعیت و تاریخ انقضا را بخوانید؛ وجود پیام تمدید خودکار، گزارش انجام‌شدن یک تمدید مشخص نیست.
- در صورت دسترسی، با View Certificate جزئیات گواهی همان ردیف را مشاهده و با آنچه در اتصال عمومی دیده می‌شود مقایسه کنید.
این عکس واقعی از یک محیط مجاز سی‌پنل، محل وضعیت و تاریخ را نشان می‌دهد؛ شبیه‌سازی خرابی یا اثبات مشکل تمدید رایکت نیست. جزئیات مسیر و تفاوت رابط یکپارچه در مستند رسمی SSL/TLS Status آمده است.
تب Certificates فهرست دیگری است: گواهی‌های ذخیره‌شده روی سرور. ممکن است نسخهٔ قدیمی، گواهی سایت دیگر یا فایلِ هنوز نصب‌نشده هم در آن باشد. فهرست را با وضعیت سرویس فعال یکی نگیرید.
برای شناخت مراحل نصبِ گواهی خریداری‌شده، راهنمای نصب دستی SSL مرجع مکمل است. برای تشخیص، گواهی‌ها یا کلیدها را حذف نکنید و نصب را بدون تعیین میزبان مقصد تکرار نکنید.
۳. لبهٔ CDN و سرور اصلی را جدا بررسی کنید
در سایت پشت CDN، مرورگر معمولاً با لبهٔ CDN ارتباط TLS می‌سازد؛ CDN اتصال جداگانه‌ای به سرور اصلی دارد. مستند مفاهیم SSL در Cloudflare همین تفاوت گواهی Edge و Origin را توضیح می‌دهد. تازه‌شدن گواهی Origin الزاماً گواهیِ دیده‌شده در مرورگر را عوض نمی‌کند.
| مشاهده | برداشت عملی |
|---|---|
| پنل هاست جدید، اتصال عمومی قدیمی | نخست مشخص کنید کاربر به CDN، هاست قبلی یا گره دیگری می‌رسد. |
| CDN معتبر، اتصال مستقیم به Origin نامعتبر | مسیر سرور اصلی جدا بررسی شود؛ سالم‌بودن لبه وضعیت همهٔ مسیرها را ثابت نمی‌کند. |
| چند گواهی متفاوت اما همگی معتبر و پوشانندهٔ نام | تفاوت را با طراحی سرویس و مسئول آن تطبیق دهید؛ صرف تفاوت، علت خطا نیست. |
نکته: برای دیدن گواهی هاست، CDN یا حفاظت Origin را خاموش نکنید. گواهی مخصوص Origin هم ممکن است برای اعتماد عمومی مرورگر طراحی نشده باشد؛ نامعتبر بودن آن در یک اتصال مستقیمِ عمومی، به‌تنهایی خرابی ارتباط CDN با Origin را ثابت نمی‌کند.
۴. همهٔ مقصدها و نام‌ها را در یک جدول مقایسه کنید
از همان نام خطادار رکوردهای A و AAAA را بخوانید. اگر چند IP دارید، یک بررسی موفق برای یک IP کافی نیست. سرور اصلی، www، زیردامنه، IPv4 و IPv6 می‌توانند به پیکربندی‌های متفاوت برسند. محل مدیریت رکورد را با مرجع DNS فعال دامنه مشخص کنید.
یک جدول کاری با ستون‌های «نام»، «مسیر: CDN یا Origin»، «IP یا گره مشاهده‌شده»، «صادرکننده و سریال/اثرانگشت»، «پایان اعتبار» و «زمان آزمون» بسازید. فهرست پنل و اتصال عمومی را در دو ردیف مجزا نگه دارید؛ پرکردن آن با حدس، تشخیص را خراب می‌کند.
برای نمونه، اگر نام اصلی همیشه جدید است ولی www به هاست قبلی می‌رود، مشکل به همان نام و مقصد محدود می‌شود. اگر یک آدرس IPv6 گواهی قدیمی می‌دهد، تمدید دوبارهٔ مقصد IPv4 پاسخ آن مسیر را عوض نمی‌کند. این مثال‌ها سناریوی تشخیصی‌اند، نه نتیجهٔ آزمایش روی هاست مشتری.
۵. کش صفحه را از وضعیت اتصال جدا کنید
کش HTML، تصویر و فایل‌های استاتیک با گواهیِ اتصال TLS یک چیز نیست. یک صفحهٔ قدیمی می‌تواند روی اتصال با گواهی جدید دیده شود. برای مقایسهٔ گواهی، یک اتصال تازه از ابزار یا مرورگر دیگر بگیرید و نام و مقصد را ثابت نگه دارید؛ بستن اتصال قدیمی و گرفتن مشاهدهٔ تازه از پاک‌سازی همهٔ داده‌های سایت هدفمندتر است.
اگر نتیجه بین دو شبکه فرق دارد، پاسخ DNS و مقصد واقعی هرکدام را ثبت کنید. خواندن TTL کمک می‌کند اختلاف کش DNS را بفهمید، اما «تا ۴۸ ساعت صبر کنید» بدون مشاهدهٔ رکورد و TTL تشخیص نیست؛ راهنمای TTL در DNS را ببینید. پس از سپری‌شدن مهلت هم ممکن است مقصدِ پیکربندی‌شده همچنان اشتباه باشد.
۶. چه زمانی مسئله واقعاً حل شده است؟
- نام‌های موردنیاز در گواهیِ مسیر واقعی کاربر پوشش داده شوند.
- بازهٔ اعتبار با ساعت درست معتبر باشد و زنجیره در کلاینت پشتیبانی‌شده اعتبارسنجی شود.
- مقصدهای مورد انتظارِ A و AAAA و لایه‌های مربوط بررسی شوند؛ نتیجهٔ یک شبکه به کل اینترنت تعمیم داده نشود.
- بعد از اصلاح مجاز، همان جدولِ قبل دوباره تکمیل شود؛ صرف پیام «نصب شد» جای آزمون اتصال را نگیرد.
اگر فقط صدور گواهی شکست می‌خورد و خطا CAA است، تشخیص محدودیت CAA را دنبال کنید. اگر تغییر نصب یا بارگذاری سرویس لازم شد، مسئول سرور باید نسخهٔ فعلی پیکربندی، گواهی/کلید مربوط، شرط توقف و مسیر بازگشت را پیش از تغییر تعیین کند؛ این راهنما فرمان restart یا نصب کورکورانه نمی‌دهد.
۷. پرسش‌های رایج
آیا باید گواهی‌های قدیمی پنل را پاک کنم؟
برای تشخیص خیر. حذف فایلِ ذخیره‌شده راه اثبات انتخاب گواهی فعال نیست و ممکن است وابستگی ناشناخته‌ای داشته باشد؛ ابتدا اتصال و میزبان دقیق را مشخص کنید.
چه مدرکی برای پشتیبانی بفرستم؟
نام کامل، زمان آزمون، لایهٔ مورد بررسی، تاریخ اعتبار و شناسهٔ عمومی گواهی، نتیجهٔ DNS و متن خطا کافی‌اند. کلید خصوصی، رمز و تصویر بدون بلور اطلاعات حساب لازم نیست.
