Python Requests: CA balíčky patří do verify, ne do cert
Vložte schválený materiál důvěry CA do konfigurace ověřování, místo abyste chybu certifikátu považovali za žádost o soukromý klíč klienta.
Kolega vám dá CA certifikát organizace. Requests nabízí parametr s názvem cert. Názvy vypadají, že k sobě patří, ale odpovídají na různé otázky.
| Nastavení | Účel |
|---|---|
verify | Vybere materiál důvěry používaný k ověření protistrany |
cert | Předloží klientský certifikát s jeho soukromým klíčem, když je vyžadováno ověření klienta |
Pro schválenou zachytávající CA může operace Requests vybrat zamýšlený CA balíček:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)Zde routes je stávající mapování proxy v aplikaci. Cesta musí pojmenovat správný čitelný balíček důvěry pro tohoto klienta. Není to stažený certifikát webu vybraný jen proto, že spojení selhalo.
Proměnná prostředí REQUESTS_CA_BUNDLE je další podporovaný vstup důvěry. Pokud se zdá neúčinná, zkontrolujte skutečnou cestu odesílání; pracovní postupy připravených požadavků a explicitní nastavení mohou změnit, jak se konfigurace prostředí slučuje.
Neměli byste potřebovat soukromý klíč CA
Veřejný CA certifikát je to, co klient potřebuje k rozpoznání schváleného vydavatele. Jeho podpisový soukromý klíč je mocným tajemstvím jiné strany. Neměl by být distribuován uživatelům aplikace jako součást rutinní opravy důvěry proxy.
Klientský certifikát může stále vyžadovat konkrétní cíl nebo jiný samostatně nakonfigurovaný vztah TLS. To je samostatný požadavek, nikoli něco odvozeného z každé chyby ověření certifikátu.
Až se objeví další chyba, pojmenujte operaci: načtení souboru CA, ověření certifikátu protistrany nebo předložení identity klienta. Přesouvání souboru mezi verify a cert, dokud se zpráva nezmění, není spolehlivý způsob, jak zvolit jeho roli.