خطای SSL در سرور یکی از آن خطاهایی است که کاربر در همان ثانیه‌ی اول آن را می‌بیند، ولی مدیر سایت غالباً دیرتر از همه متوجه می‌شود. مرورگر با یک هشدار قرمز اعلام می‌کند که اتصال امن نیست، کاربر به‌جای ورود به سایت به صفحه‌ی هشدار نگاه می‌کند و در چند ثانیه به سایت رقیب می‌رود. سال‌هاست روی سرورهای تولیدی و پروژه‌های وردپرسی با این خطا مواجه می‌شوم و در تجربه‌ام، بیشترین آسیب نه از خود خطا، بلکه از تأخیر در تشخیص و رفع آن می‌آید.

این مقاله را برای عیب‌یابی نظام‌مند نوشته‌ام، نه برای وصل کردن راه‌حل‌های آماده. اگر سایت شما همین حالا هشدار امنیتی نشان می‌دهد، اگر کاربران از پیام نامعتبر بودن گواهی شکایت می‌کنند، یا اگر بعد از تمدید گواهی، باز هم HTTPS سبز نمی‌شود، ترتیب بخش‌ها همان مسیری است که در بحران‌های واقعی اجرا می‌کنم.

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

SSL (Secure Sockets Layer) یک پروتکل رمزنگاری است که اتصال بین مرورگر کاربر و سرور شما را رمزنگاری می‌کند. نسخه‌ی مدرن این پروتکل، TLS (Transport Layer Security) نام دارد، ولی در زبان عامیانه هنوز با نام SSL شناخته می‌شود. توضیح تکمیلی این پروتکل در ویکی‌پدیا موجود است، ولی جان ماجرا در سه تضمین اصلی این پروتکل است: رمزنگاری داده‌ها، احراز هویت سرور، و تضمین یکپارچگی داده‌ها.

نکته‌ای که در پروژه‌های واقعی بارها دیده‌ام این است که گواهی SSL فقط زمانی کار می‌کند که تمام این سه تضمین هم‌زمان برقرار باشند. یک گواهی معتبر ولی با زنجیره‌ی ناقص، پیام هشدار می‌دهد. یک گواهی کامل ولی با دامنه‌ی متفاوت، هشدار می‌دهد. یک گواهی درست ولی با پروتکل TLS قدیمی، هشدار می‌دهد. همین سه‌گانه، دلیل اصلی متنوع بودن خطاهای SSL در سرور است.

از منظر سئو و تجربه‌ی کاربر، HTTPS امروز یک استاندارد اجباری است، نه یک مزیت رقابتی. گوگل از سال‌ها پیش HTTPS را به‌عنوان یکی از سیگنال‌های رتبه‌بندی معرفی کرده و مرورگرها نیز سایت‌های بدون HTTPS را با هشدار برجسته نشان می‌دهند. مباحث مرتبط با این حوزه در SSL و HTTPS در امنیت وب و امنیت وب چیست باز شده است.

گواهی SSL، پلاک شناسایی مغازه‌ی شما در دنیای وب است. اگر پلاک جعلی، منقضی یا ناقص باشد، مشتری قبل از ورود به مغازه، از ترس فرار می‌کند.

ده پیام خطای رایج SSL و معنای واقعی هرکدام

مرورگرها امروز پیام‌های بسیار متنوعی برای خطاهای SSL نشان می‌دهند. هر پیام، به یک ریشه‌ی مشخص اشاره دارد و مسیر عیب‌یابی هر یک متفاوت است:

