Wildcard SSL و SAN؛ پوشش دقیق نام دامنه

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

پس انتخاب واقعی همیشه «Wildcard یا SAN» به‌عنوان دو چیز کاملاً جدا نیست. ابتدا فهرست نام‌های لازم را بنویسید و بعد ببینید هر نام با چه ورودیِ گواهی پوشش می‌گیرد. این راهنما پوشش نام را بررسی می‌کند؛ نصب، صدور عملیاتی یا خرید گواهی انجام نمی‌دهد. تعریف عمومی را در راهنمای گواهی SSL ببینید.

۱. SAN و Wildcard چه نقشی دارند؟

Subject Alternative Name یا SAN بخشی از گواهی است که شناسه‌های مجاز در آن ثبت می‌شوند. برای HTTPSِ نام دامنه، ورودی‌های DNS آن اهمیت دارند. Wildcard شکل خاصی از یک نام، مانند *.example.com است؛ جایگزینی برای خودِ سازوکار SAN نیست.

طبق قاعدهٔ تطبیق نام در RFC ۹۵۲۵، ستارهٔ گواهی در الگوی معتبر، یک برچسب کاملِ سمت چپ را می‌پوشاند. مثال‌ها را بر اساس همین قاعده بخوانید؛ رفتار Wildcard در گواهی TLS را با Wildcard در DNS یکی نگیرید.

نام درخواست‌شده	فقط *.example.com
`shop.example.com`	از نظر نام پوشش دارد.
`www.example.com`	از نظر نام پوشش دارد.
`example.com`	پوشش ندارد؛ نام ریشه جدا لازم است.
`api.shop.example.com`	پوشش ندارد؛ دو سطح پایین‌تر است.
`example.net`	پوشش ندارد؛ دامنهٔ دیگری است.

«پوشش از نظر نام» فقط یک شرط است؛ زنجیرهٔ اعتماد، تاریخ اعتبار و تنظیم درست سرویس هم باید برقرار باشند. داشتن نام مناسب داخل فایل گواهی، نصب‌بودن آن روی مقصد واقعیِ کاربر را ثابت نمی‌کند.

۲. از روی نیاز واقعی، فهرست نام بسازید

برای یک فروشگاه فرضی، نام اصلی، www، فروشگاه، API و پنل داخلی را جدا بنویسید. مشخص کنید کدام نام عمومی است، کجا TLS خاتمه می‌یابد و چه کسی گواهی آن مسیر را نگه می‌دارد. نامی را صرف احتمالِ استفاده در آینده وارد یک گواهی مشترک نکنید؛ این کار مرز مسئولیت‌ها را مبهم می‌کند.

نیاز نمونه	پوشش قابل بررسی
ریشه و www فقط	دو ورودی دقیق `example.com` و `www.example.com`.
ریشه و چند زیردامنهٔ سطح اولِ متغیر	ورودی دقیق ریشه همراه `*.example.com`، اگر سیاست سرویس اجازه دهد.
API زیرِ shop	ورودی دقیق `api.shop.example.com` یا الگوی مناسبِ جدا مانند `*.shop.example.com`.
چند دامنهٔ مستقل	ورودی‌های لازمِ هر دامنه؛ یک ستاره برای example.com دامنه‌های دیگر را پوشش نمی‌دهد.

این جدول مثال مفهومی است، نه پیشنهاد یکسان برای همهٔ سایت‌ها. اگر فقط دو نام ثابت دارید، گواهی چندنامیِ دقیق می‌تواند کافی باشد؛ اگر زیردامنه‌ها زیاد و متغیرند، Wildcard ممکن است مدیریت را ساده کند، اما باید پیامد نگهداری کلید و تمدیدش هم بررسی شود.

۳. صدور Wildcard با ساخت رکورد Wildcard فرق دارد

