مدتی پیش، روی پروژه‌ای که چند ده ساب‌دامین داشت — از shop و blog تا admin و status — کار می‌کردم. تیم قبلی برای هر ساب‌دامین یک گواهی جدا خریده بود و سررسیدهای مختلف، هر ماه یک بحران کوچک می‌ساخت. پیشنهاد دادم یک Wildcard SSL بگیریم و کار تمام است. وقتی توضیح دادم که یک Wildcard نه‌فقط همه‌ی ساب‌دامین‌ها را پوشش می‌دهد، بلکه سررسید یکتا هم دارد، تصویر پروژه یک‌باره روشن‌تر شد. اما Wildcard هم مثل هر ابزار دیگری، جای خاص خودش را دارد و در برخی موارد انتخاب نادرستی است.

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

Wildcard SSL دقیقاً چیست و چه چیزی را پوشش می‌دهد؟

Wildcard SSL یک گواهی SSL (Secure Sockets Layer) است که به‌جای یک نام میزبان مشخص، یک الگو را پوشش می‌دهد. اگر گواهی برای *.example.com صادر شده باشد، این گواهی می‌تواند تمام ساب‌دامین‌های سطح اول دامنه را امن کند:

  • shop.example.com
  • blog.example.com
  • api.example.com
  • admin.example.com
  • status.example.com

اما مهم است بدانید که Wildcard فقط یک سطح را پوشش می‌دهد. اگر دامنه‌ی شما shop.us.example.com باشد، گواهی *.example.com آن را پوشش نمی‌دهد؛ برای پوشش آن باید *.us.example.com داشته باشید. همچنین دامنه‌ی اصلی example.com بدون ساب‌دامین، توسط Wildcard پوشش داده نمی‌شود و باید در SAN (Subject Alternative Name) گواهی ذکر شود.

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

Wildcard یعنی یک گواهی برای همه‌ی درهای خانه. اگر خانه‌ی شما یک ساختمان با ده‌ها در است، Wildcard همان چیزی است که نبودش باعث می‌شود پشت هر در یک کلید جدا بسازید.

مکانیزم فنی: چرا یک ستاره می‌تواند همه ساب‌دامین‌ها را پوشش دهد؟

در لایه‌ی فنی، Wildcard در فیلد Subject Alternative Name گواهی به‌صورت *.example.com ثبت می‌شود. استاندارد X.509 تعریف کرده که یک گواهی می‌تواند الگوی Wildcard داشته باشد، به‌شرط آن‌که ستاره فقط در سمت چپ‌ترین برچسب دامنه قرار بگیرد (یعنی *.example.com معتبر است، اما shop.*.com یا *.*.example.com نه).

مرورگر هنگام اتصال، نام میزبان را با SAN مقایسه می‌کند. اگر نام میزبان با الگو مطابقت داشت، گواهی معتبر شمرده می‌شود. این یعنی صادرکننده‌ی گواهی باید بتواند مالکیت دامنه‌ی والد را تأیید کند — که معمولاً با یکی از سه روش Validation انجام می‌شود: Domain Validation (DV)، Organization Validation (OV) یا Extended Validation (EV).

این نکته را هم در نظر بگیرید که مکانیزم Wildcard، به‌طور پیش‌فرض به ساب‌دامین‌های سطح اول محدود است. اگر روی زیرساخت DNS خود از طریق Wildcard DNS Record یا CNAME wildcard استفاده می‌کنید، مفهوم متفاوتی است؛ این موضوع را در تفاوت دامنه و ساب‌دامین چیست تحلیل کرده‌ام.

Wildcard در برابر SAN: کدام یک را انتخاب کنیم؟

اگر روی تعداد محدودی نام میزبان مشخص کار می‌کنید، SAN (Subject Alternative Name) اغلب انتخاب اقتصادی‌تری است. اما اگر ساب‌دامین‌ها زیاد و متغیر هستند، Wildcard برنده است. جدول زیر تفاوت‌های کلیدی را نشان می‌دهد:

