Hamkasbingiz sizga tashkilotning CA sertifikatini beradi. Requests'da cert nomli parametr bor. Nomlar juftga o'xshaydi, lekin ular turli savollarga javob beradi.

SozlamaMaqsad
verifyQarshi tomonni tekshirish uchun ishlatiladigan ishonch materialini tanlaydi
certMijoz autentifikatsiyasi talab qilinganda mijoz sertifikatini shaxsiy kaliti bilan taqdim etadi

Tasdiqlangan tutib olish CA uchun Requests amali mo'ljallangan CA to'plamini tanlashi mumkin:

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

Bu yerda routes ilovaning mavjud proksi xaritasidir. Yo'l bu mijoz uchun to'g'ri o'qiladigan ishonch to'plamini ko'rsatishi kerak. Bu faqat ulanish muvaffaqiyatsiz bo'lgani uchun tanlangan yuklab olingan veb-sayt sertifikati emas.

REQUESTS_CA_BUNDLE muhit o'zgaruvchisi yana bir qo'llab-quvvatlanadigan ishonch kiritishidir. Agar u samarasiz ko'rinsa, haqiqiy yuborish yo'lini tekshiring; tayyorlangan so'rov ish oqimlari va aniq sozlamalar muhit konfiguratsiyasi qanday birlashtirilishini o'zgartirishi mumkin.

Sizga CA'ning shaxsiy kaliti kerak bo'lmasligi kerak

Mijoz tasdiqlangan chiqaruvchini tanishi uchun ommaviy CA sertifikati kerak. Uning imzo shaxsiy kaliti boshqa tomonning kuchli siri. Uni oddiy proksi ishonchini tuzatishning bir qismi sifatida ilova foydalanuvchilariga tarqatmaslik kerak.

Mijoz sertifikati baribir ma'lum bir manzil yoki alohida sozlangan boshqa TLS munosabati tomonidan talab qilinishi mumkin. Bu alohida talab, har bir sertifikat tekshiruvi xatosidan kelib chiqadigan narsa emas.

Keyingi xato paydo bo'lganda, amalni nomlang: CA faylini yuklash, qarshi tomon sertifikatini tekshirish yoki mijoz identifikatorini taqdim etish. Xabar o'zgaruncha faylni verify va cert o'rtasida ko'chirish uning rolini tanlashning ishonchli usuli emas.

O'xshash maqolalar