اگر مرورگر می‌گوید گواهی SSL برای دامنهٔ دیگری صادر شده، ابتدا نام دقیق داخل آدرس، نام‌های مجاز گواهی و مقصد اتصال را با هم مقایسه کنید. این خطا لزوماً به معنی منقضی‌شدن SSL نیست؛ ممکن است به سرور قدیمی برسید، نامی مثل www داخل گواهی نباشد یا سرویس HTTPS گواهی میزبان دیگری را تحویل دهد. خرید گواهی تازه یا پاک‌کردن کش وردپرس، بدون این تشخیص، ممکن است هیچ اثری نداشته باشد.
این راهنما مسیر تشخیصِ بدون تغییر تنظیمات را توضیح می‌دهد. برای آشنایی با نقش گواهی و زنجیرهٔ اعتماد، ابتدا گواهی SSL چیست را ببینید. از صفحهٔ هشدار امنیتی عبور نکنید و در اتصال خطادار رمز وارد نکنید.
۱. نوع خطا و نام دقیق را ثبت کنید
نام داخل نوار آدرس را کامل بنویسید: example.com، www.example.com و shop.example.com سه نام متفاوت‌اند. مسیرهایی مثل /blog/ در پوشش نامِ گواهی نقشی ندارند. اگر برنامه شما را به نام دیگری هدایت می‌کند، خطا ممکن است مربوط به مقصد هدایت باشد، نه آدرس اولیه.
| نشانه | مسیر بررسی |
|---|---|
| خطای نام مانند ERR_CERT_COMMON_NAME_INVALID | نام درخواست‌شده، SAN و مقصد اتصال را تطبیق دهید؛ نام خطا به‌تنهایی علت نهایی نیست. |
| خطای تاریخ گواهی | بازهٔ اعتبار و ساعت دستگاه را بررسی کنید؛ با ناهماهنگی نام یکی نیست. |
| صفحه با HTTPS باز می‌شود، اما منابع HTTP دارد | مسیر رفع محتوای ترکیبی را دنبال کنید. |
در پنجرهٔ اطلاعات گواهی مرورگر، اگر بدون عبور از هشدار در دسترس است، بخش نام‌های جایگزین یا Subject Alternative Name را بخوانید. صرف نام صادرکننده یا یک عنوان عمومی در بالای پنجره، پوشش دامنهٔ شما را ثابت نمی‌کند. اگر نمایش جزئیات ممکن نیست، متن خطا را برای پشتیبانی بفرستید؛ نیازی به ادامهٔ ناامن نیست.
۲. نام گواهی را با آدرس سایت اشتباه نگیرید
مطابق استاندارد تطبیق هویت سرویس در TLS، نام مرجع باید با شناسهٔ مناسب داخل گواهی تطبیق داشته باشد. برای نمونه، وجود example.com به‌تنهایی پوشش www.example.com را ایجاد نمی‌کند؛ و *.example.com جای نام ریشهٔ example.com را نمی‌گیرد.
اگر سایت شما به یک سرویس بیرونی CNAME شده، نامی که کاربر در URL نوشته همچنان اهمیت دارد. اینکه مقصد DNS گواهی معتبر برای نام خودش دارد، کافی نیست تا دامنهٔ سفارشی شما هم معتبر شود. یک مثال آموزشی: سرویس customer.vendor.example می‌تواند گواهی سالم خودش را داشته باشد؛ اما بازدید از shop.example.com به گواهی پوشانندهٔ همین نام نیاز دارد.
اشتباه رایج: تغییر آدرس مرورگر به IP، آزمایش درستی برای گواهی دامنه نیست. درخواست با IP هویت دیگری را بررسی می‌کند و ممکن است به گواهی پیش‌فرض سرور برسد.
۳. مقصد DNS را جداگانه بررسی کنید
- نام دقیق خطادار را در ابزار رسمی Google Public DNS وارد کنید؛ فقط نام عمومی، بدون رمز، توکن و مسیر خصوصی.
- رکورد A و سپس AAAA را جدا بررسی کنید؛ اگر نام مستعار وجود دارد، زنجیرهٔ CNAME هم مهم است.
- IPهای برگشتی را با مقصد مورد انتظارِ اعلام‌شده توسط میزبان یا CDN تطبیق دهید. یک نام ممکن است چند مقصد داشته باشد.
- اگر CDN فعال است، انتظار دیدن IP عمومی لبهٔ آن را داشته باشید؛ تفاوت با IP هاست به‌تنهایی خطا نیست.
تصویر بالا یک پاسخ سالم برای دامنهٔ عمومیِ نمونه است، نه گزارش خطای سایت شما. ترتیب پاسخ‌ها و TTL ممکن است در دفعات بعد تغییر کند. برای خواندن خروجی در ویندوز، راهنمای nslookup و برای یافتن محل مدیریت واقعی رکوردها، راهنمای مرجع DNS دامنه کمک می‌کنند.
۴. نقش SNI و هاست اشتراکی را بشناسید
چند سایت می‌توانند روی یک IP سرویس بگیرند. در افزونهٔ SNI در TLS، کلاینت نام سرور موردنظر را هنگام شروع اتصال اعلام می‌کند تا سرویس بتواند گواهی مناسب را انتخاب کند. سپس اعتبار نامِ همان گواهی هم بررسی می‌شود؛ انتخاب و اعتبارسنجی دو موضوع مرتبط اما جدا هستند.
به همین دلیل دستورِ «اتصال به IP با هدر Host دامنه» برای بررسی HTTPS کافی نیست. مستند رسمی curl دربارهٔ نام مقصد توضیح می‌دهد که SNI از URL گرفته می‌شود. اگر پشتیبانی یک مقصد مشخص را برای آزمایش معرفی کرده، باید نام URL حفظ و مقصد اتصال برای همان درخواست تعیین شود؛ این کار جای تغییر تصادفی DNS یا غیرفعال‌کردن بررسی گواهی را نمی‌گیرد.
۵. چه چیزی را در سی‌پنل مشاهده کنید؟
در رابط مشاهده‌شده، مسیر Security → SSL/TLS Certificates یکپارچه است. تب Status وضعیت دامنه و تب Certificates گواهی‌های ذخیره‌شده را نشان می‌دهد؛ در بعضی نسخه‌ها صفحه‌ها جدا هستند. مسیر قدیمی در مستند SSL/TLS سی‌پنل هم آمده است.
وجود یک فایل در فهرست Certificates، اثبات نمی‌کند همان گواهی در اتصال عمومی تحویل داده می‌شود. نام دقیق سایت را در Status پیدا و اطلاعات گواهیِ مربوط را بررسی کنید. اگر گواهی مناسب در پنل موجود است ولی اتصال عمومی نام دیگری می‌دهد، مقصد DNS، واسط CDN و اتصال گواهی به میزبان مجازی باید توسط مسئول سرویس بررسی شوند. هیچ گزینهٔ Install، Delete یا اجرای AutoSSL برای تهیهٔ این تصویر استفاده نشده است.
اگر مسئله واقعاً صادرنشدن گواهی است، از راهنمای وضعیت AutoSSL استفاده کنید. اگر پیام صریحاً CAA را نام می‌برد، تشخیص خطای CAA مسیر مستقلی است؛ ناهماهنگی نام را با محدودیت صدور یکی ندانید.
۶. نتیجه را به یک اقدام مشخص تبدیل کنید
| نتیجهٔ مقایسه | درخواست مشخص از مسئول سرویس |
|---|---|
| نام لازم داخل SAN نیست | پوشش گواهیِ همان نام بررسی شود؛ صرف تمدید همان مجموعهٔ قبلی مشکل را حل نمی‌کند. |
| پاسخ DNS به مقصد قبلی می‌رود | مرجع فعال و رکورد دقیق شناسایی و طرح اصلاح محدود آماده شود. |
| نام و مقصد درست‌اند، گواهی سایت دیگری می‌آید | انتخاب گواهی برای همان میزبان مجازی و SNI بررسی شود. |
| خطا فقط در یک دستگاه یا شبکه دیده می‌شود | زمان، پاسخ DNS، واسط سازمانی/VPN و نام صادرکننده مقایسه شوند؛ امنیت دستگاه خاموش نشود. |
گزارش خوب شامل نام کامل، زمان و منطقهٔ زمانی، نوع خطا، نتیجهٔ A/AAAA، نام‌های گواهی و وضعیت CDN است. کلید خصوصی، رمز سی‌پنل و کوکی مرورگر برای این تشخیص لازم نیست. اگر اصلاح مدیریتی لازم شد، ابتدا پیکربندی فعلی، مالک تغییر و روش بازگردانی مشخص شوند؛ این مقاله دستور ویرایش زندهٔ DNS یا وب‌سرور ارائه نمی‌کند.
۷. پرسش‌های رایج
آیا تمدید گواهی خطای نام را رفع می‌کند؟
فقط اگر گواهیِ تحویل‌داده‌شده بعد از اصلاح، نام لازم را پوشش دهد. تمدید گواهی برای نام‌های اشتباه یا نصب‌نشدن آن روی مقصد واقعی، خطا را باقی می‌گذارد.
اگر با IP سایت باز شود، DNS و SSL سالم‌اند؟
خیر. این آزمایش می‌تواند سایت پیش‌فرض یا هویت IP را بسنجد. برای نتیجهٔ معتبر باید نام دامنه، مقصد و اعتبار TLS همان اتصال معلوم باشند.
