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 до зміни повідомлення не є надійним способом вибрати його роль.

Схожі статті