پیام خطا در مرورگرریشه‌ی واقعیاقدام اولیه
NET::ERR_CERT_DATE_INVALIDگواهی منقضی یا زمان سیستم اشتباهبررسی تاریخ و تمدید گواهی
NET::ERR_CERT_COMMON_NAME_INVALIDدامنه‌ی گواهی با دامنه‌ی سایت هماهنگ نیستبررسی دامنه یا صدور مجدد گواهی
NET::ERR_CERT_AUTHORITY_INVALIDگواهی self-signed یا زنجیره‌ی ناقصنصب زنجیره‌ی کامل گواهی
NET::ERR_SSL_PROTOCOL_ERRORناسازگاری نسخه‌ی TLS یا پورت اشتباهفعال‌سازی TLS 1.2 و 1.3
NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCHعدم تطابق cipher suitesبازبینی پیکربندی وب‌سرور
ERR_TOO_MANY_REDIRECTSریدایرکت زنجیره‌ای HTTP/HTTPSاصلاح قواعد ریدایرکت
NET::ERR_SSL_OBSOLETE_VERSIONاستفاده از TLS 1.0 یا 1.1ارتقا به TLS 1.2+
This site can’t provide a secure connectionخطای عمومی پیکربندی سروربررسی کامل پیکربندی
Your connection is not privateگواهی نامعتبر یا منقضیبررسی زنجیره و انقضا
Mixed Content Warningبخش‌هایی از صفحه با HTTP لود می‌شوندبازنویسی URL منابع

در تجربه‌ی چندساله‌ام، سه خطای اول بیش از بقیه تکرار می‌شوند و در ۸۰ درصد موارد، با چهار گام مشخص قابل رفع هستند: بررسی انقضا، بررسی دامنه، بررسی زنجیره، و بررسی پیکربندی وب‌سرور.

هشت ریشه‌ی اصلی خطای SSL در سرور

در عیب‌یابی خطای SSL روی سرورهای تولیدی، این هشت ریشه بیش از بقیه تکرار می‌شوند:

ریشه‌ی اول: انقضای گواهی

شایع‌ترین دلیل. اگر گواهی به‌موقع تمدید نشود، مرورگر با پیام NET::ERR_CERT_DATE_INVALID کاربر را متوقف می‌کند. این خطا در سایت‌هایی که از گواهی رایگان Let’s Encrypt استفاده می‌کنند و تمدید خودکار را فعال نکرده‌اند، بیشتر دیده می‌شود. راه‌حل سریع: تمدید گواهی از پنل هاست یا با ابزار Certbot. مباحث مرتبط در نصب گواهی SSL باز شده است.

ریشه‌ی دوم: عدم تطابق دامنه

اگر گواهی برای دامنه‌ی example.com صادر شده باشد ولی سایت روی www.example.com باز شود، مرورگر پیام NET::ERR_CERT_COMMON_NAME_INVALID می‌دهد. راه‌حل: صدور گواهی برای هر دو دامنه یا استفاده از Wildcard SSL. مباحث مرتبط با انواع گواهی در گواهی Wildcard SSL باز شده است.

ریشه‌ی سوم: زنجیره‌ی ناقص گواهی

گواهی‌های صادرشده توسط مراجع معتبر، معمولاً از یک زنجیره‌ی سه‌سطحی تشکیل شده‌اند: گواهی ریشه، گواهی میانی و گواهی سایت. اگر گواهی میانی روی سرور نصب نشود، مرورگر نمی‌تواند زنجیره را کامل کند و پیام NET::ERR_CERT_AUTHORITY_INVALID می‌دهد. این خطا در برخی مرورگرها ناپدید می‌شود ولی در موبایل و مرورگرهای قدیمی‌تر ظاهر می‌شود؛ به همین دلیل یکی از خطاهای فریبنده است.

ریشه‌ی چهارم: ناسازگاری نسخه‌ی TLS

مرورگرهای مدرن از نسخه‌های قدیمی TLS (مثل TLS 1.0 و 1.1) پشتیبانی نمی‌کنند. اگر سرور شما فقط این نسخه‌های قدیمی را ارائه دهد، کاربران پیام خطا می‌بینند. راه‌حل: فعال‌سازی TLS 1.2 و 1.3 در پیکربندی وب‌سرور. مسیر فنی این کار در بخش تشخیص آمده است.

ریشه‌ی پنجم: پیکربندی نادرست ریدایرکت

اگر ریدایرکت HTTP به HTTPS اشتباه تنظیم شود، ممکن است حلقه‌ی بی‌پایان ریدایرکت ایجاد شود و مرورگر خطای ERR_TOO_MANY_REDIRECTS بدهد. این سناریو معمولاً بعد از نصب افزونه‌ی امنیتی یا فعال‌سازی HTTPS در CDN رخ می‌دهد. مسیر دقیق این خطا در رفع خطای ریدایرکت بی‌نهایت در وردپرس باز شده است.

