it-swarm.com.de

Python-Anfragen werfen SSLError

Ich arbeite an einem einfachen Skript, das CAS, Jspring-Sicherheitsüberprüfung, Umleitung usw. umfasst. Ich würde gerne die Python-Anfragen von Kenneth Reitz verwenden, da dies eine großartige Arbeit ist! CAS erfordert jedoch eine Validierung über SSL, so dass ich diesen Schritt zuerst überwinden muss. Ich weiß nicht, was Python-Anfragen haben? Wo soll sich dieses SSL-Zertifikat befinden?

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
252
TedBurrows

Das Problem, das Sie haben, wird durch ein nicht vertrauenswürdiges SSL-Zertifikat verursacht.

Wie in einem früheren Kommentar von @dirk erwähnt, setzt der schnellste -Pflege verify=False:

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

Bitte beachten Sie, dass das Zertifikat dadurch nicht verifiziert wird. Dadurch wird Ihre Anwendung Sicherheitsrisiken ausgesetzt, z. B. Man-in-the-Middle-Angriffen. 

Natürlich Urteilsvermögen anwenden. Wie in den Kommentaren erwähnt, ist dieses kann für schnelle/wegwerfende Anwendungen/Skripte akzeptabel, sollte aber nicht zur Produktionssoftware gehen

Wenn das Überspringen der Zertifikatsüberprüfung in Ihrem Kontext nicht akzeptabel ist, sollten Sie die folgenden Optionen in Betracht ziehen. Die beste Option besteht darin, den Parameter verify auf eine Zeichenfolge zu setzen, die den Pfad der .pem-Datei des Zertifikats darstellt (die Sie irgendwie abrufen sollten von sicheren Mitteln).

Ab Version 2.0 akzeptiert der Parameter verify die folgenden Werte mit ihrer jeweiligen Semantik:

  • True: bewirkt, dass das Zertifikat anhand der vertrauenswürdigen Zertifizierungsstellen der Bibliothek validiert wird (Hinweis: Sie können über die Certifi-Bibliothek, eine aus den Requests extrahierte Vertrauensdatenbank von RCs, welche Stammzertifikatsanforderungen verwendet werden, sehen: Certifi - Vertrauensdatenbank für Menschen ) .
  • False: Umgeht die Zertifikatsüberprüfung vollständig.
  • Pfad zu einer CA_BUNDLE-Datei, in der Anforderungen zur Überprüfung der Zertifikate verwendet werden.

Quelle: Anfragen - SSL-Zertifizierungsprüfung

Schauen Sie sich auch den Parameter cert unter demselben Link an.

322
Rafael Almeida

Aus Anfragen Dokumentation zur SSL-Verifizierung :

Anfragen können SSL-Zertifikate für HTTPS-Anfragen wie einen Webbrowser überprüfen. Um das SSL-Zertifikat eines Hosts zu überprüfen, können Sie das Überprüfungsargument verwenden:

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

Wenn Sie Ihr SSL-Zertifikat nicht überprüfen möchten, geben Sie verify=False an. 

96
Boud

Der Name der zu verwendenden CA-Datei könnte über verify übergeben werden:

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

Wenn Sie verify=True verwenden, verwendet requests einen eigenen Zertifizierungsstellensatz, der möglicherweise keine Zertifizierungsstelle hat, die Ihr Serverzertifikat signiert hat.

44
jfs

$ pip install -U requests[security]

  • Getestet auf Python 2.7.6 @ Ubuntu 14.04.4 LTS
  • Getestet auf Python 2.7.5 @ MacOSX 10.9.5 (Mavericks)

Als diese Frage geöffnet wurde (2012-05), war die Version von Requests 0.13.1. In Version 2.4.1 (2014-09) wurden die "Sicherheits" -Extras eingeführt, wobei das Paket certifi verwendet wurde, falls verfügbar. 

Im Moment (2016-09) ist die Hauptversion 2.11.1, das funktioniert gut ohneverify=False. Bei requests[security]-Extras muss requests.get(url, verify=False) nicht verwendet werden.

30
alanjds

