خطای SSL؛ چرا با وجود گواهی سایت اخطار می‌دهد؟
نصب بودن گواهی لزوماً به معنی سالم بودن تمام مسیرهای سایت نیست. این مقاله تفاوت خطای گواهی، منابع ناامن و ناهماهنگی لایه‌های ارتباط را توضیح می‌دهد.
خطای SSL را می‌بینید، درحالی‌که پشتیبانی می‌گوید گواهی نصب است. شاید صفحه اصلی باز شود، اما نسخه www اخطار بدهد؛ یا پس از فعال کردن CDN، سایت در حلقه انتقال بیفتد. این وضعیت نشان می‌دهد «نصب بودن گواهی» فقط بخشی از بررسی است.
باید ببینید کاربر برای همان نام و همان مسیر، چه گواهی و پاسخی دریافت میکند. گواهی موجود در پنل ممکن است با چیزی که مرورگر واقعاً می‌بیند متفاوت باشد. حذف اخطار بدون فهم علت، راه‌حل مناسبی برای سایت فعال نیست.
بررسی خطای SSL را از ثبت متن اخطار شروع کنید
نام دامنه، وجود یا نبود www، صفحه مورد نظر و زمان خطا را یادداشت کنید. بررسی کنید همه کاربران مشکل دارند یا فقط یک دستگاه. ساعت اشتباه دستگاه می‌تواند در اعتبارسنجی اثر بگذارد، اما نباید هر اخطار را به آن نسبت داد.
از کاربر نخواهید برای خرید، هشدار مرورگر را نادیده بگیرد. این کار مشکل را حل نمی‌کند و عادت نامناسبی ایجاد میکند. ابتدا مشخص کنید اخطار از نام گواهی، تاریخ اعتبار، زنجیره اعتماد یا وضعیت دیگری است.
| نشانه | مسیر بررسی اولیه |
|---|---|
| فقط یک نام اخطار می‌دهد | پوشش همان نام در گواهی |
| پس از انتقال هاست شروع شده | مقصد DNS و گواهی سرور جدید |
| صفحه امن است ولی بخشی بار نمی‌شود | منابع HTTP و محتوای ترکیبی |
| انتقال پی‌درپی رخ می‌دهد | قواعد HTTPS در سایت، سرور و CDN |
| فقط یک دستگاه مشکل دارد | ساعت، مرورگر و مسیر اتصال همان دستگاه |
دامنه اصلی و www را جدا ببینید
گواهی باید نام‌هایی را که کاربر با آن‌ها ارتباط امن برقرار میکند پوشش دهد. اگر قرار است www به دامنه اصلی هدایت شود، اتصال اولیه به www هم باید درست برقرار شود. هدایت به نام دیگر، نیاز به گواهی معتبر در نقطه شروع را حذف نمی‌کند.
زیردامنه‌های پنل، فروشگاه و ایمیل نیز ممکن است پوشش جدا بخواهند. از عبارت «گواهی برای سایت فعال است» نتیجه نگیرید که تمام نام‌های حساب پوشش داده شده‌اند. فهرست نام‌های واقعی را تهیه و هرکدام را آزمایش کنید.
محتوای ترکیبی چیست؟
وقتی صفحه با HTTPS باز میشود ولی بخشی از منابع آن از HTTP درخواست میشود، با محتوای ترکیبی روبه‌رو هستید. رفتار مرورگر برای انواع منابع یکسان نیست؛ برخی را ارتقا می‌دهد و برخی را مسدود میکند. بنابراین صفحه ممکن است ناقص یا با خطا دیده شود.
تصویر قدیمی، فونت، اسکریپت یا فایل قالب می‌تواند منشأ درخواست ناامن باشد. باید منبع واقعی در گزارش مرورگر پیدا شود. جایگزینی بی‌هدف همه رشته‌های متنی در پایگاه داده، بدون ابزار مناسب و نسخه پشتیبان، می‌تواند تنظیمات را خراب کند.
برای وردپرس، مسئول فنی باید روش سازگار با ساختار داده را انتخاب کند. پس از اصلاح، فقط صفحه نخست را نبینید؛ محصول، فرم، ورود و صفحات قدیمی را هم بررسی کنید. بعضی منابع فقط در بخش خاصی استفاده می‌شوند.
وقتی CDN در مسیر است، دو ارتباط داریم
ممکن است کاربر به CDN وصل شود و CDN به سرور اصلی. وضعیت گواهی و شیوه رمزگذاری این دو مسیر باید هماهنگ باشند. حالت Full (strict) در Cloudflare، اعتبار گواهی مبدأ را نیز بررسی میکند؛ انتخاب حالت باید با آماده بودن مبدأ انجام شود.
پایین آوردن سطح حفاظت فقط برای ناپدید شدن اخطار، پاسخ نهایی نیست. اگر گواهی سرور اصلی نامعتبر است، همان قسمت را اصلاح کنید. گواهی مخصوص ارتباط مبدأ با یک سرویس واسط نیز لزوماً برای اتصال مستقیم مرورگر معتبر نیست.
حلقه انتقال چرا رخ می‌دهد؟
ممکن است یک لایه درخواست را به HTTPS ببرد و لایه دیگر دوباره مسیر متفاوتی بسازد. تنظیمات برنامه، وب‌سرور و سرویس واسط باید با هم سازگار باشند. افزودن چند افزونه انتقال به امید حل مشکل، می‌تواند حلقه را پیچیده‌تر کند.
- زنجیره هدایت از نشانی شروع را ثبت کنید.
- مشخص کنید هر پاسخ انتقال از کدام لایه می‌آید.
- تنظیم مورد تعارض را اصلاح کنید.
- کش مرتبط را با روش مناسب پاک کنید.
- نشانی‌های اصلی و مسیر ورود و خرید را دوباره آزمایش کنید.
نکته: پیام «گواهی نصب شد» را با نتیجه واقعی مرورگر تطبیق دهید؛ سلامت سایت از مسیر کاربر سنجیده میشود.
یک مثال عملی برای تصمیم‌گیری
یک فروشگاه فرضی پس از فعال کردن سرویس واسط، صفحه اصلی را باز میکند اما تسویه‌حساب خطای انتقال می‌دهد. در این مثال، مسئله‌ای که باید حل شود این است: ناهماهنگی احتمالی میان مسیر HTTPS سایت و لایه واسط قرار نیست از روی یک نشانه، نتیجه قطعی بگیریم. بهتر است ابتدا معلوم کنیم چه چیزی قابل مشاهده است و چه چیزی فقط حدس ماست. این تفکیک جلوی خرید عجولانه یا تغییر تنظیماتی را می‌گیرد که به مشکل ارتباطی ندارند.
اولین مدرک مفید در این سناریو، زنجیره انتقال و گواهی ارائه‌شده برای نام دقیق صفحه خرید است. اگر این اطلاعات در دسترس نیست، قدم بعدی تهیه همان مدرک است؛ نه انتخاب گران‌ترین گزینه. گاهی یک گزارش کوتاه نشان می‌دهد مسئله در کدام بخش قرار دارد و گاهی لازم است بررسی دقیق‌تری انجام شود. در هر دو حالت، ثبت وضعیت اولیه کمک میکند نتیجه اقدام را با چیزی واقعی مقایسه کنید.
اقدام پیشنهادی نخست این است: مسئول فنی لایه ایجادکننده هر انتقال را مشخص کند. این اقدام باید با وضعیت سرویس و اختیار شما سازگار باشد. اگر دسترسی لازم را ندارید، از فرد مسئول بخواهید نتیجه را همراه با توضیح کوتاه ارائه کند. نیازی نیست صاحب کسب‌وکار همه جزئیات فنی را خودش اجرا کند؛ اما باید بداند چه کاری انجام شده و قرار است چه اثری داشته باشد.
اشتباه وسوسه‌کننده در این مثال، خاموش کردن اعتبارسنجی یا درخواست از مشتری برای عبور از هشدار است. ممکن است چنین کاری ظاهراً سریع‌تر باشد، اما اگر علت را برطرف نکند، هزینه یا ابهام تازه‌ای به وجود می‌آورد. راه بهتر این است که برای هر تغییر، یک دلیل مشخص داشته باشید و پس از آن همان نشانه اولیه را دوباره بررسی کنید. هم‌زمان عوض کردن چند عامل، تشخیص اثر هرکدام را دشوار میکند.
پیش از اقدام، معیار نتیجه را مشخص کنید
برای موضوع خطای SSL، نتیجه مورد انتظار در این سناریو چنین است: باز شدن نام‌های لازم با ارتباط معتبر و انجام مسیر خرید بدون حلقه انتقال. این جمله را در درخواست خود بنویسید تا معیار تحویل برای دو طرف یکسان باشد. عبارت‌هایی مثل «بررسی شد» یا «انجام شد» به‌تنهایی نشان نمی‌دهند نیاز شما برطرف شده است. باید نتیجه‌ای وجود داشته باشد که بتوان آن را مشاهده یا تأیید کرد.
مسئول مناسب پیگیری، مدیر سایت با دسترسی به وب‌سرور و سرویس واسط است. اگر افراد مختلفی درگیرند، یک نفر هماهنگی را بر عهده بگیرد و پاسخ‌ها را کنار هم قرار دهد. مسئول مالی، طراح و پشتیبانی ممکن است هرکدام بخشی از اطلاعات را داشته باشند؛ تصمیم خوب از ترکیب این اطلاعات به دست می‌آید. نبودن مسئول مشخص، حتی یک کار ساده را طولانی میکند.
این پرسش را مطرح کنید: «اخطار از گواهی کدام لایه یا از کدام قانون هدایت ایجاد میشود؟» پاسخ خوب باید محدودیت‌ها و اقدام بعدی را روشن کند. اگر جواب فقط یک عبارت تبلیغاتی یا توصیه کلی بود، جزئیات مربوط به وضعیت خودتان را بخواهید. هدف گرفتن قول ناممکن نیست؛ باید بتوانید بفهمید چه چیزی در تعهد ارائه‌دهنده است و کدام بخش به تنظیمات یا تصمیم شما وابسته است.
چک‌لیست پیگیری و تحویل
- شرح کوتاهی از نیاز و شرایط فعلی بنویسید؛ نام سرویس، دامنه مرتبط و زمان مشاهده مسئله را در صورت نیاز ثبت کنید.
- مدرک مربوط را جمع کنید و اطلاعات محرمانه مثل رمز، کلید یا داده مشتری را از نسخه ارسالی عمومی حذف کنید.
- اقدام پیشنهادی را به یک نتیجه قابل بررسی وصل کنید و مشخص کنید چه کسی آن را انجام می‌دهد.
- اگر تغییر بر سرویس فعال اثر دارد، زمان انجام و روش حفظ وضعیت قبلی را پیشاپیش هماهنگ کنید.
- پس از اقدام، بررسی اصلی را انجام دهید: نسخه‌های دامنه، صفحات حساس و منابع صفحه بدون خطای مربوط کار کنند.
- نتیجه و موارد باقی‌مانده را ثبت کنید؛ پایان یک درخواست پشتیبانی لزوماً به معنی پایان همه بررسی‌های لازم نیست.
در مورد برگشت از تغییر، تنظیمات پیشین را ثبت کنید؛ تغییرهای امنیتی را با امکان بازگرداندن پیکربندی و بدون از دست دادن کلیدها انجام دهید. پیش از اقدام درباره همین موضوع توافق کنید. داشتن راه بازگشت فقط به معنی نگه داشتن یک تصویر از پنل نیست؛ لازم است مشخص باشد چه اطلاعات یا اختیاراتی برای برگشت لازم است. اگر اقدام برگشت‌پذیر نیست، تصمیم باید با آگاهی از همین محدودیت گرفته شود.
اگر اخطار فقط در یک شبکه دیده میشود، مقصد واقعی را هم بررسی کنید. ممکن است آن مسیر به سرور قدیمی برسد یا عامل محلی در ارتباط دخالت کند. صرف تفاوت نتیجه بین دو دستگاه، دلیل قطعی خراب بودن یا سالم بودن گواهی نیست.
اخطار مشتری را با نشانی دقیق دنبال کنید
از مشتری بخواهید نام کامل صفحه و زمان مشاهده را اعلام کند؛ اطلاعات پرداخت یا رمز لازم نیست. تفاوت میان دامنه اصلی و زیردامنه می‌تواند علت بررسی را تغییر دهد. اگر فقط تصویر اخطار دارید، حدس نزنید که همه درخواست‌ها همان مسیر را طی کرده‌اند.
پس از رفع مشکل، نشانی‌های قدیمی و لینک‌های موجود در ایمیل‌های سایت را هم آزمایش کنید. ممکن است کاربران از مسیری وارد شوند که مدیر روزانه استفاده نمی‌کند. اصلاح باید مسیر ورود واقعی مشتری را پوشش دهد، نه فقط آدرسی که در مرورگر مسئول فنی باز است.
برای مطالعه بیشتر
مطالب مرتبط را در راهنمای هاست سی‌پنل و صفحه سوالات متداول دنبال کنید.
مراجع فنی این مقاله: محتوای ترکیبی در MDN و حالت سخت‌گیرانه رمزگذاری Cloudflare.
سوالات متداول
آیا نصب دوباره گواهی همیشه مشکل را حل میکند؟
خیر؛ ممکن است مشکل از نام، هدایت یا منابع ناامن باشد. ابتدا متن خطا و مسیر آن را بررسی کنید.
آیا www هم گواهی میخواهد؟
اگر کاربر با HTTPS به آن وصل میشود، گواهی باید همان نام را پوشش دهد؛ حتی اگر بعداً هدایت شود.
محتوای ترکیبی یعنی چه؟
یعنی صفحه امن، منابعی را با نشانی ناامن درخواست میکند. نوع منبع در رفتار مرورگر اثر دارد.
آیا میتوان هشدار را به مشتری نادیده گرفتنی دانست؟
خیر؛ علت را رفع کنید. عبور از هشدار جای اصلاح ارتباط را نمیگیرد.
چرا خطای SSL فقط در بعضی صفحات است؟
ممکن است آن صفحات منابع یا قواعد متفاوتی داشته باشند. همان مسیر مشکل‌دار را بررسی کنید.
