Python Requests. CA փաթեթների տեղը verify-ում է, ոչ cert-ում

Գործընկերը ձեզ տալիս է կազմակերպության CA սերտիֆիկատը։ Requests-ը առաջարկում է cert անունով պարամետր։ Անունները նման են զույգի, բայց դրանք պատասխանում են տարբեր հարցերի։

Հաստատված միջամտող CA-ի համար Requests գործողությունը կարող է ընտրել նախատեսված CA փաթեթը՝

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

Այստեղ routes հավելվածի առկա պրոքսի քարտեզն է։ Ուղին պետք է նշի այս հաճախորդի համար ճիշտ ընթեռնելի վստահության փաթեթը։ Սա ներբեռնված կայքի սերտիֆիկատ չէ, որն ընտրվել է միայն այն պատճառով, որ կապը ձախողվել է։

REQUESTS_CA_BUNDLE միջավայրի փոփոխականը ևս մեկ աջակցվող վստահության մուտք է։ Ստուգեք իրական ուղարկման ուղին, եթե այն անարդյունավետ է թվում. պատրաստված հարցումների աշխատահոսքերը և բացահայտ կարգավորումները կարող են փոխել, թե ինչպես է միավորվում միջավայրի կոնֆիգուրացիան։

Ձեզ չպետք է անհրաժեշտ լինի CA-ի գաղտնի բանալին

Հանրային CA սերտիֆիկատն այն է, ինչ հաճախորդին պետք է հաստատված թողարկողին ճանաչելու համար։ Դրա ստորագրման գաղտնի բանալին մեկ այլ կողմի հզոր գաղտնիք է։ Այն չպետք է բաշխվի հավելվածի օգտատերերին որպես սովորական պրոքսի-վստահության վերանորոգման մաս։

Հաճախորդի սերտիֆիկատ դեռ կարող է պահանջվել որոշակի նպատակակետի կամ առանձին կարգավորված TLS հարաբերության կողմից։ Դա առանձին պահանջ է, ոչ թե ինչ-որ բան, որը ենթադրվում է սերտիֆիկատի ստուգման յուրաքանչյուր սխալից։

Երբ հայտնվի հաջորդ սխալը, անվանեք գործողությունը՝ CA ֆայլի բեռնում, կողմի սերտիֆիկատի ստուգում կամ հաճախորդի ինքնության ներկայացում։ Ֆայլը verify-ի և cert-ի միջև տեղափոխելը, մինչև հաղորդագրությունը փոխվի, նրա դերը ընտրելու վստահելի միջոց չէ։