ریشه‌ی ششم: تداخل CDN با SSL سرور

اگر از Cloudflare یا CDN دیگری استفاده می‌کنید، ممکن است گواهی CDN با گواهی سرور اصلی ناهماهنگ باشد. حالت‌های SSL در Cloudflare (مثل Flexible، Full و Full Strict) هرکدام رفتار متفاوتی دارند. اگر سایت شما روی Full Strict تنظیم شده ولی سرور اصلی گواهی خودامضا داشته باشد، خطای SSL رخ می‌دهد. مباحث مرتبط در نقد و بررسی Cloudflare باز شده است.

ریشه‌ی هفتم: محتوی ترکیبی (Mixed Content)

اگر صفحه‌ی HTTPS شما شامل منابع HTTP باشد (تصاویر، CSS، JS)، مرورگر با پیام ناامنی هشدار می‌دهد. حتی اگر گواهی معتبر باشد، وجود یک منبع HTTP می‌تواند آیکون قفل را نارنجی یا قرمز کند. راه‌حل: بازنویسی تمام URLهای داخلی به HTTPS. مباحث مرتبط در ریدایرکت HTTP به HTTPS باز شده است.

ریشه‌ی هشتم: تنظیمات نادرست وب‌سرور

پیکربندی SSL در Nginx یا Apache نیازمند دقت است. اگر مسیر گواهی، مسیر کلید، یا پروتکل‌های مجاز اشتباه تنظیم شده باشند، وب‌سرور نمی‌تواند اتصال امن برقرار کند. این سناریو معمولاً بعد از مهاجرت سرور یا ویرایش دستی فایل پیکربندی رخ می‌دهد.

پروتکل واکنش سریع در بحران

اگر سایت شما همین حالا خطای SSL می‌دهد و کاربران قادر به ورود نیستند، این پنج حرکت را به همین ترتیب اجرا کنید:

  1. تعیین نوع خطا: سریع مشخص کنید چه پیام خطایی در مرورگر دیده می‌شود. اگر خطای انقضا است، تمدید گواهی سریع‌ترین راه است. اگر خطای زنجیره یا دامنه است، مسیر عیب‌یابی متفاوت است.
  2. بررسی انقضای گواهی: با مرورگر یا ابزار آنلاین، تاریخ انقضای گواهی را چک کنید. اگر منقضی شده، سریعاً تمدید کنید.
  3. تست با openssl: با دستور openssl s_client -connect yourdomain.com:443 -servername yourdomain.com می‌توانید زنجیره‌ی گواهی و پروتکل‌های مجاز را در خط فرمان ببینید.
  4. غیرفعال‌سازی موقت CDN: اگر CDN فعال است، موقتاً آن را غیرفعال کنید و سایت را از سرور اصلی تست کنید. اگر خطا ناپدید شد، ریشه در پیکربندی CDN است.
  5. پایش لاگ وب‌سرور: لاگ وب‌سرور می‌تواند دلیل دقیق رد شدن اتصال SSL را نشان دهد.

نکته‌ی میدانی: در بحران SSL، هیچ‌گاه فایل پیکربندی وب‌سرور را بدون بکاپ تغییر ندهید. اگر تغییر باعث بدتر شدن وضعیت شد، باید بتوانید در چند ثانیه به نسخه‌ی سالم برگردید. در پروژه‌های من، یک نسخه‌ی پشتیبان از فایل پیکربندی همیشه در مسیر /etc/nginx/sites-available/backup/ نگه‌داری می‌شود.

تشخیص دقیق با openssl و ابزارهای سرور

ابزار openssl یکی از دقیق‌ترین ابزارها برای عیب‌یابی SSL در خط فرمان است. سه دستور کلیدی که در پروژه‌ها زیاد از آن‌ها استفاده می‌کنم:

بررسی زنجیره‌ی گواهی

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts

