Mfanyakazi mwenzako anakupa cheti cha CA cha shirika. Requests ina kigezo kinachoitwa cert. Majina yanaonekana kufanana, lakini hujibu maswali tofauti.

MpangilioMadhumuni
verifyHuchagua nyenzo za uaminifu zinazotumika kuthibitisha upande mwingine
certHuwasilisha cheti cha mteja, pamoja na ufunguo wake wa faragha, inapohitajika uthibitishaji wa mteja

Kwa CA ya kuingilia iliyoidhinishwa, operesheni ya Requests inaweza kuchagua kifurushi cha CA kinachokusudiwa:

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

Hapa routes ni ramani iliyopo ya proksi ya programu. Njia lazima itaje kifurushi sahihi cha uaminifu kinachosomeka kwa mteja huyu. Si cheti cha tovuti kilichopakuliwa na kuchaguliwa kwa sababu tu muunganisho umeshindikana.

Kigezo cha mazingira REQUESTS_CA_BUNDLE ni pembejeo nyingine ya uaminifu inayotumika. Angalia njia halisi ya kutuma ikiwa inaonekana haina matokeo; mikondo ya maombi yaliyoandaliwa na mipangilio dhahiri inaweza kubadilisha jinsi usanidi wa mazingira unavyounganishwa.

Hupaswi kuhitaji ufunguo wa faragha wa CA

Cheti cha CA cha umma ndicho mteja anahitaji ili kutambua mtoaji aliyedhinishwa. Ufunguo wake wa faragha wa kusaini ni siri yenye nguvu ya upande mwingine. Haupaswi kusambazwa kwa watumiaji wa programu kama sehemu ya ukarabati wa kawaida wa uaminifu wa proksi.

Cheti cha mteja kinaweza bado kuhitajika na lengwa fulani au na uhusiano mwingine wa TLS uliosanidiwa kando. Hilo ni hitaji tofauti, si kitu kinachokisiwa kutoka kwa kila hitilafu ya uthibitishaji wa cheti.

Hitilafu inayofuata inapoonekana, taja operesheni: kupakia faili ya CA, kuthibitisha cheti cha upande mwingine, au kuwasilisha utambulisho wa mteja. Kuhamisha faili kati ya verify na cert hadi ujumbe ubadilike si njia ya kuaminika ya kuchagua jukumu lake.

Makala zinazohusiana