Kollega antaa sinulle organisaation CA-varmenteen. Requests tarjoaa parametrin nimeltä cert. Nimet näyttävät sopivan yhteen, mutta ne vastaavat eri kysymyksiin.

AsetusTarkoitus
verifyValitsee luottamusmateriaalin, jota käytetään vastapuolen varmentamiseen
certEsittää asiakasvarmenteen ja sen yksityisen avaimen, kun asiakkaan todennus vaaditaan

Hyväksytylle välityspalvelimen CA:lle Requests-toiminto voi valita aiottun CA-nipun:

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

Tässä routes on sovelluksen olemassa oleva välityspalvelinkartoitus. Polun on nimettävä tälle asiakkaalle oikea luettava luottamusnippu. Se ei ole ladattu verkkosivuston varmenne, joka valittiin vain siksi, että yhteys epäonnistui.

Ympäristömuuttuja REQUESTS_CA_BUNDLE on toinen tuettu luottamuslähde. Tarkista todellinen lähetyspolku, jos se vaikuttaa tehottomalta; valmisteltujen pyyntöjen työnkulut ja nimenomaiset asetukset voivat muuttaa sitä, miten ympäristöasetukset yhdistetään.

Sinun ei pitäisi tarvita CA:n yksityistä avainta

Julkinen CA-varmenne on se, mitä asiakas tarvitsee hyväksytyn myöntäjän tunnistamiseen. Sen allekirjoituksen yksityinen avain on toisen osapuolen vahva salaisuus. Sitä ei pitäisi jakaa sovelluksen käyttäjille osana rutiininomaista välityspalvelimen luottamuksen korjausta.

Asiakasvarmennetta voidaan silti vaatia tietyssä kohteessa tai toisessa erikseen määritetyssä TLS-suhteessa. Se on erillinen vaatimus, ei jotain, joka päätellään jokaisesta varmennevarmennuksen virheestä.

Kun seuraava virhe ilmaantuu, nimeä toiminto: CA-tiedoston lataaminen, vastapuolen varmenteen varmentaminen tai asiakkaan identiteetin esittäminen. Tiedoston siirtäminen verify ja cert välillä, kunnes viesti muuttuu, ei ole luotettava tapa valita sen rooli.

Aiheeseen liittyvät artikkelit