Python prosi o wyrzucenie SSLError

Pracuję nad prostym skryptem, który obejmuje CAS, kontrolę bezpieczeństwa jspring, przekierowanie itp. Chciałbym skorzystać z zapytań Kennetha Reitza, ponieważ to świetna robota! Jednak CAS wymaga potwierdzenia przez SSL, więc najpierw muszę przejść ten krok. Nie wiem, czego żąda Python? Gdzie powinien znajdować się ten certyfikat 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

Problem, który masz, jest spowodowany niezaufanym certyfikatem SSL.

Podobnie jak @dirk wspomniany w poprzednim komentarzu, najszybszą poprawką jest ustawienie verify=False:

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

Pamiętaj, że spowoduje to, że certyfikat nie zostanie zweryfikowany. Narazi to twoją aplikację na zagrożenia bezpieczeństwa, takie jak ataki typu man-in-the-middle.

Oczywiście zastosuj osąd. Jak wspomniano w komentarzach, może to być akceptowalne w przypadku aplikacji / skryptów szybkich / odrzucanych, ale tak naprawdę nie powinno iść do oprogramowania produkcyjnego .

Jeśli pominięcie sprawdzania certyfikatu jest niedopuszczalne w twoim konkretnym kontekście, rozważ następujące opcje, najlepszą opcją jest ustawienie verifyparametru na ciąg znaków, który jest ścieżką do .pempliku certyfikatu (który należy uzyskać w pewien sposób bezpieczny znaczy).

Tak więc, począwszy od wersji 2.0, verifyparametr akceptuje następujące wartości wraz z ich odpowiednią semantyką:

• True: powoduje sprawdzanie poprawności certyfikatu w oparciu o własne zaufane urzędy certyfikacji biblioteki (Uwaga: możesz zobaczyć, których żądań Root Certificates Requests używa za pośrednictwem biblioteki Certifi, zaufanej bazy danych RC wyodrębnionej z Requests: Certifi - Trust Database for Humans ).
• False: całkowicie pomija walidację certyfikatu .
• Ścieżka do pliku CA_BUNDLE dla żądań do sprawdzania poprawności certyfikatów.

Źródło: Żądania - weryfikacja certyfikatu SSL

Spójrz również na certparametr tego samego linku.

Z dokumentacji wniosków o weryfikację SSL :

Żądania mogą weryfikować certyfikaty SSL dla żądań HTTPS, podobnie jak przeglądarka internetowa. Aby sprawdzić certyfikat SSL hosta, możesz użyć argumentu weryfikującego:

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

Jeśli nie chcesz weryfikować certyfikatu SSL, zrób verify=False

Nazwa pliku CA, który chcesz użyć, możesz przekazać verify:

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

Jeśli używasz verify=Truenastępnie requestsużywa własnego zestawu CA, które mogą nie certyfikacji, który podpisał certyfikat serwera.

$ pip install -U requests[security]

• Testowane na Python 2.7.6 @ Ubuntu 14.04.4 LTS
• Testowane na Python 2.7.5 @ MacOSX 10.9.5 (Mavericks)

Po otwarciu tego pytania (2012-05) wersja Żądania miała wersję 0.13.1. W wersji 2.4.1 (2014-09) wprowadzono dodatki „bezpieczeństwa”, używając certifipakietu, jeśli jest dostępny.

W tej chwili (2016-09) główną wersją jest 2.11.1, bez której działa dobrze verify=False. Nie trzeba używać requests.get(url, verify=False), jeśli jest zainstalowany z requests[security]dodatkami.

Napotkałem ten sam problem i weryfikacja certyfikatu ssl nie powiodła się podczas używania aws boto3, sprawdzając kod boto3, znalazłem, że REQUESTS_CA_BUNDLEnie jest ustawiony, więc naprawiłem oba problemy ustawiając go ręcznie:

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')

W przypadku aws-cli, myślę, że ustawienie REQUESTS_CA_BUNDLE ~/.bashrcnaprawi ten problem (nie przetestowano, ponieważ moja aws-cli działa bez niego).

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

Jeśli masz bibliotekę, na której się opierasz, requestsi nie możesz zmodyfikować ścieżki weryfikacji (jak w przypadku pyvmomi), musisz znaleźć cacert.pempakiet z żądaniami i dołączyć do niego swój urząd certyfikacji. Oto ogólne podejście do znalezienia cacert.pemlokalizacji:

