Ein kollega gjev deg CA-sertifikatet til organisasjonen. Requests tilbyr ein parameter kalla cert. Namna ser ut som eit par, men dei svarar på ulike spørsmål.

InnstillingFøremål
verifyVel tillitsmaterialet som vert brukt til å verifisere motparten
certLegg fram eit klientsertifikat med den private nøkkelen når klientautentisering er påkravd

For ein godkjend avlyttings-CA kan ein Requests-operasjon velje den tiltenkte CA-pakken:

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

Her er routes den eksisterande proxy-tilordninga til applikasjonen. Stien må nemne den rette lesbare tillitspakken for denne klienten. Det er ikkje eit nedlasta nettstadssertifikat som berre vart valt fordi tilkoplinga mislukkast.

Miljøvariabelen REQUESTS_CA_BUNDLE er ei anna støtta tillitskjelde. Sjekk den faktiske sendestien om han verkar ineffektiv; arbeidsflytar for førebudde førespurnader og eksplisitte innstillingar kan endre korleis miljøkonfigurasjonen vert slått saman.

Du bør ikkje trenge den private nøkkelen til CA-en

Det offentlege CA-sertifikatet er det ein klient treng for å kjenne att ein godkjend utgivar. Den private signeringsnøkkelen er ein mektig hemmelegheit hjå ein annan part. Han bør ikkje distribuerast til applikasjonsbrukarar som del av ein rutinemessig proxy-tillitsreparasjon.

Eit klientsertifikat kan framleis krevjast av eit bestemt mål eller av ein annan separat konfigurert TLS-relasjon. Det er eit eige krav, ikkje noko som vert utleidd frå kvar sertifikatverifiseringsfeil.

Når den neste feilen dukkar opp, nemn operasjonen: laste ei CA-fil, verifisere eit motpartssertifikat eller leggje fram ein klientidentitet. Å flytte ei fil mellom verify og cert til meldinga endrar seg er ikkje ein påliteleg måte å velje rolla på.

Relaterte artiklar