این دستور، کل زنجیره‌ی گواهی را نمایش می‌دهد. در خروجی، باید سه بخش دیده شود: گواهی سایت، گواهی میانی و گواهی ریشه. اگر یکی از این بخش‌ها غایب باشد، زنجیره ناقص است.

بررسی تاریخ انقضا

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

خروجی این دستور، تاریخ شروع و پایان اعتبار گواهی را نشان می‌دهد. اگر تاریخ پایان گذشته باشد، گواهی منقضی شده است.

بررسی نسخه‌های TLS پشتیبانی‌شده

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

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

ابزارهای آنلاین

ابزارهایی مثل SSL Labs یا SSL Checker، تحلیل جامعی از وضعیت SSL سایت ارائه می‌دهند. این ابزارها می‌توانند مشکلاتی که با openssl کمتر دیده می‌شوند (مثل cipher suites ضعیف یا آسیب‌پذیری‌های شناخته‌شده) را نیز نشان دهند.

زنجیره‌ی گواهی و گواهی میانی

زنجیره‌ی گواهی، ساختاری سه‌سطحی دارد که بدون آن، مرورگر نمی‌تواند به گواهی سایت شما اعتماد کند:

  1. گواهی ریشه (Root Certificate): از پیش روی مرورگر کاربر نصب شده و نیازی به نصب روی سرور ندارد.
  2. گواهی میانی (Intermediate Certificate): باید روی سرور شما نصب شود تا زنجیره کامل شود.
  3. گواهی سایت (Server Certificate): همان گواهی‌ای است که برای دامنه‌ی شما صادر شده.

در تجربه‌ی چندساله‌ام، گواهی میانی شایع‌ترین نقطه‌ی فراموش‌شده در نصب SSL است. وقتی گواهی سایت نصب می‌شود ولی گواهی میانی نصب نمی‌شود، مرورگرهای دسکتاپ جدید مشکل را پنهان می‌کنند ولی مرورگرهای موبایل و قدیمی‌تر پیام هشدار نشان می‌دهند. این تفاوت رفتاری، یکی از دلایل سردرگمی در عیب‌یابی است.

نصب زنجیره‌ی کامل در Nginx

در Nginx، گواهی سایت و گواهی میانی باید در یک فایل ترکیب شوند:

ssl_certificate /etc/ssl/certs/yourdomain.com.fullchain.pem;
ssl_certificate_key /etc/ssl/private/yourdomain.com.key;

فایل fullchain.pem باید شامل گواهی سایت و گواهی میانی باشد، به ترتیب از خاص به عام.

نصب زنجیره‌ی کامل در Apache

در Apache، دو فایل جداگانه استفاده می‌شود:

SSLCertificateFile /etc/ssl/certs/yourdomain.com.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain.com.key
SSLCertificateChainFile /etc/ssl/certs/yourdomain.com.ca-bundle

فایل ca-bundle شامل گواهی‌های میانی است. اگر این فایل نصب نشود، زنجیره ناقص می‌ماند.

تمدید گواهی و مشکلات بعد از آن

تمدید گواهی، در ظاهر یک عملیات ساده است، ولی می‌تواند به چند مشکل پنهان منجر شود:

مشکل اول: فراموش شدن تمدید خودکار

در گواهی‌های Let’s Encrypt که رایگان هستند، تمدید خودکار معمولاً هر ۶۰ روز انجام می‌شود. اگر این تمدید خودکار به هر دلیل شکست بخورد (مثلاً تغییر در پیکربندی سرور یا مسدودی پورت 80)، گواهی منقضی می‌شود و کاربران پیام خطا می‌بینند. راه‌حل: پایش هفتگی انقضای گواهی و تست دوره‌ای تمدید.

مشکل دوم: گواهی جدید ولی پیکربندی قدیمی

وقتی گواهی تمدید می‌شود، مسیر فایل‌ها ممکن است تغییر کند. اگر پیکربندی وب‌سرور به‌روز نشود، وب‌سرور گواهی قدیمی را لود می‌کند و خطا ادامه می‌یابد. راه‌حل: بعد از هر تمدید، با openssl وضعیت گواهی فعال را بررسی کنید.