رکوردی مثل *.example.com در DNS مسیر نام‌ها را تعریف می‌کند؛ گواهی Wildcard اعتبار TLS را. ایجاد یکی، دیگری را ایجاد نمی‌کند. ممکن است DNS نام را به مقصد درست برساند ولی گواهی آن را نپوشاند، یا گواهی مناسب باشد اما نام اصلاً پاسخ DNS نداشته باشد.

در روش‌های اعتبارسنجی Let’s Encrypt، صدور Wildcard با روش DNS-۰۱ پشتیبانی می‌شود؛ HTTP-۰۱ برای Wildcard نیست. این قاعدهٔ همان صادرکننده است، نه وعدهٔ وجود گزینهٔ آماده در همهٔ پنل‌ها. مجوز API دامنه را هم صرفاً برای آزمایش به ابزار ناشناخته ندهید.

اگر درخواست صدور با CAA رد می‌شود، نوع درخواست اهمیت دارد؛ راهنمای issue و issuewild در خطای CAA این تمایز را توضیح می‌دهد. پوشش نام و مجازبودن صادرکننده دو بررسی جدا هستند.

۴. پوشش را در گواهی واقعی ببینید

نام دقیقِ مورد استفادهٔ کاربر را ثبت کنید؛ مسیر URL جای نام گواهی نیست.
در جزئیات گواهی، فهرست Subject Alternative Name را بخوانید؛ تنها عنوان یا Common Name را ملاک قرار ندهید.
هر نام موردنیاز را با جدول پوشش تطبیق دهید؛ ریشه، سطح اول و سطح دوم جدا باشند.
مطمئن شوید همان گواهی در اتصال واقعی تحویل داده می‌شود؛ فهرست فایل‌های پنل به‌تنهایی کافی نیست.

فهرست واقعی گواهی‌های ذخیره‌شده در سی‌پنل با ستون Domains و Expiration UTC؛ نام‌ها و توضیحات خصوصی بلور شده‌اند — عکس واقعی Certificates on Server؛ فهرست ذخیره‌شده با گواهی تحویلیِ اتصال عمومی یکی نیست. نام‌ها و توضیحات خصوصی بلور شده؛ هیچ Edit، Install یا Delete اجرا نشده است.

در رابط واقعیِ سی‌پنل، تب Certificates ستون Domains، صادرکننده و تاریخ انقضا را نشان می‌دهد؛ نام‌های خصوصی تصویر بلور شده‌اند. این عکس محل فهرست را نشان می‌دهد و نمونهٔ اثبات‌شدهٔ گواهی Wildcard نیست. جزئیات مسیرهای مشاهدهٔ گواهی در مستند SSL/TLS سی‌پنل آمده است.

در یک اتصال عمومیِ جدا به example.com با اعتبارسنجی پیش‌فرض TLS، نام‌های example.com و *.example.com در SAN مشاهده شدند. این یک نمونهٔ واقعی از حضور هم‌زمان نام دقیق و ستاره در یک گواهی است؛ ثابت نمی‌کند که هر سرویس یا هر Wildcard، ریشه را خودکار اضافه می‌کند. محتوای گواهیِ سرویس عمومی ممکن است بعداً تغییر کند.

۵. مدیریت مشترک را با پوشش مشترک اشتباه نگیرید

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

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

۶. چک‌لیست پیش از سفارش یا تغییر

فهرست نام‌ها، ریشه و www مشخص است و هرکدام به یک ورودی معتبر نگاشت شده‌اند.
نام سطح دوم به اشتباه زیرِ ستارهٔ سطح اول حساب نشده است.
روش اعتبارسنجی صادرکننده و دسترسی مجاز DNS مشخص است.
محل TLS در هاست و در صورت وجود CDN جدا ثبت شده است.
مسئول نگهداری، محل نصب و تاریخ بازبینی مشخص‌اند؛ کلید خصوصی در گزارش یا تیکت عمومی قرار نمی‌گیرد.

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