Ich bin auf dasselbe Problem gestoßen, und das SSL-Zertifikat konnte nicht überprüft werden, wenn aws boto3 verwendet wurde. Ich habe festgestellt, dass REQUESTS_CA_BUNDLE nicht festgelegt ist. Ich habe das Problem behoben, indem ich es manuell eingestellt habe:

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

Bei aws-cli denke ich, dass die Einstellung von REQUESTS_CA_BUNDLE in ~/.bashrc dieses Problem behebt (nicht getestet, da mein aws-cli ohne es funktioniert).

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

Falls Sie über eine Bibliothek verfügen, die auf requests angewiesen ist und Sie den Überprüfungspfad nicht ändern können (wie bei pyvmomi), müssen Sie den mit Anforderungen gebündelten cacert.pem finden und Ihre Zertifizierungsstelle dort anhängen. Hier ist ein allgemeiner Ansatz, um den cacert.pem-Speicherort zu finden:

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)
[email protected]:~/# python -c "import requests; print requests.certs.where()"
/usr/lib/python2.7/dist-packages/certifi/cacert.pem

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

Übrigens @ request-devs, das Bündeln eigener Cacerts mit Anfrage ist wirklich sehr ärgerlich ... vor allem die Tatsache, dass Sie das System ca nicht zuerst zu speichern scheinen und dies nirgends dokumentiert ist.

Update

in Situationen, in denen Sie eine Bibliothek verwenden und keine Kontrolle über den Speicherort des ca-Bundles haben, können Sie den ca-Bundle-Speicherort auch explizit als Ihr hostweites ca-Bundle festlegen:

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

Ich habe das gleiche Problem mit gspread und diese Befehle funktionieren für mich:

Sudo pip uninstall -y certifi
Sudo pip install certifi==2015.04.28
13
user941581

Wenn Sie die Warnungen entfernen möchten, verwenden Sie den folgenden Code.

import urllib3

urllib3.disable_warnings()

und verify=False mit der request.get- oder post-Methode

10
AniketGole

Ich habe einen spezifischen Ansatz gefunden, um ein ähnliches Problem zu lösen. Die Idee ist, auf die im system gespeicherte Cacert-Datei zu zeigen, die von anderen auf SSL basierenden Anwendungen verwendet wird.

In Debian (ich bin nicht sicher, ob es in anderen Distributionen gleich ist) werden die Zertifikatsdateien (.pem) unter /etc/ssl/certs/ gespeichert. Dies ist also der Code, der für mich funktioniert:

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

Um zu erraten, welche pem-Datei gewählt wird, muss ich zur URL navigieren und prüfen, welche Zertifizierungsstelle (CA) das Zertifikat generiert hat.

BEARBEITEN: Wenn Sie den Code nicht bearbeiten können (weil Sie eine dritte App ausführen), können Sie versuchen, das pem-Zertifikat direkt in /usr/local/lib/python2.7/dist-packages/requests/cacert.pem hinzuzufügen (z. B. durch Kopieren an das Ende der Datei).

10
chk

Wenn Sie sich nicht um ein Zertifikat kümmern, verwenden Sie einfach verify=False.

import requests

url = "Write your url here"

returnResponse = requests.get(url, verify=False)
9
yogesh prasad

Nach stundenlangem Debugging konnte ich dies nur mit den folgenden Paketen zum Laufen bringen:

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

OpenSSL 1.0.2g 1 Mar 2016 verwenden

Ohne diese Pakete funktionierte verify=False nicht.

Ich hoffe das hilft jemandem.

7
michael

Ich bin auf die gleiche Ausgabe gestoßen. Es stellte sich heraus, dass ich das Zwischenzertifikat nicht auf meinem Server installiert hatte (hängen Sie es einfach an das Ende Ihres Zertifikats, wie unten gezeigt).

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

Stellen Sie sicher, dass Sie das CA-Zertifikate-Paket installiert haben:

Sudo apt-get install ca-certificates

Das Aktualisieren der Uhrzeit kann dies ebenfalls beheben:

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

Wenn Sie ein selbstsigniertes Zertifikat verwenden, müssen Sie es möglicherweise manuell zu Ihrem System hinzufügen.

5

Ich habe dieses Problem stundenlang bekämpft. 