مشکل سوم: کش شدن گواهی قدیمی

مرورگرها گواهی‌ها را کش می‌کنند. اگر کاربر قبلاً سایت شما را با گواهی قدیمی باز کرده باشد، ممکن است همچنان خطای قدیمی را ببیند. راه‌حل: اطلاع‌رسانی به کاربران برای پاک کردن کش یا تست در حالت Incognito.

ریدایرکت HTTP به HTTPS و خطاهای مربوط

ریدایرکت از HTTP به HTTPS، ضروری است ولی اگر اشتباه تنظیم شود، خودش به منبع خطا تبدیل می‌شود:

ریدایرکت در htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

این قاعده باید قبل از قواعد وردپرس قرار گیرد. اگر بعد از قواعد وردپرس قرار گیرد، ممکن است به‌درستی اعمال نشود.

ریدایرکت در Nginx

server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}

خطای حلقه‌ی ریدایرکت

اگر ریدایرکت HTTPS هم در CDN و هم در سرور تنظیم شده باشد ولی با تنظیمات متناقض، حلقه‌ی بی‌پایان ایجاد می‌شود. مرورگر خطای ERR_TOO_MANY_REDIRECTS می‌دهد. راه‌حل: ریدایرکت را فقط در یک لایه (سرور یا CDN) تعریف کنید.

SSL در CDN و پراکسی معکوس

CDNها معمولاً گواهی SSL خودشان را ارائه می‌دهند و می‌توانند به‌عنوان لایه‌ی میانی بین کاربر و سرور شما عمل کنند. این معماری مزایایی دارد، ولی ریشه‌ی خطاهای SSL می‌شود اگر پیکربندی نادرست باشد.

حالت‌های SSL در Cloudflare

Cloudflare چهار حالت SSL ارائه می‌دهد که هر یک رفتار متفاوتی دارند:

  1. Flexible: ارتباط کاربر-Cloudflare رمزنگاری‌شده، ولی Cloudflare-سرور بدون SSL. این حالت امن نیست و معمولاً مشکل محتوی ترکیبی ایجاد می‌کند.
  2. Full: هر دو ارتباط رمزنگاری‌شده، ولی گواهی سرور اصلی بررسی نمی‌شود.
  3. Full Strict: هر دو ارتباط رمزنگاری‌شده و گواهی سرور اصلی نیز بررسی می‌شود. این حالت امن‌ترین است ولی نیازمند گواهی معتبر روی سرور اصلی است.
  4. Origin Pull: شبیه Full Strict ولی با گواهی اختصاصی.

اگر خطای SSL در سایت با CDN مشاهده می‌کنید، اول حالت SSL را در پنل CDN بررسی کنید. تجربه‌ی من نشان داده که در ۷۰ درصد موارد، خطا از تنظیم نادرست همین حالت ناشی می‌شود.

تداخل گواهی CDN با سرور

در حالت Full Strict، اگر گواهی سرور اصلی منقضی یا نامعتبر باشد، CDN نمی‌تواند به سرور وصل شود و خطای ۵۲۶ (Invalid SSL Certificate) نشان می‌دهد. راه‌حل: اطمینان از معتبر بودن گواهی سرور اصلی در همه‌ی زمان‌ها.

محتوی ترکیبی و پیام ناامنی مرورگر

محتوی ترکیبی زمانی رخ می‌دهد که بخشی از منابع صفحه (تصاویر، CSS، JS) با HTTP لود شوند، در حالی که صفحه‌ی اصلی با HTTPS باز شده است. این وضعیت، حتی اگر گواهی معتبر باشد، باعث هشدار مرورگر می‌شود.

تشخیص محتوی ترکیبی

در مرورگر، از ابزار DevTools و تب Console می‌توانید هشدارهای Mixed Content را ببینید. هر منبع HTTP یک هشدار زرد یا قرمز ایجاد می‌کند.

رفع محتوی ترکیبی