معیارWildcard SSLSAN SSL
تعداد نام میزبانبی‌نهایت (سطح اول)محدود به لیست صریح
هزینهبالاتر، اما برای چند ساب‌دامین ارزان‌تر تمام می‌شودپایه ارزان‌تر، با افزایش هزینه برای هر نام اضافی
انعطاف در ساب‌دامین جدیدآنی و بدون اقدام اضافینیازمند صدور مجدد
پوشش دامنه اصلینیاز به ذکر جداگانه در SANبله، در SAN ذکر می‌شود
پوشش سطوح چندگانهفقط یک سطحبله (multi-level SAN)

در دنیای عملی، ترکیب Wildcard و SAN هم رایج است: یک گواهی که هم *.example.com را پوشش می‌دهد و هم example.com و *.dev.example.com. این ترکیب، انعطاف Wildcard را با پوشش دامنه‌ی اصلی و زیر‌دامنه‌های خاص ترکیب می‌کند.

چه زمانی Wildcard انتخاب درستی است؟

بر اساس تجربه‌ی پروژه‌ها، Wildcard در این سناریوها انتخاب درستی است:

  • چند ده ساب‌دامین پویا: سیستم‌هایی که به‌ازای هر مشتری یا هر تیم یک ساب‌دامین می‌سازند، بدون Wildcard هر ساب‌دامین جدید یعنی فرآیند صدور گواهی تازه.
  • محیط‌های چندگانه‌ی پروژه: اگر برای هر محیط (dev، staging، demo) یک ساب‌دامین دارید، یک Wildcard تمام سناریو را پوشش می‌دهد.
  • تیم فنی که می‌خواهد مدیریت گواهی را ساده کند: یک گواهی با یک سررسید، به‌جای چند گواهی با چند سررسید.
  • زیرساخت SaaS چندمستأجری (Multi-tenant): که به‌طور ذاتی روی ساب‌دامین‌های پویا ساخته می‌شود.
  • پروژه‌های تک‌ساب‌دامینی در حال رشد: اگر می‌دانید در سال آینده دو یا سه ساب‌دامین اضافه خواهید کرد، Wildcard از همان امروز سرراست‌تر است.

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

چه زمانی Wildcard انتخاب اشتباهی است؟

در این سناریوها، Wildcard بیشتر هزینه و ریسک می‌آورد تا فایده:

  • سایت تک‌دامینی بدون برنامه برای ساب‌دامین: اگر فقط example.com و www.example.com دارید، یک گواهی SAN یا حتی Let's Encrypt رایگان کافی است.
  • پروژه با ساب‌دامین‌های چندسطحی: مثل api.staging.example.com. Wildcard این‌ها را پوشش نمی‌دهد و باید از ترکیب استفاده کنید.
  • نیاز امنیتی بالا به جداسازی: در برخی سازمان‌ها، سیاست امنیتی اجازه نمی‌دهد یک کلید خصوصی برای همه‌ی ساب‌دامین‌ها استفاده شود. چون در Wildcard، کلید خصوصی واحد است و در همه‌ی سرورهای ساب‌دامین قرار می‌گیرد.
  • پوشش فقط یک بخش از ساب‌دامین‌ها: اگر فقط دو یا سه ساب‌دامین دارید و بقیه هرگز گواهی نمی‌خواهند، Wildcard بی‌دلیل هزینه‌ی بیشتر می‌آورد.
  • استفاده از ACME اتوماتیک با Let's Encrypt: در این حالت، صدور خودکار گواهی برای هر ساب‌دامین به‌طور خودکار انجام می‌شود و نیاز به Wildcard کمتر می‌شود.
Wildcard را نه به‌خاطر زیبایی و نه به‌خاطر ترس از ساب‌دامین‌های آینده نخرید؛ وقتی بخرید که تعداد ساب‌دامین‌های امروزی شما آن را توجیه کند.

محدودیت‌های فنی Wildcard SSL

