برای رمزنگاری ارتباط، SSL رایگان DV می‌تواند کافی باشد؛ اما تفاوت‌هایی در نوع اعتبارسنجی، پشتیبانی، Wildcard و نیاز سازمانی وجود دارد.

سلام‌سرور این راهنما را با نگاه آموزشی و عیب‌یابی نوشته است؛ هدف مقاله فروش سرویس یا تبلیغ نیست، بلکه کمک به کاربری است که با یک مشکل واقعی در دامنه، DNS، هاست یا SSL روبه‌رو شده و می‌خواهد بداند دقیقاً از کجا شروع کند.

این مقاله دقیقاً چه مشکلی را حل می‌کند؟

این مقاله بدون فروش مستقیم توضیح می‌دهد چه زمانی SSL رایگان کافی است و چه زمانی سازمان یا پروژه به گواهی پولی یا OV/EV نیاز دارد.

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

چک‌لیست سریع قبل از شروع

  • نام دامنه را دقیق و بدون غلط تایپی بررسی کنید؛ نسخه با www و بدون www را جداگانه تست کنید.
  • مشخص کنید DNS فعال دامنه کجاست: رجیسترار، cPanel، DirectAdmin، Cloudflare یا سرور اختصاصی.
  • اگر ایمیل دامنه فعال است، قبل از تغییر DNS از MX و TXTهای SPF/DKIM/DMARC یادداشت بگیرید.
  • اگر سایت فروشگاهی یا پرترافیک است، تغییرات را در زمان کم‌ترافیک انجام دهید و بکاپ داشته باشید.

مفاهیم پایه‌ای که باید بدانید

DNS دفترچه راهنمای اینترنت برای تبدیل نام دامنه به مقصد فنی است. وقتی کاربر example.com را وارد می‌کند، مرورگر باید بفهمد این نام به کدام IP یا کدام سرویس اشاره می‌کند. SSL هم لایه اعتماد و رمزنگاری روی این ارتباط است؛ بنابراین اگر DNS اشتباه باشد، SSL هم معمولاً نمی‌تواند درست صادر یا استفاده شود.

Nameserver مشخص می‌کند مدیریت DNS دامنه در کدام سرویس انجام می‌شود. رکوردهای DNS داخل همان سرویس نگهداری می‌شوند. رکورد A معمولاً دامنه را به IPv4 وصل می‌کند، AAAA به IPv6، CNAME یک نام را به نام دیگر، MX مسیر ایمیل، TXT اطلاعات متنی و تأییدیه‌ها، و NS محل مدیریت DNS را مشخص می‌کند.

مراحل پیشنهادی انجام کار

  1. نیاز خود را مشخص کنید: فقط HTTPS یا اعتبار سازمانی و پشتیبانی رسمی؟
  2. بررسی کنید پنل شما AutoSSL یا Let’s Encrypt دارد یا نه.
  3. برای زیر دامنه‌های زیاد، به Wildcard و روش DNS-01 فکر کنید.
  4. تمدید خودکار را تست کنید؛ SSL رایگان اگر تمدید نشود همان‌قدر خطرناک است که SSL پولی منقضی‌شده.

دستورهای SSH و ترمینال برای بررسی دقیق

در دستورهای زیر به‌جای example.com دامنه خودتان را قرار دهید. اگر دسترسی SSH ندارید، بخش زیادی از همین تست‌ها را می‌توانید با ابزارهای آنلاین DNS یا ترمینال ویندوز انجام دهید؛ اما روی سرور لینوکس، dig و curl دقیق‌ترین تصویر را می‌دهند.

# بررسی نوع و تاریخ گواهی
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

# بررسی زنجیره گواهی با curl
curl -Iv https://example.com 2>&1 | grep -E 'issuer|subject|SSL certificate|expire|start date'

# بررسی تمدید certbot در سرورهایی که خودتان مدیریت می‌کنید
sudo certbot certificates
sudo certbot renew --dry-run

