Python Requests: CA პაკეტების ადგილი verify-შია და არა cert-ში

თანამშრომელი გაძლევთ ორგანიზაციის CA სერტიფიკატს. Requests გთავაზობთ cert სახელის პარამეტრს. სახელები წყვილად გამოიყურება, მაგრამ სხვადასხვა კითხვას პასუხობენ.

დამტკიცებული ჩარევის CA-სთვის Requests ოპერაციას შეუძლია აირჩიოს სასურველი CA პაკეტი:

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

აქ routes არის აპლიკაციის არსებული პროქსის დაკავშირება. გზამ უნდა დაასახელოს ამ კლიენტისთვის სწორი, წაკითხვადი ნდობის პაკეტი. ეს არ არის ჩამოტვირთული ვებსაიტის სერტიფიკატი, რომელიც მხოლოდ იმიტომ აირჩიეს, რომ კავშირი ვერ დამყარდა.

გარემოს ცვლადი REQUESTS_CA_BUNDLE კიდევ ერთი მხარდაჭერილი ნდობის შეყვანაა. შეამოწმეთ რეალური გაგზავნის გზა, თუ ის არაეფექტური ჩანს; მომზადებული მოთხოვნის სამუშაო ნაკადები და მკაფიო პარამეტრები შეიძლება შეცვალოს, როგორ ერწყმის გარემოს კონფიგურაცია.

CA-ს კერძო გასაღები არ უნდა დაგჭირდეთ

საჯარო CA სერტიფიკატი არის ის, რაც კლიენტს სჭირდება დამტკიცებული გამომცემლის ამოსაცნობად. მისი ხელმოწერის კერძო გასაღები სხვა მხარის ძლიერი საიდუმლოა. ის არ უნდა გავრცელდეს აპლიკაციის მომხმარებლებზე პროქსის ნდობის ჩვეულებრივი შეკეთების ნაწილად.

კლიენტის სერტიფიკატი მაინც შეიძლება მოითხოვოს კონკრეტულმა დანიშნულებამ ან ცალკე კონფიგურირებულმა TLS ურთიერთობამ. ეს ცალკე მოთხოვნაა და არა ის, რაც ყოველი სერტიფიკატის შემოწმების შეცდომიდან გამომდინარეობს.

როცა გამოჩნდება შემდეგი შეცდომა, დაასახელეთ ოპერაცია: CA ფაილის ჩატვირთვა, მეორე მხარის სერტიფიკატის შემოწმება ან კლიენტის იდენტობის წარდგენა. ფაილის verify-სა და cert-ს შორის გადატანა, სანამ შეტყობინება შეიცვლება, მისი როლის არჩევის საიმედო გზა არ არის.