У меня есть программа, которая успешно работает в моем файле user/virtualenv. Программа обращается к API с помощью requests. Для целей этого поста всю программу можно прочитать так:
requests.get("https://example.com")
Это прекрасно работает, когда я вызываю его из командной строки. Однако я пытаюсь заставить его работать под supervisord, и по какой-то причине, когда я делаю это таким образом, происходит сбой с ошибкой SSL, как показано ниже:
SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)")
Он использует того же пользователя, среду python, каталог и т. д. Любая идея, что еще проверить/что еще может быть причиной этого?
Обновлено: я думаю, что это может быть тип правила брандмауэра. Изучение этого варианта.
Да, если я добавляю verify=False, я получаю другую ошибку (как ни странно, 502 с сервера, несмотря на то, что он всегда возвращает 200 при нормальной работе. Кроме того, я не хочу добавлять verify=False в качестве долгосрочного решения, даже если оно работало, поскольку я хочу проверить сертификат.
Вы пытались понизить requests, как было предложено здесь?
Я этого не делал, но я думаю, что это как бы упускает из виду суть вопроса - почему это ведет себя по-другому при запуске под супервизором? Таким образом, любой обходной путь, включающий взлом запросов, похоже, не устраняет основную причину проблемы.






Доступны ли сертификаты SSL в среде супервизора? Я предполагаю, что вы используете request.certs, так что сертификаты там, где ожидается requests.certs.where()?
Итак, оказалось, что это был сетевой прокси. Машина, на которой я работал, использует прокси-сервер squid, и мне пришлось добавить следующую строку, чтобы установить правильные переменные среды в моей конфигурации супервизора, чтобы она работала:
environment=http_proxy=http://proxy.server:3128/,https_proxy=http://proxy.server:3128/
Вы пытались добавить
verify=Falseк вашему запросу:requests.get("https://example.com", verify=False)?