چطور نتیجه دستورها را تفسیر کنیم؟

اگر dig برای دامنه IP برگرداند، یعنی حداقل بخشی از DNS کار می‌کند. اگر curl روی HTTP یا HTTPS خطای 301، 302، 403، 404، 500 یا timeout نشان دهد، دیگر فقط با DNS طرف نیستیم و باید وب‌سرور، فایروال، SSL یا برنامه سایت را بررسی کنیم. اگر openssl گواهی دامنه دیگری را نشان دهد، یعنی SNI یا virtual host اشتباه تنظیم شده است.

در عیب‌یابی حرفه‌ای، مهم است پاسخ‌ها را از چند نقطه مقایسه کنید. ممکن است 1.1.1.1 پاسخ جدید را نشان دهد اما 8.8.8.8 یا اینترنت یک کاربر هنوز پاسخ قدیمی را داشته باشد. این وضعیت معمولاً نشانه کش و TTL است، نه الزاماً خراب بودن تنظیم جدید.

خطاها و چالش‌های رایج کاربران

  • کاربر فکر می‌کند SSL پولی سرعت سایت را بیشتر می‌کند؛ در بیشتر موارد تفاوت اصلی نوع اعتبارسنجی و خدمات است.
  • SSL رایگان نصب شده اما تمدید خودکار خراب است.
  • گواهی Wildcard لازم است اما روش HTTP-01 انتخاب شده که برای Wildcard کافی نیست.
  • نام دامنه در گواهی با دامنه‌ای که کاربر باز می‌کند یکی نیست.

سناریوهای واقعی که معمولاً رخ می‌دهد

سناریوی اول این است که کاربر تازه دامنه را به هاست یا سرور وصل کرده و انتظار دارد همان لحظه همه‌چیز برای همه کاربران باز شود. در موضوع «SSL رایگان و پولی»، همیشه باید تفاوت بین تغییر واقعی در authoritative DNS و دیده شدن آن تغییر در کش کاربران را در نظر گرفت. اگر پاسخ authoritative درست باشد اما بخشی از کاربران هنوز خطا می‌بینند، نباید تنظیمات را چند بار پشت‌سرهم عوض کرد؛ این کار فقط زمان عیب‌یابی را طولانی‌تر می‌کند.

سناریوی دوم مربوط به جابه‌جایی سایت است. مدیر سایت IP یا Nameserver را تغییر می‌دهد اما رکوردهای ایمیل، زیر دامنه، CDN یا SSL را منتقل نمی‌کند. نتیجه این می‌شود که صفحه اصلی باز می‌شود ولی ایمیل قطع است، www خطا می‌دهد یا پنل مدیریت از آدرس قدیمی لود می‌شود. قبل از هر مهاجرت، باید یک فهرست از رکوردهای DNS و سرویس‌های وابسته تهیه شود.

سناریوی سوم زمانی اتفاق می‌افتد که مشکل در مرورگر دیده می‌شود اما ریشه آن در DNS یا SSL نیست. مثلاً کش افزونه وردپرس، کش LiteSpeed، تنظیمات Cloudflare، ریدایرکت قدیمی 301 یا حتی DNS مودم می‌تواند نتیجه تست را گمراه کند. برای همین در مقاله‌های فنی همیشه توصیه می‌شود تست نهایی با ابزارهایی مثل dig، curl و openssl انجام شود، نه فقط با یک مرورگر روی یک اینترنت.

سناریوی چهارم برای کاربران هاست اشتراکی است. این کاربران معمولاً دسترسی root ندارند و نمی‌توانند سرویس DNS یا وب‌سرور را reload کنند؛ اما باز هم می‌توانند با تست‌های ساده بفهمند مشکل از تنظیمات خودشان است یا باید از پشتیبانی هاست بخواهند رکورد، SSL، Feature Manager، AutoSSL، لاگ وب‌سرور یا محدودیت فایروال را بررسی کند.

