WIUNIX ACADEMY
عیبیابی TLS؛ زنجیرهٔ گواهی، SNI و تفاوت کلاینتها
صفحهٔ 2 از 2؛ مراحل قبلی و پیشنیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا میکنی؟
سیستمعامل و نسخه را انتخاب کن تا مراحل، دستورها و راهحلها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر میکنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری میشوند و به سرور یا لینک اشتراکگذاری فرستاده نمیشوند. پیش از اجرا، DNS، گواهیها و سیاست شبکهٔ واقعی را بررسی کن.
آیپی، دامنه یا پورت مثالها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای بهروزشده را کپی کن.
تنظیم مقادیر برای محیط من4 مقدار قابلتغییر
قدم بعدی
نامها و تاریخ گواهی انتخابشده را بخوانید
SAN، صادرکننده، بازهٔ اعتبار و fingerprint گواهی همان SNI را با استقرار مورد انتظار مقایسه کنید. نام common name بهتنهایی جای بررسی درست نام دامنه را نمیگیرد. fingerprint هم فقط وقتی مفید است که مرجع مقایسه قابل اعتماد باشد.
در این pipeline، pipefail نمیگذارد شکست دریافت گواهی پشت موفقیت ابزار بعدی پنهان شود. خروجی فقط اطلاعات عمومی گواهی است؛ هیچ کلید خصوصی لازم نیست.
ترمینال همان میزبان معرفیشده در توضیح گام
set -o pipefail
timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256نام و تاریخ گواهی درستاند یا اختلاف مشخص شده است. اگر نودها fingerprint متفاوت دارند، هرکدام را جدا بررسی کنید.
قدم بعدی
انتخاب پیشفرض سرور را بدون SNI مقایسه کنید
این مقایسه فقط برای تشخیص است: عمداً SNI فرستاده نمیشود و نام دامنه هم تأیید نمیشود. اگر گواهی پیشفرض با گواهی درخواست نامدار فرق دارد، علت شکست یک کلاینت قدیمی ممکن است همین انتخاب باشد.
راهحل، ارسال SNI درست یا طراحی یک مقصد پشتیبانیشده است؛ نباید برای پذیرش گواهی اشتباه، اعتبارسنجی کلاینت را خاموش کنید.
ترمینال همان میزبان معرفیشده در توضیح گام
set -o pipefail
timeout 15 openssl s_client -connect '203.0.113.10:443' -noservername -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint -sha256گواهی پیشفرض با درخواست نامدار مقایسه شده است؛ این خروجی تأیید امنیت اتصال بدون SNI نیست.
قدم بعدی
نبود پاسخ OCSP را درست تفسیر کنید
پاسخ stapled OCSP را درخواست کنید، اما نبود آن را برای هر گواهی خرابی ندانید. Let’s Encrypt در۲۰۲۵ سرویس OCSP را کنار گذاشته است؛ راهنمای قدیمیِ فعالکردن stapling برای همهٔ گواهیها را نباید بیقید استفاده کرد.
افزونههای گواهی و روش اعلام ابطال همان CA، از جمله CRL یا نیاز TLS Feature، را بررسی کنید. وضعیت stapling بهتنهایی اعتبار کامل زنجیره یا رفتار همهٔ مرورگرها را ثابت نمیکند.
ترمینال همان میزبان معرفیشده در توضیح گام
timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -status -verify_hostname 'app.example.com' -verify_return_error </dev/nullنتیجهٔ بررسی نام و زنجیره، مشاهدهٔ stapling و روش واقعی ابطال CA جدا ثبت شدهاند.
قدم بعدی
زنجیرهٔ مشخص را با ریشهٔ مشخص بررسی کنید
برای مقایسهٔ کنترلشده یا PKI خصوصی، گواهی سرور، گواهیهای میانی و ریشهٔ تأییدشده را از مسیر معتبر مدیریت گواهی بگیرید. فایلهای این پنل فقط گواهی عمومیاند، نه کلید خصوصی.
گزینهٔ trusted منابع CA پیشفرض را کنار میگذارد تا فقط bundle دادهشده مرجع اعتماد باشد؛ اعتماد سراسری سیستم تغییر نمیکند. نتیجه فقط برای همین فایلهاست و ثابت نمیکند سرور در حال حاضر همین زنجیره را میفرستد. برای خاموشکردن خطا، leaf یا intermediate را خودسرانه ریشه نکنید.
ترمینال همان میزبان معرفیشده در توضیح گام
openssl verify -purpose sslserver -verify_hostname 'app.example.com' -trusted approved-roots.pem -untrusted intermediates.pem leaf.pemنتیجهٔ OK مربوط به فایلها و ریشهٔ صریح همین مقایسه است؛ پس از اصلاح مجاز سرور، بررسی زنده را دوباره انجام دهید.
همان لایهای را اصلاح کنید که خراب است
اگر سرور گواهی اشتباهی میفرستد، اتصال دامنه به گواهی در پیکربندی سرویس را بررسی کنید؛ اگر خود گواهی نادرست است، صدور مجدد لازم میشود. زنجیرهٔ ناقص به نصب گواهی میانی درست روی سرور نیاز دارد، مخزن اعتماد قدیمی به بهروزرسانی پشتیبانیشدهٔ کلاینت، و انقضا به تمدید و نصب موفق گواهی. هر کدام مسیر اصلاح خودش را دارد.
پنلهای تشخیصی این آموزش تغییری ایجاد نمیکنند. پیش از اصلاح، نسخهای از تنظیمات فعلی نگه دارید و تغییر را از روال مدیریت گواهی انجام دهید. اگر تغییر شکست خورد، فایل زنجیره و تنظیم اتصال دامنه به گواهی معتبر قبلی را برگردانید؛ غیرفعالکردن اعتبارسنجی، بازیابی سرویس محسوب نمیشود. کلید خصوصی را در وبسایت تشخیصی بارگذاری نکنید.
نتیجه را با کلاینت واقعی تأیید کنید
همهٔ نودها و خانوادههای آدرسی را که کلاینت استفاده میکند، با نام درست بررسی کنید. سپس همان کتابخانهٔ TLS اپلیکیشن را با مجموعهٔ اعتماد پشتیبانیشدهٔ خودش بیازمایید. SNI، SAN، تاریخ، زنجیره، نسخهٔ trust store و fingerprint را ثبت کنید.
این راهنما بر مستندات رسمی تکیه دارد؛ ادعای آزمون همهٔ مرورگرها، بررسی عملی ابطال یا تأیید مقصد سفارشی شما را ندارد.
پشتوانهٔ این آموزش
منابع رسمی
وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخهها نیست.
- راهنمای اتصال و اعتبارسنجی با s_client
- گزینههای ساخت و اعتبارسنجی زنجیره در OpenSSL
- خواندن اطلاعات گواهی با x509
- پایان پشتیبانی OCSP در Let’s Encrypt
- راهنمای رسمی curl و بررسی TLS
- انتخاب صریح مخزن اعتماد در OpenSSL
- چرخهٔ پشتیبانی Ubuntu
- انتشارها و پشتیبانی Debian
- انتشارهای پشتیبانیشدهٔ Rocky Linux
- انتشارهای AlmaLinux
- امنیت شبکه و OpenSSH در RHEL 9
- امنیت شبکه در RHEL 10