Tekshiruv proksisining qaysi tomoni sertifikatni rad etdi?

Mijoz tasdiqlangan tekshiruv proksisiga ishonadi. So'rov baribir sertifikat xatosi tufayli bajarilmaydi. Ikkala fakt ham to'g'ri bo'lishi mumkin: bu proksining tekshiriladigan yana bir TLS aloqasi bor.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

Ushlab qolish sxemasida vositachi mijozning TLSini tugatib, oldinga o'z ulanishini yaratadi. Mijoz o'z tomonida taqdim etilgan sertifikatni qabul qilishi mumkin, proksi esa veb-saytdan olgan sertifikatni rad etadi.

Tekshiruvchining xatosini o'qing

Muvaffaqiyatsiz zanjir yoki xost nomi haqida qaysi jarayon xabar berganini aniqlang. Proksi yaratgan xato sahifasi haqiqiy ulanish orqali mijozga muvaffaqiyatli yetib borishi mumkin. Mijozning CA faylini yana o'zgartirish proksining yuqori oqim ishonch konfiguratsiyasini yangilamaydi.

Masalan, Mitmproxy yuqori oqim ishonchining alohida parametrlarini hujjatlashtiradi, jumladan ssl_verify_upstream_trusted_ca. Tegishli administrator tekshiruvni saqlab, yuqori oqim xizmati uchun tasdiqlangan ishonchni sozlashi mumkin. Boshqa proksi mahsulotiga o'zining tegishli interfeysi kerak.

Haqiqiy manzil nomi va zanjirni ham tekshiring. Oraliq sertifikati yo'q shaxsiy xizmat, muddati o'tgan sertifikat va tanilmagan shaxsiy emitent turli tuzatishlarni talab qiladi. Bitta shaxsiy xizmat uchun mo'ljallangan istisno jimgina har bir sertifikatning global qabuliga aylanmasligi kerak.

Oddiy CONNECT tunnel boshqacha

Shaffof bo'lmagan uzatish tunnel manzil TLSini bu tarzda ajratmaydi. Odatda ilova o'sha uchdan-uchgacha TLS sessiyasini o'zi kelishib, tekshiradi. Tekshiruv proksisi sozlamalarini har qanday vositachiga qo'llash o'rniga, avval ushlab qolish haqiqatan marshrutning qismi ekanini aniqlang.

Ikkala tekshiruv natijasini alohida qayd eting. «Proksi sertifikati ishonchli» degani mijoz tomonidagi savolga javob beradi; proksi yuqoriga ulanganida nima ko'rganini tasdiqlamaydi.