برای کاربر هاست اشتراکی و مدیر سرور چه فرقی دارد؟

اگر فقط کاربر هاست اشتراکی هستید، معمولاً باید از پنل‌هایی مثل cPanel یا DirectAdmin تغییر را انجام دهید و خروجی تست‌ها را برای پشتیبانی ارسال کنید. در این حالت، دستورهای SSH بیشتر برای فهمیدن مسئله و مکاتبه دقیق‌تر با پشتیبانی مفید است. اما اگر مدیر سرور هستید، علاوه بر DNS باید سرویس‌هایی مثل named، PowerDNS، Nginx، Apache، فایروال، cron تمدید SSL و لاگ‌های سیستم را هم بررسی کنید.

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

روش عیب‌یابی مرحله‌به‌مرحله

  1. اول DNS را جدا تست کنید؛ اگر دامنه IP نمی‌دهد، هنوز سراغ SSL یا وردپرس نروید.
  2. بعد اتصال به سرور را تست کنید؛ اگر IP درست است اما سایت باز نمی‌شود، فایروال، وب‌سرور و virtual host را بررسی کنید.
  3. بعد SSL را تست کنید؛ اگر گواهی نامعتبر است، دامنه‌های داخل گواهی، تاریخ انقضا و زنجیره را ببینید.
  4. در پایان کش‌ها را پاک کنید؛ کش مرورگر، کش DNS سیستم، کش افزونه وردپرس، کش LiteSpeed یا CDN ممکن است نتیجه تست را اشتباه نشان دهد.

نکات امنیتی و عملی مهم

قبل از هر تغییر مهم، از تنظیمات فعلی خود یادداشت بگیرید یا اسکرین‌شات بگیرید. در DNS و SSL، یک تغییر کوچک مثل حذف رکورد MX یا فعال‌سازی ریدایرکت در دو جای مختلف می‌تواند باعث قطع سایت، ایمیل یا ایجاد خطاهای مرورگر شود.

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

چک‌لیست نهایی بعد از انجام کار

  • دامنه اصلی و www هر دو تست شده‌اند.
  • رکوردهای ایمیل مثل MX و TXT حذف یا خراب نشده‌اند.
  • HTTP به HTTPS فقط از یک مسیر اصلی ریدایرکت می‌شود و loop وجود ندارد.
  • گواهی SSL برای همه نام‌های لازم صادر شده و منقضی نیست.
  • سایت از اینترنت دیگر یا DNS عمومی هم درست باز می‌شود.

سوالات متداول

آیا SSL رایگان امنیت رمزنگاری کمتری دارد؟

در حالت استاندارد، رمزنگاری TLS به تنظیمات سرور و مرورگر وابسته است، نه صرفاً رایگان یا پولی بودن گواهی.

OV و EV چه فرقی با DV دارند؟

DV فقط مالکیت دامنه را تأیید می‌کند؛ OV و EV اطلاعات سازمانی را هم اعتبارسنجی می‌کنند.

برای سایت فروشگاهی SSL رایگان کافی است؟

از نظر رمزنگاری می‌تواند کافی باشد، اما برای نیازهای سازمانی، قراردادها یا اعتماد رسمی ممکن است گواهی سازمانی ترجیح داده شود.

جمع‌بندی

موضوع «SSL رایگان و SSL پولی چه تفاوتی دارند؟» زمانی واقعاً درست حل می‌شود که آن را به چند لایه جدا تقسیم کنیم: دامنه، Nameserver، رکوردهای DNS، پاسخ سرور، SSL، ریدایرکت و کش. اگر این ترتیب را رعایت کنید، به‌جای آزمون‌وخطای خطرناک، با چند تست ساده می‌توانید محل دقیق مشکل را پیدا کنید و فقط همان بخش را اصلاح کنید.