Un coleg vă dă certificatul CA al organizației. Requests oferă un parametru numit cert. Numele par potrivite, dar răspund la întrebări diferite.

SetareScop
verifySelectează materialul de încredere folosit pentru verificarea celeilalte părți
certPrezintă un certificat de client, împreună cu cheia sa privată, când este necesară autentificarea clientului

Pentru o CA de interceptare aprobată, o operație Requests poate selecta pachetul CA dorit:

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

Aici routes este maparea proxy existentă a aplicației. Calea trebuie să numească pachetul de încredere corect și lizibil pentru acest client. Nu este un certificat de site descărcat și ales doar pentru că conexiunea a eșuat.

Variabila de mediu REQUESTS_CA_BUNDLE este o altă sursă de încredere acceptată. Verificați calea reală de trimitere dacă pare ineficientă; fluxurile de cereri pregătite și setările explicite pot schimba modul în care este îmbinată configurația mediului.

Nu ar trebui să aveți nevoie de cheia privată a CA

Certificatul CA public este ceea ce are nevoie un client pentru a recunoaște un emitent aprobat. Cheia sa privată de semnare este un secret puternic al altei părți. Nu ar trebui distribuită utilizatorilor aplicației ca parte a unei reparații de rutină a încrederii proxy.

Un certificat de client poate fi în continuare cerut de o destinație anume sau de o altă relație TLS configurată separat. Aceasta este o cerință separată, nu ceva dedus din fiecare eroare de verificare a certificatului.

Când apare următoarea eroare, numiți operația: încărcarea unui fișier CA, verificarea unui certificat al celeilalte părți sau prezentarea unei identități de client. Mutarea unui fișier între verify și cert până când mesajul se schimbă nu este o modalitate fiabilă de a-i alege rolul.

Articole similare