Wildcard چند محدودیت فنی دارد که بی‌توجهی به آن‌ها می‌تواند شما را غافلگیر کند:

  1. سطح واحد: همان‌طور که اشاره کردیم، Wildcard فقط یک سطح ساب‌دامین را پوشش می‌دهد. پوشش چند سطح، نیازمند صدور گواهی جداگانه یا ترکیب SAN است.
  2. پوشش دامنه‌ی اصلی: دامنه‌ی اصلی (example.com) بدون ساب‌دامین، پوشش داده نمی‌شود مگر آن‌که در SAN ذکر شود.
  3. کلید خصوصی مشترک: کلید خصوصی Wildcard در همه‌ی سرورهایی که این گواهی را نصب می‌کنند، وجود دارد. اگر یکی از سرورها کامپرامایز شود، امنیت همه‌ی ساب‌دامین‌ها در معرض خطر است.
  4. پشتیبانی محدودتر در برخی سیستم‌ها: برخی ابزارها یا کتابخانه‌های قدیمی در پردازش Wildcard مشکل دارند.
  5. محدودیت در اعتبارسنجی EV: گواهی‌های Wildcard معمولاً در سطح DV یا OV صادر می‌شوند و امکان EV (که نشان سبز سازمانی می‌دهد) وجود ندارد. برای بیشتر پروژه‌ها این محدودیت مهم نیست، اما در برخی سازمان‌ها هست.

این محدودیت‌ها نباید باعث ترس شوند، اما باید بخشی از تصمیم شما باشند. اگر بعد از این تصمیم، دامنه‌ی جدیدی به پروژه اضافه شد و می‌خواهید Wildcard دیگری بگیرید، پیش از خرید، دامنه چیست و چگونه ثبت می‌شود را برای درک ساختار دامنه مرور کنید.

نکات نصب و مدیریت Wildcard

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

  • پراکندگی کلید خصوصی: هر سرور یک کپی از کلید خصوصی دارد. اگر یکی از سرورها کامپرامایز شود، همه‌ی ساب‌دامین‌ها در معرض خطرند. برای کاهش ریسک، از HSM یا سرویس‌های مدیریت کلید استفاده کنید.
  • مدیریت متمرکز انقضا: مزیت Wildcard این است که یک سررسید دارد. این سررسید را در تقویم تیم با هشدار دو ماه قبل ثبت کنید. برای مدیریت بهتر، چگونه اعتبار SSL را بررسی کنیم روش‌های عملی را نشان می‌دهد.
  • ریدایرکت HTTP به HTTPS روی همه‌ی ساب‌دامین‌ها: پس از نصب Wildcard، باید هر ساب‌دامین ریدایرکت درست داشته باشد. راهنمای کامل در ریدایرکت HTTP به HTTPS چگونه انجام می‌شود آمده است.
  • پایش HSTS: اگر از HSTS استفاده می‌کنید، دقت کنید که همه‌ی ساب‌دامین‌ها گواهی معتبر داشته باشند؛ در غیر این صورت، کاربران به دام می‌افتند.
  • پشتیبانی CDN: بعضی CDNها Wildcard را ساده‌تر پشتیبانی می‌کنند و بعضی دیگر نیاز به تنظیمات اضافه دارند. پیش از انتخاب CDN، پشتیبانی از Wildcard را بررسی کنید.

در پروژه‌های فروشگاهی، انتخاب Wildcard مزیت مدیریتی بزرگی است چون همه‌ی زیرسرویس‌ها (پرداخت، پشتیبانی، API) یک سررسید دارند. این جنبه را در SSL برای فروشگاه اینترنتی چه اهمیتی دارد باز کرده‌ام.

پرسش‌های پرتکرار درباره Wildcard SSL

Wildcard SSL روی دامنه اصلی هم کار می‌کند؟ نه، Wildcard فقط ساب‌دامین‌ها را پوشش می‌دهد. برای دامنه‌ی اصلی (example.com) باید آن را در SAN گواهی ذکر کنید یا از یک گواهی جداگانه استفاده کنید.

Wildcard چند سطح ساب‌دامین را پوشش می‌دهد؟ فقط یک سطح. *.example.com شامل shop.example.com است، اما شامل shop.us.example.com نیست. برای سطوح چندگانه، Wildcard جداگانه یا SAN چندسطحی لازم است.

