وب‌سایت گواهی اشتباه را نشان می‌دهد؟ شنونده را پیدا کنید
یک سایت گواهی غیرمنتظره‌ای ارائه می‌دهد و فایل آشکار بازنویسی می‌شود. شنونده و میزبان مجازی‌ای را که نخست پاسخ داد شناسایی کنید.
نصب نرم‌افزار VPN روی یک میزبان وب می‌تواند سرویس‌ها را بازآرایی کند، اما یک گواهی غیرمنتظره ثابت نمی‌کند که فایل‌های Apache بازنویسی شده‌اند. چیزی آن گواهی را به مرورگر شما ارائه داد، و نخستین کار نام‌گذاری آن است. تا زمانی که شنونده و میزبان مجازی شناسایی نشوند، هر تعمیر حدسی است که به لایه نادرست اعمال می‌شود. کل بررسی زیر فقط خواندنی است.
هیچ‌چیز دوباره راه‌اندازی، حذف یا بازنویسی نمی‌شود در حالی که واقعیت‌های تعیین‌کننده پرونده را جمع می‌کنید.
گواهی‌ای را بخوانید که مرورگر واقعاً دریافت کرد
نام میزبان، نشانی حل‌شده برای هر خانواده، درگاه و جزئیات گواهی‌ای را که مرورگر از آن شکایت کرد ثبت کنید. نامی که هم به رکورد A و هم به AAAA حل می‌شود می‌تواند به دو جبهه مختلف برسد، و تنها یکی از آن‌ها ممکن است میزبانی باشد که دسترسی پوسته به آن دارید. مرورگر پشت پروکسی می‌تواند دوباره مسیر سومی بگیرد. حدس زدن اینکه کدام یک هشدار را ایجاد کرد تنها مشاهده‌ای را که دارید هدر می‌دهد.
سپس دست‌دادن را از ماشینی روی همان مسیر بازتولید کنید، نشانی را صریحاً نام ببرید و نام سرور موردنظر را بفرستید تا پاسخ سایت را بازتاب دهد نه میزبان پیش‌فرض را.
openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltNameنام‌های جایگزین موضوع و اثر انگشت را با گواهی‌ای که انتظار دارید بسنجید، نه با صادرکننده‌ای آشنا. اتصال به نشانی لخت بدون نام سرور می‌تواند گواهی پیش‌فرض را انتخاب کند، که آن‌گاه شبیه فایل نادرست به نظر می‌رسد در حالی که در واقع پرسش نادرست است.
فرایند متصل به آن درگاه را شناسایی کنید
روی میزبانی که باید اتصال را دریافت کند، شنونده‌ها را فهرست کنید و نشانی اتصال، خانواده نشانی و مالک فرایند را یادداشت کنید. سرویسی که به نشانی بازگشتی متصل است با سرویسی که به همه رابط‌ها متصل است یکسان نیست، و انتشار کانتینر می‌تواند شنونده عمومی را کاملاً جای دیگری بگذارد.
sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'اگر TLS توسط متعادل‌کننده بار یا پروکسی جلویی پایان می‌یابد، اینجا بایستید و به‌جای آن همان جبهه را بررسی کنید. نمونه Apache پشت آن ممکن است هرگز گواهی‌ای به مرورگر عمومی ارائه ندهد، بنابراین ویرایش پیکربندی آن چیزی را که مرورگر می‌بیند تغییر نمی‌دهد. نمای سوکت‌ها و دست‌دادن بیرونی باید یک مسیر را توصیف کنند، و همین چیزی است که این مقایسه اثبات می‌کند.
میزبان مجازی را پیش از فایل تطبیق دهید
وقتی Apache پایان‌دهنده است، از آن بپرسید کدام میزبان مجازی برای آن نشانی و نام برنده می‌شود. فرمان کنترل چیدمان مؤثر را چاپ می‌کند، شامل گروه منطبق با هر سوکت، نام‌های سرور اعلام‌شده و میزبانی که پیش‌فرض تلقی می‌شود. ویرایش فایل گواهی بدون آن پاسخ همان راهی است که سایت نادرست در نهایت از فایل درست سرو می‌شود.
sudo apachectl -Sپرسش‌های متداول SSL در Apache توضیح می‌دهد که نشانگر نام سرور چگونه گواهی را انتخاب می‌کند. سرصفحه Host در HTTP پس از دست‌دادن می‌رسد و نمی‌تواند آنچه را پیش‌تر ارائه شده به‌صورت گذشته تغییر دهد، بنابراین نام نامنطبق یا غایب به میزبان پیش‌فرض برمی‌گردد.
میزبان مجازی نام‌دار با غلط تایپی در ServerAlias دقیقاً همین نشانه را تولید می‌کند، و همچنین فایل پیکربندی دومی که نخست میزبانی را بارگذاری می‌کند که همه‌چیز را می‌گیرد. هر دو در آن فهرست چیدمان دیده می‌شوند.
تعمیر را روی هر مسیری که ادعا می‌کنید بررسی کنید
پس از تغییر تأییدشده، بررسی ویژه نام میزبان را برای هر خانواده نشانی تکرار کنید و با اعتبارسنجی معمول مرورگر به‌جای پرچم دورزدن پایان دهید. پیش از دست زدن به تنظیمات مشترک شنونده، یک مسیر مدیریت جداگانه نگه دارید، زیرا خطا در آنجا دسترسی‌ای را که برای خنثی کردن آن به کار می‌بردید حذف می‌کند. سپس بنویسید کدام شنونده پاسخ داد، کدام میزبان مجازی منطبق شد و کدام گواهی پیش و پس از آن سرو شد.
حذف یک بسته می‌تواند چیدمان را تغییر دهد و ناسازگاری اصلی را بی‌توضیح بگذارد، و به همین دلیل آن ثبت از تعمیر بیشتر عمر می‌کند.
آنچه می‌خواهید سایت موردنظر در نقطه ورود موردنظر است. گواهی متفاوت پس از ناپدید شدن سرویس نامرتبط آن نتیجه نیست، حتی وقتی مرورگر از شکایت دست می‌کشد.