Windows

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, łączenie własnych cacert z żądaniem jest naprawdę, bardzo denerwujące ... szczególnie fakt, że nie wydaje się, abyś najpierw używał systemu ca store i nie jest to nigdzie udokumentowane.

aktualizacja

w sytuacjach, w których korzystasz z biblioteki i nie masz kontroli nad lokalizacją pakietu ca, możesz również jawnie ustawić lokalizację pakietu ca na pakiet całego hosta:

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

Mam ten sam problem przy użyciu gspread i te polecenia działają dla mnie:

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

Jeśli chcesz usunąć ostrzeżenia, użyj poniższego kodu.

import urllib3

urllib3.disable_warnings()

i za verify=Falsepomocą request.getlub postmetody

Znalazłem konkretne podejście do rozwiązania podobnego problemu. Chodzi o wskazanie pliku cacert przechowywanego w systemie i wykorzystywanego przez inne aplikacje oparte na ssl.

W Debianie (nie jestem pewien, czy tak samo jest w innych dystrybucjach) pliki certyfikatów (.pem) są przechowywane w /etc/ssl/certs/Tak więc to jest kod, który działa dla mnie:

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

Aby zgadnąć, który pemplik wybrać, przejrzałem adres URL i sprawdziłem, który urząd certyfikacji (CA) wygenerował certyfikat.

EDYCJA: jeśli nie możesz edytować kodu (ponieważ korzystasz z trzeciej aplikacji), możesz spróbować dodać pemcertyfikat bezpośrednio do /usr/local/lib/python2.7/dist-packages/requests/cacert.pem(np. Skopiować go na koniec pliku).

Jeśli nie przejmujesz się certyfikatem, skorzystaj z niego verify=False.

import requests

url = "Write your url here"

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

Po godzinach debugowania mogłem to uruchomić tylko przy użyciu następujących pakietów:

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

za pomocą OpenSSL 1.0.2g 1 Mar 2016

Bez tych pakietów verify=Falsenie działał.

Mam nadzieję, że to komuś pomoże.

Natrafiłem na ten sam problem. Okazuje się, że nie zainstalowałem certyfikatu pośredniego na moim serwerze (wystarczy dołączyć go do dolnej części certyfikatu, jak pokazano poniżej).

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

Upewnij się, że masz zainstalowany pakiet certyfikatów ca:

sudo apt-get install ca-certificates

Aktualizacja czasu może rozwiązać ten problem:

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

Jeśli używasz samopodpisanego certyfikatu, prawdopodobnie będziesz musiał ręcznie dodać go do systemu.

Jeśli wywołania żądań są zakopane gdzieś głęboko w kodzie i nie chcesz instalować certyfikatu serwera, to tylko w celach debugowania możliwe jest monitorowanie żądań małp:

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!')

Nigdy nie używaj w produkcji!

Chyba za późno na przyjęcie, ale chciałem wkleić poprawkę dla innych wędrowców takich jak ja! Więc dla mnie działało w Pythonie 3.7.x

Wpisz następujące dane w swoim terminalu

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

Spróbuj ponownie uruchomić skrypt / żądania i sprawdź, czy działa (jestem pewien, że nie zostanie jeszcze naprawiony!). Jeśli to nie zadziałało, spróbuj bezpośrednio uruchomić następującą komendę w terminalu

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

Walczyłem z tym problemem przez HOURS.

Próbowałem zaktualizować żądania. Następnie zaktualizowałem certyfikat. Wskazałem weryfikację na certifi.where () (kod i tak domyślnie to robi). Nic nie działało.

W końcu zaktualizowałem moją wersję Pythona do Pythona 2.7.11. Byłem w Pythonie 2.7.5, który miał pewne niezgodności ze sposobem weryfikacji certyfikatów. Po zaktualizowaniu Pythona (i kilku innych zależności) zaczął działać.

Jest to podobne do odpowiedzi @ rafael-almeida, ale chcę zauważyć, że od żądań 2.11+ nie ma 3 wartości, które verifymożna przyjąć, w rzeczywistości są to 4:

