Python запрашивает выбрасывание SSLError

Я работаю над простым сценарием, который включает в себя CAS, проверку безопасности jspring, перенаправление и т. Д. Я хотел бы использовать запросы Python от Кеннета Рейтца, потому что это отличная работа! Тем не менее, CAS требует проверки через SSL, поэтому мне нужно сначала пройти этот шаг. Я не знаю, чего хотят запросы Python? Где должен находиться этот сертификат SSL?

Traceback (most recent call last):
  File "./test.py", line 24, in <module>
  response = requests.get(url1, headers=headers)
  File "build/bdist.linux-x86_64/egg/requests/api.py", line 52, in get
  File "build/bdist.linux-x86_64/egg/requests/api.py", line 40, in request
  File "build/bdist.linux-x86_64/egg/requests/sessions.py", line 209, in request 
  File "build/bdist.linux-x86_64/egg/requests/models.py", line 624, in send
  File "build/bdist.linux-x86_64/egg/requests/models.py", line 300, in _build_response
  File "build/bdist.linux-x86_64/egg/requests/models.py", line 611, in send
requests.exceptions.SSLError: [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Возникшая проблема связана с ненадежным сертификатом SSL.

Как и @dirk, упомянутый в предыдущем комментарии, самое быстрое исправление - установка verify=False:

requests.get('https://example.com', verify=False)

Обратите внимание, что это приведет к тому, что сертификат не будет проверен. Это подвергнет ваше приложение угрозам безопасности, таким как атаки «человек посередине».

Конечно, применять суждение. Как упоминалось в комментариях, это может быть приемлемо для быстрых / одноразовых приложений / скриптов, но на самом деле не должно переходить на производственное программное обеспечение .

Если просто пропустить проверку сертификата в вашем конкретном контексте недопустимо, рассмотрите следующие варианты, лучше всего установить verifyпараметр в строку, которая является путем к.pem файлу сертификата (который вы должны получить с помощью какого-либо безопасного средства).

Таким образом, начиная с версии 2.0, verifyпараметр принимает следующие значения с соответствующей семантикой:

• True: проверяет сертификат на соответствие собственным доверенным центрам сертификации библиотеки (Примечание: вы можете увидеть, какие запросы корневых сертификатов используются через библиотеку Certifi, базу данных доверенных сертификатов RC, извлеченную из запросов: Certifi - Trust Database for Humans ).
• False: Обходит проверку сертификата полностью .
• Путь к файлу CA_BUNDLE для запросов, используемых для проверки сертификатов.

Источник: Запросы - Проверка SSL сертификата

Также взгляните на certпараметр по той же ссылке.

Из запросов документации по проверке SSL :

Запросы могут проверять сертификаты SSL для запросов HTTPS, как веб-браузер. Чтобы проверить SSL-сертификат хоста, вы можете использовать аргумент verify:

>>> requests.get('https://kennethreitz.com', verify=True)

Если вы не хотите подтверждать свой SSL-сертификат, сделайте verify=False

Имя файла CA для использования вы можете передать через verify:

cafile = 'cacert.pem' # http://curl.haxx.se/ca/cacert.pem
r = requests.get(url, verify=cafile)

Если вы используете, verify=Trueто requestsиспользует свой собственный набор CA, который может не иметь CA, который подписал ваш сертификат сервера.

$ pip install -U requests[security]

• Протестировано на Python 2.7.6 @ Ubuntu 14.04.4 LTS
• Протестировано на Python 2.7.5 @ MacOSX 10.9.5 (Mavericks)

Когда этот вопрос был открыт (2012-05), версия запросов была 0.13.1. В версии 2.4.1 (2014-09) дополнительные функции безопасности были введены с использованиемcertifi пакет, если он доступен.

Прямо сейчас (2016-09) основной версией является 2.11.1, которая хорошо работает без verify=False . Не нужно использовать requests.get(url, verify=False), если установлено с requests[security]дополнениями.

Я столкнулся с той же самой проблемой, и ssl сертификат проверяет проблему с ошибкой при использовании aws boto3, просмотрев код boto3, я обнаружил, что REQUESTS_CA_BUNDLEона не установлена, поэтому я исправил обе проблемы, установив ее вручную:

from boto3.session import Session
import os

# debian
os.environ['REQUESTS_CA_BUNDLE'] = os.path.join(
    '/etc/ssl/certs/',
    'ca-certificates.crt')
# centos
#   'ca-bundle.crt')

Для aws-cli, я полагаю, установка REQUESTS_CA_BUNDLE в ~/.bashrcисправит эту проблему (не проверялось, потому что мой aws-cli работает без него).

REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt # ca-bundle.crt
export REQUESTS_CA_BUNDLE

В случае, если у вас есть библиотека, на которую requestsвы полагаетесь, и вы не можете изменить путь проверки (например, с помощью pyvmomi), вам придется найти cacert.pemпакет с запросами и добавить туда свой ЦС. Вот общий подход к поиску cacert.pemместоположения:

окна

C:\>python -c "import requests; print requests.certs.where()"
c:\Python27\lib\site-packages\requests-2.8.1-py2.7.egg\requests\cacert.pem

линукс

#  (py2.7.5,requests 2.7.0, verify not enforced)
root@host:~/# python -c "import requests; print requests.certs.where()"
/usr/lib/python2.7/dist-packages/certifi/cacert.pem

#  (py2.7.10, verify enforced)
root@host:~/# python -c "import requests; print requests.certs.where()"
/usr/local/lib/python2.7/dist-packages/requests/cacert.pem

Кстати. @ questions-devs, связывание ваших собственных cacerts с запросом действительно очень раздражает ... особенно тот факт, что вы, кажется, не используете систему ca store в первую очередь, и это нигде не задокументировано.

Обновить

в ситуациях, когда вы используете библиотеку и не можете контролировать местоположение ca-bundle, вы также можете явно установить местоположение ca-bundle в качестве вашего ca-bundle для всего хоста:

REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-bundle.crt python -c "import requests; requests.get('https://somesite.com';)"

Я сталкиваюсь с той же проблемой, используя gspread, и эти команды работают для меня:

sudo pip uninstall -y certifi
sudo pip install certifi==2015.04.28

Если вы хотите удалить предупреждения, используйте код ниже.

import urllib3

urllib3.disable_warnings()

и verify=Falseс request.getили postметодом

Я нашел конкретный подход для решения аналогичной проблемы. Идея заключается в указании файла cacert, хранящегося в системе и используемого другими приложениями на основе ssl.

В Debian (я не уверен, что то же самое в других дистрибутивах) файлы сертификатов (.pem) хранятся в /etc/ssl/certs/Итак, вот код, который работает для меня:

import requests
verify='/etc/ssl/certs/cacert.org.pem'
response = requests.get('https://lists.cacert.org', verify=verify)

Чтобы угадать, какой pemфайл выбрать, я просматриваю URL и проверяю, какой центр сертификации (CA) сгенерировал сертификат.

РЕДАКТИРОВАТЬ: если вы не можете редактировать код (поскольку вы запускаете третье приложение), вы можете попытаться добавить pemсертификат непосредственно /usr/local/lib/python2.7/dist-packages/requests/cacert.pem(например, скопировать его в конец файла).

Если вы не беспокоитесь о сертификате, просто используйте verify=False.

import requests

url = "Write your url here"

returnResponse = requests.get(url, verify=False)

После нескольких часов отладки я смог заставить это работать, используя следующие пакеты:

requests[security]==2.7.0  # not 2.18.1
cryptography==1.9  # not 2.0

с помощью OpenSSL 1.0.2g 1 Mar 2016

Без этих пакетов verify=Falseне работало.

Я надеюсь, что это поможет кому-то.

Я столкнулся с той же проблемой. Оказывается, я не установил промежуточный сертификат на своем сервере (просто добавьте его в конец вашего сертификата, как показано ниже).

https://www.digicert.com/ssl-support/pem-ssl-creation.htm

Убедитесь, что у вас установлен пакет ca-Certificates:

sudo apt-get install ca-certificates

Обновление времени также может решить эту проблему:

sudo apt-get install ntpdate
sudo ntpdate -u ntp.ubuntu.com

Если вы используете самозаверяющий сертификат, вам, вероятно, придется добавить его в вашу систему вручную.

Если вызовы запросов скрыты где-то глубоко в коде, и вы не хотите устанавливать сертификат сервера, то только для целей отладки можно выполнить запросы monkeypatch:

import requests.api
import warnings


def requestspatch(method, url, **kwargs):
    kwargs['verify'] = False
    return _origcall(method, url, **kwargs)

_origcall = requests.api.request
requests.api.request = requestspatch
warnings.warn('Patched requests: SSL verification disabled!')

Никогда не используйте в производстве!

Я полагаю, слишком поздно для вечеринки, но я хотел вставить исправление для таких странников, как я! Поэтому на Python 3.7.x у меня сложилось следующее

Введите следующее в вашем терминале

pip install --upgrade certifi      # hold your breath..

Попробуйте запустить ваш скрипт / запросы еще раз и посмотрите, работает ли он (я уверен, что он еще не будет исправлен!). Если это не сработало, попробуйте запустить следующую команду в терминале напрямую.

open /Applications/Python\ 3.6/Install\ Certificates.command  # please replace 3.6 here with your suitable python version

Я боролся с этой проблемой в течение ЧАСОВ.

Я пытался обновить запросы. Затем я обновил сертификат. Я указал check to certifi.where () (код делает это по умолчанию в любом случае). Ничего не получалось.

Наконец я обновил свою версию Python до Python 2.7.11. Я был на Python 2.7.5, у которого были некоторые несовместимости с способом проверки сертификатов. Как только я обновил Python (и несколько других зависимостей), он начал работать.

Это похоже на ответ @ rafael-almeida, но я хочу отметить, что по состоянию на запросы 2.11+ нет 3-х значений, которые verifyможно принять, на самом деле 4:

• True: проверяет соответствие внутренних доверенных ЦС запросов.
• False: Обходит проверку сертификата полностью . (Не рекомендуется)
• Путь к файлу CA_BUNDLE. запросы будут использовать это для проверки сертификатов сервера.
• Путь к каталогу, содержащему открытые файлы сертификатов. запросы будут использовать это для проверки сертификатов сервера.

Остальная часть моего ответа о # 4, как использовать каталог, содержащий сертификаты для проверки:

Получите необходимые публичные сертификаты и поместите их в каталог.

Строго говоря, вы, вероятно, «должны» использовать внеполосный метод получения сертификатов, но вы также можете просто загрузить их с помощью любого браузера.

Если сервер использует цепочку сертификатов, обязательно получите каждый отдельный сертификат в цепочке.

Согласно документации по запросам, каталог, содержащий сертификаты, должен сначала обрабатываться утилитой rehash (openssl rehash ).

(Для этого требуется openssl 1.1.1+, и не все реализации Windows openssl поддерживают перефразирование. Если у openssl rehashвас не получится, вы можете попробовать запустить скрипт rehash ruby ​​по адресу https://github.com/ruby/openssl/blob/master. /sample/c_rehash.rb , хотя я этого не пробовал.)

У меня были некоторые проблемы с получением запросов на распознавание моих сертификатов, но после того, как я использовал openssl x509 -outform PEM команду для преобразования сертификатов в .pemформат Base64 , все работало отлично.

Вы также можете просто сделать ленивую перефразировку:

try:
    # As long as the certificates in the certs directory are in the OS's certificate store, `verify=True` is fine.
    return requests.get(url, auth=auth, verify=True)
except requests.exceptions.SSLError:
    subprocess.run(f"openssl rehash -compat -v my_certs_dir", shell=True, check=True)
    return requests.get(url, auth=auth, verify="my_certs_dir")

В настоящее время существует проблема в модуле запросов, вызывающая эту ошибку, которая присутствует в версиях от v2.6.2 до v2.12.4 (ATOW): https://github.com/kennethreitz/requests/issues/2573

Обойти эту проблему можно, добавив следующую строку: requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS = 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'

Как упомянул @Rafael Almeida, проблема, с которой вы столкнулись, вызвана ненадежным сертификатом SSL. В моем случае SSL-сертификат не был доверен моему серверу. Чтобы обойти это без ущерба для безопасности, я скачал сертификат и установил его на сервере (просто дважды щелкнув файл .crt, а затем установите сертификат ...).

Невозможно добавить опции, если запросы вызываются из другого пакета. В этом случае добавление сертификатов в пакет cacert является прямым путем, например, мне пришлось добавить «Первичный промежуточный сервер CA класса StartCom Class 1», для которого я загрузил корневой сертификат в StartComClass1.pem. учитывая, что мой virtualenv называется caldav, я добавил сертификат с:

cat StartComClass1.pem >> .virtualenvs/caldav/lib/python2.7/site-packages/pip/_vendor/requests/cacert.pem
cat temp/StartComClass1.pem >> .virtualenvs/caldav/lib/python2.7/site-packages/requests/cacert.pem

одного из тех может хватить, я не проверял

У меня была похожая или та же проблема сертификации. Я читал, что версии OpenSSL менее 1.0.2, запросы которых зависят от того, иногда возникают проблемы при проверке надежных сертификатов (см. Здесь ). Кажется, что CentOS 7 использует 1.0.1e, которая, похоже, имеет проблему.

Я не был уверен, как обойти эту проблему в CentOS, поэтому я решил разрешить более слабые 1024-битные сертификаты CA.

import certifi # This should be already installed as a dependency of 'requests'
requests.get("https://example.com", verify=certifi.old_where())

Мне пришлось обновить с Python 3.4.0 до 3.4.6

pyenv virtualenv 3.4.6 myvenv
pyenv activate myvenv
pip install -r requirements.txt

В моем случае причина была довольно тривиальной.

Я знал, что проверка SSL работала несколько дней назад и фактически работала на другом компьютере.

Следующим моим шагом было сравнение содержимого и размера сертификата между машиной, на которой работала проверка, и той, на которой она не работала.

Это быстро привело меня к определению, что сертификат на «неправильно» работающей машине не был хорош, и как только я заменил его на «хороший» сертификат, все было хорошо.