Sisi mana dari proxy inspeksi yang menolak sertifikat?

Klien mempercayai proxy inspeksi yang disetujui. Permintaan tetap gagal karena kesalahan sertifikat. Kedua fakta bisa benar: proxy itu punya hubungan TLS lain untuk diverifikasi.

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

Dalam pengaturan intersepsi, perantara mengakhiri TLS klien dan membuat koneksinya sendiri ke depan. Klien dapat menerima sertifikat yang disajikan di sisinya sementara proxy menolak sertifikat yang diterimanya dari situs web.

Baca kesalahan verifikator

Tentukan proses mana yang melaporkan rantai atau nama host yang gagal. Halaman kesalahan buatan proxy bisa sampai ke klien dengan sukses melalui koneksi yang valid. Mengubah lagi berkas CA klien tidak memperbarui konfigurasi kepercayaan hulu proxy.

Misalnya, Mitmproxy mendokumentasikan opsi kepercayaan hulu yang terpisah, termasuk ssl_verify_upstream_trusted_ca. Administrator yang berwenang dapat mengonfigurasi kepercayaan yang disetujui untuk layanan hulu sambil mempertahankan verifikasi. Produk proxy lain memerlukan antarmuka yang sesuai.

Periksa juga nama tujuan yang sebenarnya dan rantainya. Layanan privat yang kehilangan perantara, sertifikat kedaluwarsa, dan penerbit privat yang tidak dikenal memerlukan perbaikan berbeda. Pengecualian yang dimaksudkan untuk satu layanan privat tidak boleh diam-diam menjadi penerimaan global atas setiap sertifikat.

Terowongan CONNECT biasa berbeda

Terowongan penerusan buram tidak memisahkan TLS tujuan dengan cara ini. Aplikasi biasanya menegosiasikan dan memverifikasi sesi TLS ujung ke ujung itu sendiri. Pertama pastikan apakah intersepsi benar-benar bagian dari rute, alih-alih menerapkan pengaturan proxy inspeksi pada perantara mana pun.

Catat kedua hasil verifikasi secara terpisah. “Sertifikat proxy tepercaya” menjawab pertanyaan di sisi klien; itu tidak membuktikan apa yang dilihat proxy saat terhubung ke hulu.