Seorang rakan sekerja memberikan anda sijil CA organisasi. Requests menawarkan parameter bernama cert. Namanya kelihatan sepadan, tetapi kedua-duanya menjawab soalan yang berbeza.

TetapanTujuan
verifyMemilih bahan kepercayaan yang digunakan untuk mengesahkan pihak lawan
certMengemukakan sijil klien, bersama kunci peribadinya, apabila pengesahan klien diperlukan

Untuk CA pintasan yang diluluskan, operasi Requests boleh memilih bundel CA yang dimaksudkan:

response = requests.get(
    'https://example.com/',
    proxies=routes,
    verify='/path/to/approved-ca-bundle.pem',
    timeout=15,
)

Di sini routes ialah pemetaan proksi sedia ada aplikasi. Laluan mesti menamakan bundel kepercayaan yang betul dan boleh dibaca untuk klien ini. Ia bukan sijil laman web yang dimuat turun dan dipilih hanya kerana sambungan gagal.

Pembolehubah persekitaran REQUESTS_CA_BUNDLE ialah satu lagi input kepercayaan yang disokong. Periksa laluan penghantaran sebenar jika ia kelihatan tidak berkesan; aliran kerja permintaan yang disediakan dan tetapan eksplisit boleh mengubah cara konfigurasi persekitaran digabungkan.

Anda tidak sepatutnya memerlukan kunci peribadi CA

Sijil CA awam ialah apa yang klien perlukan untuk mengenali pengeluar yang diluluskan. Kunci peribadi tandatangannya ialah rahsia kuat pihak lain. Ia tidak sepatutnya diedarkan kepada pengguna aplikasi sebagai sebahagian daripada pembaikan kepercayaan proksi rutin.

Sijil klien mungkin masih diperlukan oleh destinasi tertentu atau oleh hubungan TLS lain yang dikonfigurasikan secara berasingan. Itu keperluan berasingan, bukan sesuatu yang disimpulkan daripada setiap ralat pengesahan sijil.

Apabila ralat seterusnya muncul, namakan operasi: memuatkan fail CA, mengesahkan sijil pihak lawan, atau mengemukakan identiti klien. Memindahkan fail antara verify dan cert sehingga mesej berubah bukan cara yang boleh dipercayai untuk memilih peranannya.

Artikel berkaitan