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, довірну базу даних РЦ, витягнуту з запитів: Certifi - база даних довіри для людей ).
• False: Обходить перевірку сертифіката повністю .
• Шлях до файлу CA_BUNDLE для запитів, які використовуються для перевірки сертифікатів.

Джерело: Запити - SSL Cert Verification

Також подивіться на certпараметр за тим же посиланням.

З запитів документації на перевірку SSL :

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

>>> 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, який може не мати ЦА, який підписав ваш серверний сертифікат.

$ 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комплекті запити та додати свій CA там. Ось загальний підхід до пошуку 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

linux

#  (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

btw. @ request-devs, зв'язування власних кекерів із запитом - це насправді, насправді дратує ... особливо той факт, що, здається, ви не спочатку користуєтесь системним магазином ca, і це ніде не зафіксовано.

оновлення

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

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) створив сертифікат.

EDIT: якщо ви не можете редагувати код (оскільки у вас працює третя програма), ви можете спробувати додати 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:

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

Я боровся з цією проблемою за HOURS.

Я намагався оновити запити. Потім я оновив сертифікати. Я вказав на verify.where () (Код все одно робить це за замовчуванням). Нічого не працювало.

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

Це схоже на відповідь @ rafael-almeida, але я хочу зазначити, що за запитами 2.11+, не verifyможна взяти 3 значення , насправді 4:

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

Решта моєї відповіді стосується №4, як використовувати каталог для підтвердження сертифікатів:

Отримайте необхідні публічні сертифікати та помістіть їх у каталог.

Строго кажучи, ви, ймовірно, повинні "використовувати" позадіапазонний метод отримання сертифікатів, але ви також можете просто завантажити їх за допомогою будь-якого браузера.

Якщо сервер використовує ланцюжок сертифікатів, обов'язково отримуйте кожен сертифікат у ланцюзі.

Згідно з документацією на запити, каталог, що містить сертифікати, спочатку повинен бути оброблений утилітою "повторного перегляду" ( openssl rehash).

(Це вимагає OpenSSL 1.1.1+, і не всі вікна підтримки реалізації OpenSSL переспіви. Якщо openssl rehashне працюватиме для вас, ви можете спробувати запустити рубіновий скрипт переспів на https://github.com/ruby/openssl/blob/master /sample/c_rehash.rb , хоча я цього не пробував.)

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

Ви також можете просто ліниво перебирати:

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/isissue/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 - це прямий шлях, наприклад, мені довелося додати "StartCom Class 1 Primary Intermediate Server CA", для якого я завантажив кореневу cert в 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 працювала до декількох днів раніше, і фактично працювала на іншій машині.

Наступним моїм кроком було порівняння вмісту та розміру сертифікату між машиною, на якій працює перевірка, та тією, на якій вона не була.

Це швидко призвело до того, що я визнав, що Сертифікат на "неправильно" працюючому верстаті був недобрим, і як тільки я замінив його на "хороший" серт, все було добре.