TLS Certificate Checker

گواهی TLS/SSL یک سایت را بررسی کنید: موضوع/صادرکننده، تاریخ‌های اعتبار، SANها، کامل بودن زنجیره و پیکربندی‌های نادرست رایج HTTPS. به صورت اختیاری تغییر مسیرها را دنبال کنید تا تأیید شود مقصد نهایی HTTPS با گواهی معتبر است. گزارش‌های JSON/PDF را صادر کنید.

Loading…

درباره بررسی‌کننده گواهی TLS

وقتی HTTPS خراب می‌شود، کاربران هشدارهای ترسناک می‌بینند و ربات‌ها به سایت شما اعتماد نمی‌کنند. این ابزار یک URL را دریافت می‌کند، به صورت اختیاری تغییر مسیرها را دنبال می‌کند و گواهی TLS محافظت‌کننده از نقطه پایانی HTTPS نهایی را بازرسی می‌کند. به شما کمک می‌کند گواهی‌های در حال انقضا، زنجیره‌های ناقص، عدم تطابق نام میزبان/SAN و سایر مشکلاتی که معمولاً باعث خطاهای مرورگر و مشکلات سئو/دسترسی می‌شوند را شناسایی کنید.

ویژگی‌ها

  • بازرسی موضوع و صادرکننده گواهی (برای چه کسی است، چه کسی آن را صادر کرده).
  • اعتبارسنجی تاریخ‌ها: notBefore / notAfter و هشدار در مورد انقضای قریب‌الوقوع.
  • بررسی SANها (نام‌های جایگزین موضوع) و پوشش نام میزبان (www در مقابل apex، زیردامنه‌ها).
  • شناسایی مشکلات زنجیره گواهی (میان‌افزارهای گمشده / زنجیره ناقص).
  • دنبال کردن اختیاری تغییر مسیر برای اعتبارسنجی اجرای HTTPS در URL نهایی.
  • شناسایی مشکلات رایج HTTPS (میزبان اشتباه، گواهی اشتباه، جریان‌های تغییر مسیر ترکیبی).
  • نتایج و یافته‌های مناسب کپی برای تیکت‌های حادثه.
  • دانلود گزارش‌های JSON و PDF برای مستندسازی و بررسی‌های بازگشتی.

🧭 نحوه استفاده for tls-certificate-checker

1

چسباندن URL برای آزمایش

URL هدف را وارد کنید. می‌توانید https://example.com یا حتی http://example.com را بچسبانید اگر می‌خواهید تأیید کنید که در نهایت به HTTPS ارتقا می‌یابد.

2

فعال کردن "دنبال کردن تغییر مسیرها" برای رفتار واقعی

اگر می‌خواهید مقصد واقعی که کاربران و خزنده‌ها به آن می‌رسند را اعتبارسنجی کنید (http→https، non-www→www)، گزینه دنبال کردن تغییر مسیرها را فعال نگه دارید.

3

اجرای بررسی و مرور خلاصه

موارد کلیدی را بررسی کنید: تاریخ‌های اعتبار، تطابق نام میزبان/SAN و اینکه آیا زنجیره کامل است.

4

بازرسی یافته‌ها و رفع علت اصلی

اگر هشدارهایی دیدید (انقضای قریب‌الوقوع، عدم تطابق، زنجیره ناقص)، آن‌ها را در لایه پایان TLS (CDN، پروکسی معکوس، متعادل‌کننده بار یا وب سرور) رفع کنید.

5

صدور JSON/PDF برای رهگیری

یک گزارش دانلود کنید تا به تیکت‌های عملیاتی/سئو پیوست کنید یا برای نگهداری یک تصویر قبل/بعد.

مشخصات فنی

ورودی و عملیات

این ابزار یک URL را بررسی می‌کند و گواهی TLS نقطه پایانی HTTPS حل‌شده را بازرسی می‌کند.

قابلیتجزئیات
فرم‌های URL پشتیبانی شدهURLهای HTTP یا HTTPS (دنبال کردن ریدایرکت قابل فعال‌سازی است).
مدیریت ریدایرکتاختیاری؛ در صورت فعال‌شدن، تا حداکثر ریدایرکت‌های پیکربندی‌شده را دنبال می‌کند.
تمرکز TLSویژگی‌های گواهی و پیکربندی‌های نادرست رایج را بررسی می‌کند.

مقادیر پیش‌فرض و محدودیت‌ها

پیش‌فرض‌های واکشی و ایمنی برای رفتار قابل پیش‌بینی تنظیم شده‌اند.

