Python Requests: paketi CA spadajo v verify, ne v cert
Vstavite odobreno gradivo zaupanja CA v konfiguracijo preverjanja, namesto da bi napako certifikata obravnavali kot zahtevo za zasebni ključ odjemalca.
Sodelavec vam izroči certifikat CA organizacije. Requests ponuja parameter z imenom cert. Imeni sta videti kot par, vendar odgovarjata na različni vprašanji.
| Nastavitev | Namen |
|---|---|
verify | Izbere gradivo zaupanja, ki se uporablja za preverjanje druge strani |
cert | Predstavi potrdilo odjemalca z njegovim zasebnim ključem, ko je potrebno preverjanje odjemalca |
Za odobreno prestrezno CA lahko operacija Requests izbere predvideni paket CA:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)Tukaj je routes obstoječe preslikavanje posrednika v aplikaciji. Pot mora navesti pravi berljivi paket zaupanja za tega odjemalca. To ni preneseno potrdilo spletnega mesta, izbrano samo zato, ker je povezava spodletela.
Okoljska spremenljivka REQUESTS_CA_BUNDLE je drug podprt vir zaupanja. Preverite dejansko pot pošiljanja, če se zdi neučinkovita; delovni tokovi pripravljenih zahtev in izrecne nastavitve lahko spremenijo, kako se okoljska konfiguracija združuje.
Zasebnega ključa CA ne bi smeli potrebovati
Javno potrdilo CA je tisto, kar odjemalec potrebuje za prepoznavo odobrenega izdajatelja. Njegov zasebni ključ za podpisovanje je močna skrivnost druge strani. Ne bi ga smeli razdeljevati uporabnikom aplikacije kot del rutinskega popravila zaupanja posrednika.
Potrdilo odjemalca lahko še vedno zahteva določen cilj ali druga ločeno nastavljena povezava TLS. To je ločena zahteva, ne nekaj, kar se sklepa iz vsake napake preverjanja certifikata.
Ko se pojavi naslednja napaka, poimenujte operacijo: nalaganje datoteke CA, preverjanje potrdila druge strani ali predstavitev identitete odjemalca. Premikanje datoteke med verify in cert, dokler se sporočilo ne spremeni, ni zanesljiv način za izbiro njene vloge.