سه راه‌حل عملی:

  1. بازنویسی دستی URLها: در محتوای وردپرس، تصاویر و لینک‌های با http:// را به https:// تغییر دهید.
  2. استفاده از افزونه: افزونه‌هایی مثل Really Simple SSL می‌توانند URLها را در دیتابیس بازنویسی کنند.
  3. هدایت با CSP: با تنظیم Content-Security-Policy می‌توانید مرورگر را مجبور کنید که تمام منابع را با HTTPS لود کند.

پایش مستمر و پیشگیری از تکرار خطا

بعد از رفع، مهم‌تر از رفع، پیشگیری است. چهار سطح پایش توصیه می‌کنم:

سطح اول: پایش انقضای گواهی

سرویس‌های پایش می‌توانند انقضای گواهی را به‌صورت خودکار بررسی کنند و هشدار بدهند. این سرویس‌ها معمولاً ۳۰ روز قبل از انقضا هشدار می‌دهند که فرصت کافی برای تمدید است.

سطح دوم: تست دوره‌ای با SSL Labs

ماهی یک‌بار، سایت خود را با ابزار SSL Labs تست کنید. نمره‌ی A یا A+ نشان می‌دهد که پیکربندی SSL شما سالم است. نمره‌ی پایین‌تر نشان می‌دهد که باید پیکربندی را بهبود دهید.

سطح سوم: پایش لاگ‌های وب‌سرور

لاگ‌های وب‌سرور می‌توانند خطاهای SSL را نشان دهند. اگر خطای مکرر در لاگ دیده می‌شود، ریشه را قبل از این‌که به بحران تبدیل شود، پیدا کنید.

سطح چهارم: پایش خارجی

سرویس‌هایی مثل Uptime Robot می‌توانند سایت شما را به‌صورت دوره‌ای با HTTPS بررسی کنند و در صورت خطای SSL، هشدار بدهند.

پرسش‌های پرتکرار درباره خطای SSL سرور

تفاوت SSL و TLS چیست؟

SSL نسخه‌ی اولیه‌ی پروتکل رمزنگاری است که امروز منسوخ شده. TLS نسخه‌ی مدرن و امن این پروتکل است. در زبان عامیانه، هر دو با نام SSL شناخته می‌شوند، ولی از نظر فنی، تمام گواهی‌های امروز از TLS استفاده می‌کنند.

آیا گواهی SSL رایگان به‌اندازه‌ی پولی امن است؟

از نظر فنی، گواهی‌های رایگان مثل Let’s Encrypt همان سطح رمزنگاری گواهی‌های پولی را ارائه می‌دهند. تفاوت اصلی در پشتیبانی و ضمانت است. برای اکثر سایت‌ها، گواهی رایگان کافی است؛ ولی سایت‌های تجاری بزرگ ممکن است به گواهی‌های سازمانی (OV یا EV) نیاز داشته باشند.

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

در بیشتر موارد، ریشه در سه چیز است: زنجیره‌ی ناقص گواهی، عدم تطابق دامنه، یا محتوی ترکیبی. بررسی زنجیره با openssl و بررسی Console مرورگر، سریع‌ترین راه تشخیص است.

آیا خطای SSL روی سئو تأثیر می‌گذارد؟

بله. اگر خطای SSL ادامه داشته باشد، کاربران نمی‌توانند سایت شما را باز کنند و ترافیک ارگانیک به‌شدت افت می‌کند. علاوه بر این، گوگل HTTPS را یکی از سیگنال‌های رتبه‌بندی می‌داند و سایت‌های بدون HTTPS یا با خطای SSL، رتبه‌ی پایین‌تری می‌گیرند.

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

گواهی‌های Let’s Encrypt هر ۹۰ روز منقضی می‌شوند ولی تمدید خودکار هر ۶۰ روز انجام می‌شود. گواهی‌های پولی معمولاً سالیانه هستند. توصیه: همیشه تمدید خودکار را فعال کنید و انقضا را به‌صورت ماهانه پایش کنید.

آیا خطای SSL می‌تواند ناشی از حمله باشد؟