تنظیممقدار
دنبال کردن ریدایرکت‌هافعال
حداکثر ریدایرکت‌ها10
زمان‌انتظار15000 میلی‌ثانیه
User-AgentEncode64Bot/1.0 (+https://encode64.com)
شبکه‌های خصوصیمجاز نیست

موارد بررسی شده

بررسی‌ها حول متداول‌ترین مشکلات مشاهده‌شده در محیط عملیاتی طراحی شده‌اند: انقضا، عدم تطابق نام میزبان (پوشش SAN) و کامل بودن زنجیره. دنبال کردن ریدایرکت به شناسایی مواردی کمک می‌کند که HTTPS فقط روی میزبان نهایی معتبر است.

یک گواهی معتبر برای امنیت قوی ضروری است اما کافی نیست. این ابزار را با ممیزی‌های HSTS و هدرهای امنیتی برای استقرارهای تقویت‌شده ترکیب کنید.

خط فرمان

از OpenSSL و curl برای تأیید جزئیات گواهی از ترمینال خود و مقایسه با گزارش ابزار استفاده کنید.

macOS / Linux

نمایش زنجیره گواهی (SNI) برای یک میزبان

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

برای بررسی گواهی اصلی و زنجیره میانی مفید است.

استخراج سریع تاریخ انقضا

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

notBefore / notAfter را چاپ می‌کند.

فهرست SANها

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

نام‌های میزبانی که گواهی پوشش می‌دهد را نشان می‌دهد.

تأیید ریدایرکت HTTP به HTTPS

curl -I http://example.com

بررسی هدر Location و طرح نهایی.

دنبال کردن ریدایرکت‌ها و نمایش URL نهایی

curl -IL http://example.com | sed -n '1,120p'

به شناسایی زنجیره‌های تغییر مسیر و نقاط پایانی غیرکانونیکال کمک می‌کند.

همیشه از -servername با openssl s_client روی سرورها/شبکه‌های تحویل محتوای میزبانی‌شده مجازی استفاده کنید. بدون SNI، ممکن است گواهی نادرست دریافت کنید.

موارد استفاده

جلوگیری از قطعی‌های ناشی از انقضای گواهی

گواهی‌های نزدیک به انقضا را شناسایی کنید تا بتوانید قبل از مواجهه کاربران و بات‌ها با خطاهای مرورگر، آن‌ها را تمدید نمایید.

  • بررسی‌های هفتگی سلامت گواهی
  • بازرسی دامنه‌ها پس از تغییرات DNS یا CDN

رفع مشکلات زنجیره گواهی ناقص

میانجی‌های گم‌شده (رایج در تنظیمات سرور سفارشی) را که باعث اختلال در کلاینت‌های قدیمی و برخی خزنده‌ها می‌شود، شناسایی کنید.

  • بسته زنجیره Nginx/Apache نادرست پیکربندی شده
  • عدم وجود گواهی‌های میانی در متعادل‌کننده بار

اشکال‌زدایی عدم تطابق نام میزبان/SAN (www در مقابل apex)

تأیید کنید که گواهی دقیقاً میزبان دسترسی کاربران، شامل www/غیر-www و زیردامنه‌ها را پوشش می‌دهد.

  • دامنه اصلی کار می‌کند اما www خراب است
  • عدم وجود زیردامنه API در فهرست SAN

تأیید اجرای HTTPS از طریق تغییر مسیرها

اطمینان حاصل کنید که URLهای http به نقطه پایانی کانونیکال https با یک گواهی معتبر تغییر مسیر می‌دهند.

  • http→https با کد 301
  • یکسان‌سازی غیر-www→www

❓ Frequently Asked Questions

چرا ممکن است مرورگر بگوید "گواهی مورد اعتماد نیست" حتی اگر HTTPS فعال باشد؟

دلایل رایج عبارتند از: گواهی منقضی شده، زنجیره ناقص (عدم وجود گواهی میانی)، عدم تطابق نام میزبان (SAN شامل میزبان نمی‌شود)، یا ارائه گواهی نادرست به دلیل پیکربندی اشتباه SNI/میزبانی مجازی.

SANها چیستند و چرا مهم هستند؟

SANها (نام‌های جایگزین موضوع) نام‌های میزبانی هستند که یک گواهی برای آن‌ها معتبر است. اگر سایت شما هم از طریق example.com و هم www.example.com قابل دسترسی است، گواهی باید هر دو را پوشش دهد (یا باید به طور یکنواخت به یک میزبان پوشش‌داده‌شده تغییر مسیر دهید).

آیا اگر http به https تغییر مسیر دهد مشکلی ندارد؟

بله — این توصیه می‌شود. فقط مطمئن شوید که مقصد نهایی HTTPS یک گواهی معتبر ارائه می‌دهد و زنجیره تغییر مسیر کوتاه و یکنواخت است (برای تغییر مسیرهای کانونیکال، 301 را ترجیح دهید).

آیا این ابزار نسخه‌ها/رمزهای TLS را بررسی می‌کند؟

این ابزار بر بازرسی گواهی و پیکربندی‌های اشتباه رایج متمرکز است. برای تقویت پروتکل/رمز (TLS 1.2/1.3، رمزهای ضعیف)، از یک اسکنر اختصاصی پیکربندی TLS استفاده کنید.

تفاوت بین گواهی برگ، میانی و ریشه چیست؟

گواهی برگ، گواهی سایت شماست. گواهی‌های میانی آن را به یک مرجع صدور گواهی ریشه معتبر متصل می‌کنند. مرورگرها به ریشه‌ها اعتماد دارند، بنابراین عدم وجود گواهی‌های میانی می‌تواند از ساخت یک زنجیره اعتبار معتبر جلوگیری کند.

Pro Tips

Best Practice

گواهی‌ها را زودتر تمدید کنید و در هر جایی که ممکن است تمدید خودکار (ACME) را پیاده‌سازی کنید.

Best Practice

مطمئن شوید که SANها تمام نام‌های میزبان عمومی شما (www، دامنه اصلی، زیردامنه‌های API) را پوشش می‌دهند یا از طریق ریدایرکت‌ها یک میزبان معیار واحد را اعمال کنید.

Best Practice

همیشه زنجیره کامل را ارائه دهید (گواهی اصلی + میانی). بسیاری از قطعی‌ها ناشی از بسته‌های زنجیره ناقص پس از مهاجرت‌ها هستند.

Best Practice

اگر ریدایرکت‌ها را فعال می‌کنید، آن‌ها را حداقل نگه دارید: یک پرش به آدرس https معیار ایده‌آل است.

Best Practice

TLS معتبر را با HSTS و هدرهای امنیتی جفت کنید تا محافظت قوی‌تری در دنیای واقعی داشته باشید.

Additional Resources

Other Tools