آیا Wildcard برای سایت‌های کوچک ارزش دارد؟ برای سایت‌های تک‌دامینی، معمولاً نه. Wildcard بیشتر برای پروژه‌هایی که چند ساب‌دامین دارند یا به‌سرعت اضافه می‌کنند، توجیه‌پذیر است. برای بقیه، گواهی‌های رایگان Let's Encrypt انتخاب اقتصادی‌تری هستند.

تفاوت Wildcard و Multi-Domain چیست؟ Wildcard روی ساب‌دامین‌های یک دامنه کار می‌کند؛ Multi-Domain (یا SAN) روی چند دامنه‌ی متفاوت. گاهی Wildcard با SAN ترکیب می‌شود تا هم ساب‌دامین‌های یک دامنه و هم چند دامنه‌ی متفاوت پوشش داده شوند.

اگر یکی از ساب‌دامین‌ها هک شد، Wildcard چه ریسکی می‌سازد؟ کلید خصوصی Wildcard در همه‌ی سرورهای ساب‌دامین وجود دارد. اگر یکی از سرورها کامپرامایز شود، مهاجم می‌تواند خود را برای هر ساب‌دامین جا بزند. بنابراین Wildcard نیازمند سیاست امنیتی سخت‌گیرانه‌تر است.

آیا Wildcard روی SEO هم اثر دارد؟ Wildcard به‌تنهایی روی سئو اثر ندارد؛ آنچه روی سئو اثر دارد وجود HTTPS معتبر است. برای درک این اثر، HTTPS چه تاثیری بر سئو و رتبه Google دارد را ببینید.

چرا نصب Wildcard روی CDN بعضی وقت‌ها سخت است؟ بعضی CDNها کلید خصوصی شما را نمی‌پذیرند و خودشان یک گواهی مدیریت‌شده ارائه می‌دهند که معمولاً Wildcard نیست. اگر Wildcard برایتان حیاتی است، CDN مناسب را بر اساس پشتیبانی Wildcard انتخاب کنید. برای انتخاب CDN، مقایسه سرویس‌های CDN راهنمای خوبی است.

چک‌لیست تصمیم: Wildcard بخریم یا نه؟

قبل از خرید Wildcard، این پنج سوال را از خودتان بپرسید. اگر پاسخ اکثر سوال‌ها مثبت است، Wildcard انتخاب درستی است:

  1. آیا هم‌اکنون سه ساب‌دامین یا بیشتر دارید؟
  2. آیا پیش‌بینی می‌کنید در سال آینده ساب‌دامین‌های بیشتری اضافه شوند؟
  3. آیا مدیریت گواهی‌های جداگانه برای شما یک درد عملیاتی است؟
  4. آیا سیاست امنیتی شما با کلید خصوصی مشترک در چند سرور سازگار است؟
  5. آیا هزینه‌ی سالانه‌ی Wildcard، از هزینه‌ی مجموع چند گواهی کمتر یا قابل‌قبول است؟

اگر پاسخ یکی از سوال‌های ۱ تا ۳ منفی است، احتمالاً یک گواهی SAN یا حتی Let's Encrypt کافی است. اگر پاسخ سوال ۴ منفی است، پیش از خرید Wildcard، سیاست امنیتی سازمان را بازنگری کنید. اگر پاسخ سوال ۵ منفی است، ترکیب چند گواهی SAN انتخاب اقتصادی‌تری است.

در نهایت، Wildcard ابزار قدرتمندی است که اگر جای درست خودش بنشیند، مدیریت گواهی را ساده می‌کند و از بحران‌های سررسید جلوگیری می‌کند. اگر جای اشتباه بنشیند، هزینه و ریسک اضافه می‌آورد. این تصمیم، مثل انتخاب بین VPS و هاست اشتراکی — که در VPS چیست و چه تفاوتی با هاست اشتراکی دارد مقایسه کرده‌ام — بر اساس سناریوی واقعی شما گرفته می‌شود، نه بر اساس پیشنهاد فروشنده.

اگر تجربه‌ای از تصمیم Wildcard یا حتی پشیمانی از خرید آن دارید، در دیدگاه‌ها بنویسید. جزئیات سناریوی شما می‌تواند برای تیم‌های فنی دیگر که در همین تصمیم گیر افتاده‌اند، راهگشا باشد. 🔐