بله، در موارد نادر. حملات MITM (Man in the Middle) می‌توانند باعث خطای SSL شوند. اگر خطای SSL در شرایطی رخ می‌دهد که تنها یک کاربر آن را می‌بیند، احتمال حمله وجود دارد. در این حالت کاربر باید اتصال خود را با ابزارهای امنیتی بررسی کند.

چطور بفهمم خطای SSL از CDN است یا سرور اصلی؟

سریع‌ترین تست، دور زدن CDN است. با دستور curl -I --resolve yourdomain.com:443:server_ip https://yourdomain.com می‌توانید سایت را مستقیم از سرور اصلی تست کنید. اگر مستقیم پاسخ داد ولی از دامنه خطا آمد، ریشه در لایه‌ی CDN است.

تغییر دامنه چه تأثیری بر گواهی SSL دارد؟

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

آیا می‌توانم از چند گواهی SSL برای یک سایت استفاده کنم؟

بله. در سایت‌های چند‌دامنه‌ای، می‌توانید چند گواهی نصب کنید یا از گواهی Wildcard استفاده کنید که تمام زیر‌دامنه‌ها را پوشش می‌دهد. توصیه: برای سایت‌های پیچیده، از گواهی Wildcard یا SAN استفاده کنید.

پروتکل TLS 1.3 چه مزیتی نسبت به TLS 1.2 دارد؟

TLS 1.3 سریع‌تر و امن‌تر از TLS 1.2 است. این نسخه، زمان برقراری اتصال را کاهش می‌دهد و cipher suites ضعیف را حذف کرده. اگر سرور شما از TLS 1.3 پشتیبانی می‌کند، فعال‌سازی آن می‌تواند سرعت HTTPS را تا ۳۰ درصد بهبود دهد.

نکته‌های میدانی از مدیریت بحران SSL

در پایان این مقاله، چند نکته‌ای را می‌گویم که در مستندات رسمی کم‌تر به آن‌ها اشاره می‌شود ولی در پروژه‌های واقعی بارها به کارم آمده:

نخست: تمدید خودکار گواهی را همیشه فعال نگه دارید و هر ماه، انقضای گواهی را به‌صورت دستی بررسی کنید. تجربه‌ی من نشان داده که در نیمی از سایت‌هایی که با خطای SSL مواجه شده‌اند، تمدید خودکار به‌دلیل یک تغییر کوچک در پیکربندی شکست خورده و هیچ‌کس متوجه نشده بود.

دوم: قبل از هر تغییر در پیکربندی SSL، از فایل‌های پیکربندی و از گواهی فعلی بکاپ بگیرید. این عادت ساده می‌تواند در بحران، چند دقیقه وقت شما را نجات دهد.

سوم: اگر سایت شما روی CDN است، SSL را فقط در یک لایه تنظیم کنید. تجربه‌ی من نشان داده که تنظیم متناقض در چند لایه، بیشترین زمان عیب‌یابی را می‌گیرد و در ۹۰ درصد موارد، عامل اصلی خطاهای پیچیده SSL است.

در تجربه‌ی چندساله‌ام روی سرورهای تولیدی، الگویی که بارها تکرار شده این است که خطای SSL تقریباً همیشه در یکی از چهار لایه ریشه دارد: انقضای گواهی، زنجیره‌ی ناقص، ناسازگاری پروتکل، یا پیکربندی نادرست CDN. تشخیص سریع این لایه، از هر راه‌حل آماده مؤثرتر است. اگر ابزارهای تشخیصی را در اختیار داشته باشید و لایه‌ها را به ترتیب بررسی کنید، این خطا از یک بحران ترسناک به یک تمرین روتین تبدیل می‌شود.

اگر روی سرور خود با نوعی از خطای SSL مواجه شده‌اید که در این مقاله پوشش داده نشده، یا اگر راه‌حل متفاوتی پیدا کرده‌اید که به کارتان آمده، برای من جالب است آن را بشنوم. مشخصاً اگر بخشی از خروجی openssl یا پیکربندی که ریشه‌ی واقعی را نشان داد، با خوانندگان دیگر به اشتراک بگذارید؛ این یادداشت‌های دقیق، برای مدیر سرور بعدی ساعت‌ها زمان صرفه‌جویی می‌کنند. 🔐