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, пакуль паведамленне не зменіцца, не з'яўляецца надзейным спосабам выбраць яго ролю.

Падобныя артыкулы