Python Requests: CA-pakaĵoj apartenas al verify, ne al cert
Metu aprobitan CA-fidmaterialon en la kontrolan agordon anstataŭ trakti atestilan eraron kiel peton pri privata ŝlosilo de la kliento.
Kolego donas al vi la CA-atestilon de la organizo. Requests proponas parametron nomatan cert. La nomoj ŝajnas paro, sed ili respondas malsamajn demandojn.
| Agordo | Celo |
|---|---|
verify | Elektas la fidmaterialon uzatan por kontroli la kontraŭparton |
cert | Prezentas klientan atestilon kun ĝia privata ŝlosilo, kiam necesas klienta aŭtentigo |
Por aprobita intercepta CA, Requests-operacio povas elekti la celitan CA-pakaĵon:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)Ĉi tie routes estas la ekzistanta prokura mapado de la aplikaĵo. La vojo devas nomi la ĝustan legeblan fidpakaĵon por ĉi tiu kliento. Ĝi ne estas elŝutita reteja atestilo elektita nur ĉar la konekto malsukcesis.
La medivariablo REQUESTS_CA_BUNDLE estas alia subtenata fidfonto. Kontrolu la faktan sendvojon se ĝi ŝajnas senefika; laborfluoj de preparitaj petoj kaj eksplicitaj agordoj povas ŝanĝi kiel la media agordo estas kunfandata.
Vi ne devus bezoni la privatan ŝlosilon de la CA
La publika CA-atestilo estas tio, kion kliento bezonas por rekoni aprobitan eldonanton. Ĝia subskriba privata ŝlosilo estas potenca sekreto de alia partio. Ĝi ne estu disdonita al aplikaĵuzantoj kiel parto de rutina prokura fidriparo.
Klienta atestilo ankoraŭ povas esti postulata de aparta celo aŭ de alia aparte agordita TLS-rilato. Tio estas aparta postulo, ne io deduktita el ĉiu atestila kontrola eraro.
Kiam aperos la sekva eraro, nomu la operacion: ŝargi CA-dosieron, kontroli kontraŭpartan atestilon aŭ prezenti klientan identecon. Movi dosieron inter verify kaj cert ĝis la mesaĝo ŝanĝiĝos ne estas fidinda maniero elekti ĝian rolon.