SSL Checker چیست؟ آموزش بررسی گواهی SSL سایت
SSL Checker وضعیت گواهی SSL/TLS یک دامنه را بررسی میکند. ابزار به سرور مقصد وصل میشود، TLS Handshake را انجام میدهد و اعتبار گواهی، تاریخ انقضا، مرجع صادرکننده، دامنههای تحت پوشش، زنجیره اعتماد، نسخه پروتکل و Cipher اتصال را نشان میدهد. اصطلاح SSL هنوز رایج است، اما وبسایتهای امروزی برای HTTPS عملاً از TLS استفاده میکنند و SSL به نسخههای قدیمی همان فناوری اشاره دارد.
ابزار SSL Checker آسیاتکین این بررسی را با یک اتصال واقعی به پورت ۴۴۳ یا پورت انتخابی شما انجام میدهد. یعنی اطلاعات از گواهی فعال روی سرور استخراج میشود، نه از جستوجو در یک پایگاه داده که ممکن است قدیمی باشد.
گواهی SSL چگونه از ارتباط سایت محافظت میکند؟
وقتی کاربر یک نشانی HTTPS را باز میکند، مرورگر به سرور وصل میشود و گواهی دیجیتالش را میگیرد. این گواهی کلید عمومی سرور را به هویت دامنه گره میزند و مرورگر بعد از آن تاریخ اعتبار، نام دامنه و امضای مرجع صادرکننده را میسنجد.
طبق راهنمای بررسی گواهی وبسایت در Mozilla، زنجیره اعتماد از گواهی سرور، یک یا چند گواهی واسط و گواهی ریشه ساخته میشود. اگر این زنجیره ناقص باشد یا مرجع صادرکننده در فهرست مراجع مورد اعتماد مرورگر نباشد، کاربر هشدار امنیتی میبیند.
نکتهای که زیاد اشتباه فهمیده میشود: خود گواهی دادهها را رمزنگاری نمیکند. کارش فراهمکردن اطلاعات لازم برای احراز هویت سرور و ساخت کلیدهای امن در فرایند TLS است، و رمزنگاری واقعی پس از تکمیل Handshake روی کانالی که همان فرایند ساخته انجام میشود.
کاربردهای SSL Checker برای مدیران سایت
این ابزار در چند لحظه مشخص به کار میآید: پیش از انتشار سایت، پس از نصب یا تمدید گواهی، هنگام انتقال دامنه به سرور جدید، و بعد از فعالسازی CDN. در هر کدام باید بررسی کنید سرور واقعاً گواهی جدید را ارائه میدهد، تاریخش درست است و دامنه مورد نظر در فهرست SAN آمده.
کاربران مرتب به ما میگویند اینترنتشان قطع شده، چون مرورگر هشدار «اتصال خصوصی نیست» داده است. در بیشتر این موارد DNS و پورت سرور هر دو سالماند و صورتمسئله انقضای گواهی یا نخواندن نام دامنه با گواهی است. جداکردن این دو حالت از هم، اولین کاری است که SSL Checker انجام میدهد.
زیردامنهها هم داستان جداگانهای دارند. ممکن است example.com بدون خطا باز شود اما panel.example.com گواهی مناسبی نداشته باشد؛ یکسانبودن IP این دو تضمین نمیکند هر دو گواهی معتبری دریافت کنند.
یک تفکیک مسئولیت هم اینجا لازم است. اگر سایت یا پنل سازمانی شما روی سروری با پهنای باند اختصاصی یا در دیتاسنتر قرار دارد، پایداری مسیر اینترنت فقط دسترسی به سرور را تأمین میکند. نصب گواهی، ارائه زنجیره کامل و تنظیم SNI کار وبسرور، Reverse Proxy یا Load Balancer است و هیچ ارتباطی با کیفیت خط ندارد.
آموزش کار با ابزار SSL Checker آسیاتکین
برای گرفتن نتیجه درست باید نام میزبان را وارد کنید، نه نشانی کامل یک صفحه. وجود https://، مسیرهایی مانند /login یا پارامترهای انتهای URL میتواند ورودی را نامعتبر کند.
در کادر Hostname نام دامنهای مانند asiatechin.com یا www.example.com را بدون https:// بنویسید.
پورت را روی ۴۴۳ نگه دارید، مگر اینکه سرویس HTTPS روی پورت دیگری مثل ۸۴۴۳ اجرا شود.
دکمه بررسی را بزنید. ابزار اول نام دامنه را Resolve میکند، به پورت مقصد وصل میشود و با ارسال SNI فرایند TLS Handshake را انجام میدهد.
وضعیت اعتبار، روزهای باقیمانده، نسخه TLS، Cipher، زنجیره گواهی و SAN را بخوانید.
با دکمه کپی خروجی متنی را بردارید تا بتوانید برای مدیر سرور یا پشتیبانی بفرستید.
در نسخه فعلی فقط میزبانهای عمومی بررسی میشوند و آدرسهای خصوصی مانند 192.168.1.1 قابل آزمایش نیستند. سقف درخواست ۲۰ در دقیقه و زمان انتظار هر بررسی حدود ۱۲ ثانیه است؛ این محدودیت جلوی ارسال انبوه درخواست و نگهداشتن طولانی اتصال را میگیرد.
نتیجه SSL Checker را چگونه بخوانیم؟
وضعیت Valid یعنی گواهی در بازه اعتبار است و زنجیرهاش برای سرور بررسیکننده مورد اعتماد. Warning وقتی میآید که کمتر از ۳۰ روز تا انقضا مانده باشد و Expired یعنی اعتبار تمام شده، که معمولاً هشدار جدی مرورگر را در پی دارد. Not Yet Valid نشان میدهد زمان شروع اعتبار هنوز نرسیده؛ این یکی معمولاً بعد از استقرار زودهنگام گواهی یا بهدلیل اختلاف ساعت سیستم دیده میشود. Untrusted بیشتر در گواهیهای Self-signed، مراجع خصوصی و زنجیرههای ناقص رخ میدهد و Failed یعنی ابزار اصلاً نتوانسته Handshake را تکمیل کند.
مقدار Protocol نسخه توافقشده TLS و Cipher مجموعه الگوریتمهای همان اتصال است. اینجا یک برداشت اشتباه رایج هست: دیدن TLS 1.3 فقط میگوید این اتصال آزمایشی با آن نسخه برقرار شده، نه اینکه نسخههای قدیمی روی سرور غیرفعال شدهاند.
مقدار Trust بر پایه مخزن گواهیهای مورد اعتماد سرور بررسیکننده تعیین میشود، پس گواهیای که روی سیستمهای جدید معتبر است میتواند روی گوشی یا سیستمعامل خیلی قدیمی بهدلیل نبود Root CA مناسب خطا بدهد. عدد Chain هم فقط تعداد گواهیهای دریافتشده در مسیر اعتماد است و امتیاز امنیتی نیست.
در بخش Certificate، نام اصلی، شماره سریال، اندازه کلید و اثر انگشت SHA-256 میآید. Fingerprint کاربرد دقیقی دارد: اگر گواهی را روی دیسک تمدید کردهاید اما همان Fingerprint قبلی را میبینید، وبسرور یا پراکسی هنوز نسخه قدیمی را سرو میکند.
SAN و مسئله دامنههای تحت پوشش
فهرست SAN یا Subject Alternative Name نامهایی را مشخص میکند که گواهی اجازه دارد برایشان استفاده شود. مطابق استاندارد RFC 9525 برای احراز هویت سرویس در TLS، تطبیق نام دامنه باید بر اساس شناسههای SAN انجام شود و Common Name دیگر معیار قابل اتکایی نیست.
نتیجه عملیاش این است که اگر گواهی فقط برای example.com صادر شده باشد، بازکردن www.example.com میتواند خطای نام دامنه بدهد. گواهی Wildcard مانند *.example.com معمولاً shop.example.com را پوشش میدهد، اما نه خود example.com را و نه دامنه چندسطحی مانند admin.shop.example.com را. به همین دلیل دامنه اصلی و نسخه www را همیشه جداگانه آزمایش کنید؛ همین یک عادت ساده، بیشتر خطاهای پنهان تنظیمات چنددامنهای را زودتر بیرون میکشد.
چرا پورت ۴۴۳ باز است اما SSL خطا میدهد؟
روی یک پورت باز لزوماً سرویس TLS اجرا نمیشود. ممکن است برنامه دیگری روی آن گوش کند، تنظیمات HTTPS وبسرور ناقص باشد، یا فایروال اجازه اتصال TCP بدهد ولی Handshake را مختل کند. برای همین ترتیب بررسی اهمیت دارد: اول با ابزار DNS Lookup آسیاتکین رکوردهای A، AAAA و CNAME را کنترل کنید تا مطمئن شوید دامنه به سرور درست اشاره میکند، بعد با ابزار Port Checker آسیاتکین ببینید پورت ۴۴۳ از اینترنت در دسترس است، و در آخر سراغ گواهی بروید.
این ترتیب دلیل فنی دارد. در فرایند SSL Checker اول DNS دامنه به IP تبدیل میشود، بعد اتصال TCP برقرار میشود و نام دامنه از طریق SNI به سرور میرود تا گواهی مناسب انتخاب شود. اگر رکورد DNS به سرور اشتباهی اشاره کند، ابزار گواهی همان سرور اشتباه را تحویل میگیرد و شما دنبال مشکلی میگردید که وجود ندارد.
در استقرارهای Nginx و CDN بارها به این مورد خوردهایم که فایل گواهی تمدید شده اما سرویس Reload نشده است؛ فایل جدید روی سرور هست و کاربران همچنان قبلی را میگیرند. خطای نزدیک به آن، در سرورهای چنددامنهای، انتخاب Virtual Host پیشفرض و ارسال گواهی سایت دیگری است.
مورد سوم Incomplete Chain است که وقتی پیش میآید گواهی اصلی نصب شده ولی Intermediate در فایل Full Chain نیامده باشد. بعضی مرورگرها گواهی واسط را از حافظه قبلی پیدا میکنند و سایت ظاهراً سالم بالا میآید، اما دستگاهی که آن واسط را ذخیره نکرده هشدار میدهد. در CDNها و Load Balancerهای چندگرهی هم ممکن است گواهی روی همه نقاط همزمان بهروز نشده باشد؛ نتیجه ابزار در این حالت فقط وضعیت همان سروری است که مسیریابی در لحظه بررسی انتخاب کرده.
آیا وضعیت Valid یعنی سایت امن است؟
وضعیت Valid فقط سلامت گواهی، بازه اعتبار، تطابق دامنه و اعتماد به زنجیره CA را میسنجد. وجود بدافزار، آسیبپذیری برنامه، رمز عبور ضعیف، تزریق SQL، خطای احراز هویت یا Mixed Content را رد نمیکند.
نمایش یک نسخه TLS و یک Cipher هم جای اسکن جامع تنظیمات را نمیگیرد. راهنمای TLS بنیاد OWASP استفاده پیشفرض از TLS 1.3، پشتیبانی کنترلشده از TLS 1.2 و غیرفعالکردن TLS 1.0 و 1.1 را توصیه میکند. برای ممیزی کامل باید همه نسخهها، Cipher Suiteها، HSTS، وضعیت ابطال گواهی و تنظیمات وبسرور جداگانه آزمایش شوند.
چه زمانی باید گواهی SSL تمدید شود؟
هشدار کمتر از ۳۰ روز فرصت خوبی برای کنترل فرایند تمدید خودکار است. طبق پرسشهای متداول رسمی Let's Encrypt، گواهیهای عادی این مرجع ۹۰ روز اعتبار دارند و تمدیدشان در فاصله ۶۰ روزه توصیه شده است.
اما موفقبودن Certbot یا پنل میزبانی پایان کار نیست. بعد از هر تمدید، تاریخ جدید، Fingerprint، فهرست SAN و گواهیای که از سمت CDN یا Reverse Proxy ارائه میشود را دوباره کنترل کنید. اگر Fingerprint عوض نشده، تمدید انجام شده ولی هنوز به کاربر نرسیده است — و این دقیقاً همان حالتی است که چند هفته بعد به شکل قطعی ناگهانی سایت خودش را نشان میدهد.
گفتوگو
نظرات خوانندگان
سؤال یا تجربهٔ خود را دربارهٔ این مطلب بنویسید.
در حال بارگذاری نظرات…