Python Requests: CA пакети припадају у verify, а не у cert

Ставите одобрени CA материјал поверења у конфигурацију провере уместо да грешку сертификата третирате као захтев за приватним кључем клијента.

Колега вам даје CA сертификат организације. Requests нуди параметар под називом cert. Имена изгледају као пар, али одговарају на различита питања.

ПоставкаСврха
verifyБира материјал поверења који се користи за проверу друге стране
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 док се порука не промени није поуздан начин да изаберете њену улогу.

Повезани чланци