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 до изменения сообщения не является надёжным способом выбрать его роль.