• True: sprawdza poprawność względem wewnętrznych zaufanych urzędów certyfikacji żądań.
• False: całkowicie pomija walidację certyfikatu . (Niepolecane)
• Ścieżka do pliku CA_BUNDLE. żądania wykorzystają to do sprawdzenia poprawności certyfikatów serwera.
• Ścieżka do katalogu zawierającego publiczne pliki certyfikatów. żądania wykorzystają to do sprawdzenia poprawności certyfikatów serwera.

Reszta mojej odpowiedzi dotyczy nr 4, jak używać katalogu zawierającego certyfikaty do sprawdzania poprawności:

Uzyskaj potrzebne certyfikaty publiczne i umieść je w katalogu.

Ściśle mówiąc, prawdopodobnie „powinieneś” skorzystać z pozapasmowej metody uzyskiwania certyfikatów, ale możesz też po prostu pobrać je za pomocą dowolnej przeglądarki.

Jeśli serwer używa łańcucha certyfikatów, pamiętaj, aby uzyskać każdy pojedynczy certyfikat w łańcuchu.

Zgodnie z dokumentacją żądań katalog zawierający certyfikaty musi być najpierw przetworzony za pomocą narzędzia „rehash” ( openssl rehash).

(Wymaga to openssl 1.1.1+ i nie wszystkie implementacje openssl dla systemu Windows obsługują ponowne użycie. Jeśli openssl rehashto nie zadziała, możesz spróbować uruchomić skrypt ruby ponownego otwierania na https://github.com/ruby/openssl/blob/master /sample/c_rehash.rb , chociaż nie próbowałem tego.)

Miałem problem z otrzymywaniem próśb o rozpoznanie moich certyfikatów, ale po użyciu openssl x509 -outform PEMpolecenia do konwersji certyfikatów do .pemformatu Base64 wszystko działało idealnie.

Możesz też po prostu zrobić leniwe powtórzenie:

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")

W module żądań występuje obecnie błąd powodujący ten błąd, obecny w wersjach od 2.6.2 do 2.12.4 (ATOW): https://github.com/kennethreitz/requests/issues/2573

Obejściem tego problemu jest dodanie następującego wiersza: 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'

Jak wspomniał @Rafael Almeida, twój problem jest spowodowany niezaufanym certyfikatem SSL. W moim przypadku certyfikat SSL nie był zaufany przez mój serwer. Aby obejść ten problem bez narażania bezpieczeństwa, pobrałem certyfikat i zainstalowałem go na serwerze (wystarczy dwukrotnie kliknąć plik .crt, a następnie zainstalować certyfikat ...).

Dodanie opcji nie jest możliwe, jeśli żądania są wywoływane z innego pakietu. W takim przypadku dodanie certyfikatów do pakietu cacert jest prostą ścieżką, np. Musiałem dodać „StartCom Class 1 Primary Intermediate Server CA”, dla którego pobrałem certyfikat główny do StartComClass1.pem. biorąc pod uwagę, że moja virtualenv nazywa się caldav, dodałem certyfikat z:

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

jeden z nich może wystarczyć, nie sprawdziłem

Miałem podobny lub taki sam problem z weryfikacją certyfikacji. Przeczytałem, że wersje OpenSSL mniejsze niż 1.0.2, których żądania zależą czasem od problemów z weryfikacją silnych certyfikatów (patrz tutaj ). Wydaje się, że CentOS 7 używa wersji 1.0.1e, która wydaje się mieć problem.

Nie byłem pewien, jak obejść ten problem na CentOS, więc postanowiłem pozwolić na słabsze 1024-bitowe certyfikaty CA.

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

Musiałem uaktualnić z Python 3.4.0 do 3.4.6

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

W moim przypadku powód był dość trywialny.

Wiedziałem, że weryfikacja SSL działała do kilku dni wcześniej i faktycznie działała na innej maszynie.

Moim następnym krokiem było porównanie zawartości i rozmiaru certyfikatu między komputerem, na którym działała weryfikacja, a tym, na którym nie była.

To szybko doprowadziło mnie do stwierdzenia, że ​​certyfikat na „niepoprawnie” działającej maszynie nie był dobry, a kiedy zastąpiłem go „dobrym” certyfikatem, wszystko było w porządku.