Ich habe versucht, Anfragen zu aktualisieren. Dann habe ich certifi aktualisiert. Ich habe auf certifi.where () verwiesen (der Code tut dies standardmäßig). Nichts hat geklappt.

Schließlich habe ich meine Version von Python auf Python 2.7.11 aktualisiert. Ich war auf Python 2.7.5, das einige Inkompatibilitäten mit der Art der Überprüfung der Zertifikate hatte. Nachdem ich Python (und einige andere Abhängigkeiten) aktualisiert hatte, begann es zu funktionieren.

3
ajon

Derzeit ist im Anforderungsmodul ein Problem aufgetreten, das zu diesem Fehler geführt hat und in v2.6.2 bis v2.12.4 (ATOW) vorhanden ist: https://github.com/kennethreitz/requests/issues/2573

Umgehung für dieses Problem ist das Hinzufügen der folgenden Zeile: 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'

2
Peter

Zu spät zur Party, denke ich, aber ich wollte den Fix für andere Wanderer wie mich selbst einfügen! Das Folgende ist für mich auf Python 3.7.x ausgefallen

Geben Sie Folgendes in Ihr Terminal ein 

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

Versuchen Sie, Ihr Skript/Ihre Anforderungen erneut auszuführen, und prüfen Sie, ob es funktioniert (Ich bin mir sicher, dass es noch nicht behoben ist!) Wenn es nicht funktioniert hat, führen Sie den folgenden Befehl direkt im Terminal aus

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

Wie von @Rafael Almeida erwähnt, wird das Problem, das Sie haben, durch ein nicht vertrauenswürdiges SSL-Zertifikat verursacht. In meinem Fall wurde das SSL-Zertifikat von meinem Server nicht als vertrauenswürdig eingestuft. Um dies zu umgehen, ohne die Sicherheit zu beeinträchtigen, habe ich heruntergeladenes Zertifikat installiert und auf dem Server installiert (einfach auf die .crt-Datei doppelklicken und dann Zertifikat installieren ...).

1
Michael

Wenn die Anforderungsaufrufe irgendwo tief im Code vergraben sind und Sie das Serverzertifikat nicht installieren möchten, können Sie nur zu debug-Zwecken die Anforderungen abfragen:

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

Niemals in der Produktion verwenden!

1
xmedeko

In meinem Fall war der Grund ziemlich trivial.

Ich hatte gewusst, dass die SSL-Überprüfung bis einige Tage zuvor funktioniert hatte und tatsächlich auf einem anderen Computer funktionierte.

Mein nächster Schritt bestand darin, den Inhalt und die Größe des Zertifikats zwischen dem Computer, auf dem die Überprüfung ausgeführt wurde, und dem Computer, auf dem sie nicht ausgeführt wurde, zu vergleichen.

Dies führte schnell dazu, dass ich feststellte, dass das Zertifikat auf der "falsch" arbeitenden Maschine nicht gut war, und als ich es durch das "gute" Zertifikat ersetzte, war alles in Ordnung.

0

Es ist nicht möglich, Optionen hinzuzufügen, wenn Anforderungen aus einem anderen Paket aufgerufen werden. In diesem Fall ist das Hinzufügen von Zertifikaten zum Paketpaket der direkte Weg, z. Ich musste "StartCom Class 1 Primary Intermediate Server CA" hinzufügen, für das ich das Root-Zertifikat in StartComClass1.pem heruntergeladen habe. da meine virtualenv caldav heißt, fügte ich das Zertifikat hinzu mit:

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

eine davon könnte ausreichen, habe ich nicht überprüft

0
rhoerbe

Ich hatte ein ähnliches oder dasselbe Zertifizierungsvalidierungsproblem. Ich habe gelesen, dass OpenSSL-Versionen kleiner als 1.0.2 sind. Bei Anfragen ist es manchmal schwierig, starke Zertifikate zu überprüfen (siehe hier ). CentOS 7 scheint 1.0.1e zu verwenden, was das Problem zu haben scheint. 

Ich war mir nicht sicher, wie ich dieses Problem unter CentOS umgehen könnte, also beschloss ich, schwächere 1024-Bit-CA-Zertifikate zuzulassen. 

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

Ich musste ein Upgrade von Python 3.4.0 auf 3.4.6 durchführen

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