Колега ви дава CA сертификата на организацията. Requests предлага параметър cert. Имената изглеждат подходящи, но отговарят на различни въпроси.

НастройкаПредназначение
verifyИзбира материала за доверие, използван за проверка на другата страна
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, докато съобщението се промени, не е надежден начин да изберете ролята му.

Подобни статии