SSL Wildcard یک گواهی برای پوشش زیر دامنه‌های یک سطح مثل *.example.com است، اما معمولاً برای صدور آن به DNS-01 نیاز دارید.

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

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

این مقاله توضیح می‌دهد چه زمانی Wildcard واقعاً لازم است و چه زمانی گواهی معمولی برای چند دامنه کافی خواهد بود.

بسیاری از کاربران وقتی سایت باز نمی‌شود یا 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. اگر زیر دامنه‌های زیادی دارید یا مرتب زیر دامنه جدید می‌سازید، Wildcard مفید است.
  2. برای Let’s Encrypt Wildcard باید DNS-01 انجام شود؛ یعنی TXT خاص در DNS دامنه ساخته شود.
  3. اگر DNS API دارید، تمدید خودکار را با افزونه مناسب انجام دهید.
  4. بعد از نصب، به یاد داشته باشید Wildcard فقط یک سطح از زیر دامنه را پوشش می‌دهد.

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

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

# صدور دستی Wildcard با Certbot نمونه؛ برای تولید، DNS API بهتر است
sudo certbot certonly --manual --preferred-challenges dns   -d example.com -d '*.example.com'

# بعد از دستور بالا باید TXT زیر را در DNS بسازید؛ مقدار واقعی را Certbot می‌دهد
# _acme-challenge.example.com TXT "TOKEN_FROM_CERTBOT"

# تست رکورد TXT قبل از ادامه
dig _acme-challenge.example.com TXT +short

# بررسی گواهی نهایی
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -text | grep -A2 'Subject Alternative Name'

# تست HTTPS زیر دامنه
curl -I https://blog.example.com

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

اگر 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 است، نه الزاماً خراب بودن تنظیم جدید.

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

  • کاربر فکر می‌کند Wildcard دامنه اصلی را هم همیشه پوشش می‌دهد؛ بهتر است example.com و *.example.com هر دو در SAN باشند.
  • TXT رکورد دیر منتشر شده و validation شکست می‌خورد.
  • تمدید دستی Wildcard فراموش می‌شود و همه زیر دامنه‌ها خطا می‌گیرند.
  • Wildcard برای a.b.example.com کافی نیست چون فقط یک سطح را پوشش می‌دهد.

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

سناریوی اول این است که کاربر تازه دامنه را به هاست یا سرور وصل کرده و انتظار دارد همان لحظه همه‌چیز برای همه کاربران باز شود. در موضوع «SSL Wildcard»، همیشه باید تفاوت بین تغییر واقعی در 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 عمومی هم درست باز می‌شود.

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

Wildcard چه چیزی را پوشش می‌دهد؟

مثلاً *.example.com زیر دامنه‌هایی مثل blog.example.com و shop.example.com را پوشش می‌دهد، اما معمولاً دامنه اصلی example.com را جدا باید اضافه کرد.

چرا برای Wildcard باید DNS-01 بزنیم؟

چون صادرکننده باید مطمئن شود شما کنترل DNS کل دامنه را دارید، نه فقط یک مسیر HTTP روی یک زیر دامنه.

آیا Wildcard از SSL معمولی امن‌تر است؟

نه الزاماً. مزیت اصلی آن مدیریت ساده‌تر زیر دامنه‌های زیاد است.

جمع‌بندی

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