Python Requests: CA-pakker hører hjemme i verify, ikke i cert
Legg godkjent CA-tillitsmateriale i verifiseringskonfigurasjonen i stedet for å behandle en sertifikatfeil som en forespørsel om klientens private nøkkel.
En kollega gir deg organisasjonens CA-sertifikat. Requests tilbyr en parameter kalt cert. Navnene ser ut som et par, men de svarer på forskjellige spørsmål.
| Innstilling | Formål |
|---|---|
verify | Velger tillitsmaterialet som brukes til å verifisere motparten |
cert | Presenterer et klientsertifikat med den private nøkkelen når klientautentisering kreves |
For en godkjent avlyttings-CA kan en Requests-operasjon velge den tiltenkte CA-pakken:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)Her er routes applikasjonens eksisterende proxy-tilordning. Stien må navngi den riktige lesbare tillitspakken for denne klienten. Det er ikke et nedlastet nettstedssertifikat som bare ble valgt fordi tilkoblingen mislyktes.
Miljøvariabelen REQUESTS_CA_BUNDLE er en annen støttet tillitskilde. Sjekk den faktiske sendestien hvis den virker ineffektiv; arbeidsflyter for forberedte forespørsler og eksplisitte innstillinger kan endre hvordan miljøkonfigurasjonen slås sammen.
Du bør ikke trenge CA-ens private nøkkel
Det offentlige CA-sertifikatet er det en klient trenger for å gjenkjenne en godkjent utsteder. Den private signeringsnøkkelen er en annen parts mektige hemmelighet. Den bør ikke distribueres til applikasjonsbrukere som en del av en rutinemessig proxy-tillitsreparasjon.
Et klientsertifikat kan fortsatt kreves av et bestemt mål eller av en annen separat konfigurert TLS-forbindelse. Det er et eget krav, ikke noe som utledes fra hver sertifikatverifiseringsfeil.
Når den neste feilen dukker opp, navngi operasjonen: laste en CA-fil, verifisere et motpartssertifikat eller presentere en klientidentitet. Å flytte en fil mellom verify og cert til meldingen endres er ikke en pålitelig måte å velge rollen på.