Ralat sijil semasa menggunakan proksi
Sebelum mengubah tetapan sijil, kenal pasti sama ada pengesahan gagal pada sambungan TLS proksi itu sendiri atau laman web destinasi.
Kenal pasti jabat tangan TLS yang gagal sebelum mengubah berkas CA. Sijil proksi dan sijil laman web boleh disemak pada sambungan berbeza.
| Proksi dan destinasi | Semakan TLS |
|---|---|
| Proksi HTTP ke destinasi HTTPS | Selepas CONNECT, sahkan sijil destinasi melalui terowong. |
| Proksi HTTPS ke destinasi HTTPS | Sahkan TLS ke proksi dahulu; selepas terowong dibuka, sahkan sesi TLS berasingan ke destinasi. |
Gunakan jejak terperinci untuk mengenal pasti nama hos yang diminta dan jabat tangan terakhir yang selesai. Kegagalan sijil proksi HTTPS boleh berlaku sebelum laman web dihubungi. Semak nama yang dimaksudkan bagi sambungan itu, tempoh sah sijil, jam setempat, rantaian yang dijangka dan stor kepercayaan yang diluluskan. Sertakan pemintasan TLS yang dikonfigurasi dengan sengaja atau sijil akar yang ditambah dalam siasatan.
curl menyediakan pilihan CA berasingan untuk kedua-dua sambungan:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert menyediakan asas kepercayaan untuk proksi; --cacert untuk destinasi. Gantikan titik akhir dan fail contoh dengan nilai daripada susunan kepercayaan yang dikehendaki. Berkas tersuai tidak perlu jika kepercayaan sistem sudah mencukupi.
Menggantikan nama hos dengan IP sewenang-wenangnya mengubah pemadanan sijil. Melangkau pengesahan boleh menyembunyikan kegagalan tanpa mengesahkan identiti pihak di hujung lain. Bagi proksi yang tidak dikenali, permintaan memasang CA akarnya bukan alasan yang cukup untuk mempercayainya.
Sambungan port yang ditolak atau CONNECT yang ditolak tergolong dalam peringkat lebih awal; mengubah sijil tidak dapat membaikinya. Sebaliknya, selepas TLS destinasi disahkan, ralat HTTP laman web berkaitan dengan respons yang diterima, bukan pelarasan CA sekali lagi.