Requests: SSLError "bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],) with self-signed certificate

Erstellt am 10. Nov. 2017  ·  12Kommentare  ·  Quelle: psf/requests

Hallo. Ich versuche, mich mit https mit einem Server zu verbinden. Ich habe das Zertifikat, bei dem es sich um ein selbstsigniertes Zertifikat handelt, das im Überprüfungsparameter enthalten ist, aber das Ergebnis ist ein Fehler „Zertifikatsüberprüfung fehlgeschlagen“. Ich hatte vermutet, dass es damit zu tun hat, dass das Zertifikat selbst signiert ist (von Microsoft IIS), aber mit curl funktioniert das.
Vielen Dank im Voraus!

Dies ist die openssl-Ausgabe:

openssl s_client -showcerts -connect server:44300
CONNECTED(00000003)
depth=0 CN = server
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = server
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=server
   i:/CN=server
-----BEGIN CERTIFICATE-----
<certificate data here>
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=server
issuer=/CN=server
---
No client certificate CA names sent
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1477 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: CC4A000083B1E03B446416C9C0B16CBEAB79949E3CF5C936A309A6F92FA01364
    Session-ID-ctx:
    Master-Key: 798A570B0EC2A0CBB7C4C4DE6167E7579A92239942D869CD794B8BEBEA6EB5E492394634AD32665A8BB829DE1F3858D2
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1510329948
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

erwartetes Ergebnis

Ich erwarte, da sich das Zertifikat im Prüfparameter befindet, dass die Verbindung nicht fehlschlägt. Wenn ich dasselbe mit Curl außerhalb von Python versuche, funktioniert es:

curl https://server:44300 --cacert /usr/share/ca-certificates/server.crt
 HTTP/1.1 403 Forbidden
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Length: 1158
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Frame-Options: SAMEORIGIN
P3P: CP=None
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Allow-Headers: X-Requested-With,Content-Type
Access-Control-Allow-Credentials: true
Date: Fri, 10 Nov 2017 16:02:26 GMT

(Es schlägt fehl, aber nicht wegen Zertifikatsproblemen)

Tatsächliche Ergebnis

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "xxxxx/TestVirtualEnv/local/lib/python2.7/site-packages/requests/adapters.py", line 506, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='nlybstqvp4nb75n.code1.emi.philips.com', port=44300): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

Reproduktionsschritte

import requests
requests.get('https://server:44300', verify='/usr/share/ca-certificates/server.crt')

System Information

$ python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.1.3"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.12"
  },
  "platform": {
    "release": "4.10.0-38-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010007f",
    "version": "17.3.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}

Dieser Befehl ist nur für Requests v2.16.4 und höher verfügbar. Andernfalls,
Bitte geben Sie einige grundlegende Informationen zu Ihrem System an (Python-Version,
Betriebssystem usw.).

Hilfreichster Kommentar

Wenn Sie ein Anfänger des requests -Moduls in Python sind und einige Dinge tun möchten, die den Zugriff auf sichere Websites erfordern, besteht eine hohe Wahrscheinlichkeit, dass Sie durch diesen Fehler zum Scheitern verurteilt sind - Certificate verify failed und wie alle Programmieranfänger Sie wird versucht sein, auth = session.post( mysecureurl, verify=false) zu verwenden

Aber das ist eine sehr schlechte Praxis und wurde über viele SO-Posts entmutigt, aber Anfänger missbrauchen dies immer noch, weil der Fehler so blöd zu beheben ist.
Lassen Sie mich versuchen, etwas Licht in dieses Thema zu bringen.
Python(pip) und Conda und jede Python-basierte Software verwendet einen separaten Zertifikatsspeicher, genau wie alle Browser. Die Python-Requests-Bibliothek verwendet standardmäßig ihre eigene CA-Datei oder verwendet das Zertifikatpaket des certifi-Pakets, falls installiert. Außerdem verwendet pip im Gegensatz zu curl nicht die Systemzertifikate.
Daher müssen Sie für requests den Zertifikatsspeicher manuell über Conda oder Pip angeben.

Tldr;

  1. Exportieren Sie die gesamte .cer verschlüsselte Zertifikatskette mit einem Browser, wie in diesem erstaunlichen Blog , der hier gezeigt wird. Beachten Sie, dass es in diesem Blog nicht um conda certstore, sondern um git certstore geht, und es heißt nur, den Stamm zu exportieren, aber ich habe alle Zertifikatsketten in separate Dateien exportiert.
  2. Als nächstes installieren Sie certifi mit dem Befehl pip install certifi
  3. Überprüfen Sie den Standardpfad des Zertifikatspeichers von conda oder python:

import ssl
ssl.get_default_verify_paths() ODER
import certifi
certifi.where()

  1. Sobald Sie die Standarddatei cacert.pem gefunden haben, öffnen Sie diese (vorzugsweise in Notepad++) und hängen Sie das gesamte Zertifikat am Ende der Datei an. (Achten Sie auf die Zertifikatsabgrenzung -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- ). Speichern Sie die Datei und das war's.
    Oder wenn Sie Conda verwenden, verwenden Sie die Conda-Befehle:
    conda config --set ssl_verify <pathToYourFile>.crt
    (Mir ist aufgefallen, dass dieser Befehl Sachen in C:\Users\johndoe\.condarc aktualisiert)

  2. Verwenden Sie zur Bestätigung den folgenden Code:
    import certifi
    auth = session.post('https://mysecuresite.com/', cert=());

Wenn Sie Linux verwenden, können Sie über diesen Link auch benutzerdefinierte Cacerts in das systemweite oder Benutzerprofil ( .bashrc oder .bash_profile ) exportieren.

Alle 12 Kommentare

Übrigens, das ist Ubuntu 16.04

Dieser Fehler ist mit ziemlicher Sicherheit darauf zurückzuführen, dass das Zertifikat selbst in irgendeiner Weise ungültig ist. Können Sie bitte das PEM-codierte Zertifikat selbst bereitstellen?

Hallo. Danke für die schnelle Antwort. Das ist das Zertifikat:
-----ZERTIFIKAT BEGINNEN-----
MIID3TCCAsWgAwIBAgIIU/nMdlbWojMwDQYJKoZIhvcNAQELBQAwMDEuMCwGA1UE
AwwlTkxZQlNUUVZQNE5CNzVOLmNvZGUxLmVtaS5waGlsaXBzLmNvbTAeFw0xNzEx
MTAwMDAwMDBaFw0yNzExMTAwMDAwMDBaMDAxLjAsBgNVBAMMJU5MWUJTVFFWUDRO
Qjc1Ti5jb2RlMS5lbWkucGhpbGlwcy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQC3mzWep6k1/FbkzzoyZ8QBy/tE8adfwKvw80zaLL+car1bBZ9U
VIXs4es3babtjD3QJWP5/mwoBdIp8gvQkjA1X7RBNJZXbPz6hGR4eqaeRQLrFV9Y
TtB92MA9CDpCXfalCvzzO1jw3zvP1BHUdnTQEwSnnwtf/Ryaud+e7TDxGq8LThmc
glZgO8d2zaYpIjwWx92bXDF/qlqWBkH5mtKIkWow6Y71xz0Di62cFrMAPEGBjK3c
szpBa5Ttb9+SFtl16t2xDyCbiPFkoMW/4u3Husy/i18hLhEuQwZMHnWsocm+etZ4
8fDt5Bqhab8zC+LKS+Ll7qZdqMHzobeB6j5JAgMBAAGjgfowgfcwXwYDVR0jBFgw
VoAUGdJ3os9nPtTubuwcy1ugtDMdSMChNKQyMDAxLjAsBgNVBAMMJU5MWUJTVFFW
UDROQjc1Ti5jb2RlMS5lbWkucGhpbGlwcy5jb22CCFP5zHZW1qIzMB0GA1UdDgQW
BBQZ0neiz2c+1O5u7BzLW6C0Mx1IwDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIE
sDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwOwYDVR0RBDQwMoIlTkxZ
QlNUUVZQNE5CNzVOLmNvZGUxLmVtaS5waGlsaXBzLmNvbYIJbG9jYWxob3N0MA0G
CSqGSIb3DQEBCwUAA4IBAQC0MtflowNB4LTLKD1MW3w0QIY5ale3/sEhNCQgHGN5
iNZJptFuFt5jgPGmFjy0Pb5vLMS/Ag1RF3UgTeZzFnaSgyB4mTnwj1gLdwQidVcr
2SlL7TffCj0m/bYjtNbwExRqXE4pQKb5RKwYwpruZaX/G3oHWOG9+2X9Pw5C42zB
OFE4KvYUwOV+noabXvil8LERIdKYxR/2B6qBiwm47IcioqM07zTYLHJ+WDTEMO2k
Qy51yXwFmeOEr5MIBElYCQ0j2AfI4RCXr+2cyUym7tjEr3/I8EsZ5Crvdf++Gwaz
2A05ScPMr+5yfVXygZCenMTwNAyUY1yN9zVj8/n94Psa
-----ENDE ZERTIFIKAT-----
Ich weiß, ist nicht ganz gültig. Aber irgendwie kann curl es akzeptieren. Ich habe mich gefragt, warum Anforderungen nicht dasselbe tun. Ich bin davon ausgegangen, dass beide openssl verwenden, um das Zertifikat zu validieren.

Irgendwelche Updates dazu? Ich habe auch Probleme mit selbstsignierten zertifizierten Websites in der Python-Anforderungsbibliothek.

Unterhalb des Fehlers kommen.

request.get('https://10.10.24.20', verify='/etc/ssl/certs/certSIGN_ROOT_CA.pem')
Traceback (letzter Aufruf zuletzt):
Datei "“, Zeile 1, ein
Datei „/usr/local/lib/python2.7/dist-packages/requests/api.py“, Zeile 72, in get
Rückgabeanfrage ('get', url, params=params, *kwargs)Datei "/usr/local/lib/python2.7/dist-packages/requests/api.py", Zeile 58, in Anfragereturn session.request(method=method, url=url, * kwargs)
Datei "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", Zeile 508, in Anfrage
resp = self.send(prep, *send_kwargs)Datei „/usr/local/lib/python2.7/dist-packages/requests/sessions.py“, Zeile 618, in sendr = adapter.send (Anfrage, * kwargs)
Datei "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", Zeile 506, in send
Erhöhen Sie SSLError (e, Anfrage = Anfrage)
request.exceptions.SSLError: HTTPSConnectionPool(host='10.10.24.20', port=443): Max. Wiederholungen überschritten mit URL: / (Verursacht durch SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate ', 'Zertifikatsüberprüfung fehlgeschlagen')],)",),))

Wenn ich verifiziere, dass es falsch ist, funktioniert es, aber ich möchte es mit verifizieren = wahr

Ich habe das vorher nicht gesehen, also habe ich ein neues Thema eröffnet, sorry dafür. Aber ich stehe vor dem gleichen Problem. Für mich schlägt 'request' auch mit verify=False fehl.

$ Python
Python 2.7.13 (Standard, 19. Januar 2017, 14:48:08)
[GCC 6.3.0 20170118] auf Linux2
Geben Sie "Hilfe", "Copyright", "Credits" oder "License" ein, um weitere Informationen zu erhalten.

Anfragen importieren
Requests.get("https://localhost:9000/getcpuinfo", verify=False)
Traceback (letzter Aufruf zuletzt):
Datei "“, Zeile 1, ein
Datei „/usr/lib/python2.7/dist-packages/requests/api.py“, Zeile 70, in get
Rückgabeanfrage ('get', url, params=params, *kwargs)Datei "/usr/lib/python2.7/dist-packages/requests/api.py", Zeile 56, in Anfragereturn session.request(method=method, url=url, * kwargs)
Datei "/usr/lib/python2.7/dist-packages/requests/sessions.py", Zeile 488, auf Anfrage
resp = self.send(prep, *send_kwargs)Datei "/usr/lib/python2.7/dist-packages/requests/sessions.py", Zeile 609, in sendr = adapter.send (Anfrage, * kwargs)
Datei "/usr/lib/python2.7/dist-packages/requests/adapters.py", Zeile 497, in send
Erhöhen Sie SSLError (e, Anfrage = Anfrage)
Anfragen.Ausnahmen.SSLError: ("schlechter Handshake: SysCallError(-1, 'Unerwartetes EOF')",)

Meine lokalen Zertifikatsinformationen sind:

$ openssl s_client -showcerts -connect localhost:9000
CONNECTED(00000003)
depth=0 CN = localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = localhost
verify return:1
write:errno=0
---
Certificate chain
 0 s:/CN=localhost
   i:/CN=localhost
-----BEGIN CERTIFICATE-----
MIIC/jCCAeagAwIBAgIJAKATu2AY/QT4MA0GCSqGSIb3DQEBCwUAMBQxEjAQBgNV
BAMMCWxvY2FsaG9zdDAeFw0xNzExMDkyMTQ1NTBaFw0xNzEyMDkyMTQ1NTBaMBQx
EjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJTPk5nao0wG/EDFGnq7BvXMkEZ5oUVq7PAUxWi+E/byJk924l7Z5kACgWBa
zQL0lLXLpdMk97EFGWMblz5Ehtqh7U8HaE9OZ6x/pesDTka+REnpXecklRrdZHX7
lfFnNIU58grPpB2GyUXrRdOtcPlaKXUo+VTd7PgwMtYVtt8pyTWxSB2MMYrqJGT8
78KX6trRzQLm7tas3U0jD59+R8j7gxU6FyFaNJBrkJ5T9kHGKOsAzSqZdCgRBjl5
i7xcXJfOAAnZ3jhGlY5DQht+HZDHhjkLG9kcZZhFDYteFk8drzbd3lBw96nLq+8A
Sy92FtQL4GiYSwZ0WVAmwmTCGjUCAwEAAaNTMFEwHQYDVR0OBBYEFLYjwGKbcV9h
sYHxe8l9UvXVivByMB8GA1UdIwQYMBaAFLYjwGKbcV9hsYHxe8l9UvXVivByMA8G
A1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHl7okBCJlms+cwfzLhs
sbyyuX2wgngxyvjy497zBmeh1TiueGPhOx9u/sfJSZmoUaeRd/zPGkp2DcPQ+Lo2
EHYrXMPE1Ecgpu/15JZ8jNuE+FwZb9lllULLwzq8pDkdbdsSRltdV/rFlZ2YkscB
c+xvVaCltw5KpKnY6AWHoqwoDcd8TZKzyKXLSuluKbHNC1lvg8cMzs6hFA9P92Ae
9P08AKLAIOGJ7QzRrXQIsAO4p9rHheeZeYQZyNiRrXPQUoWos4+OjynaNs+FabhN
XBtSl/GGPRRRfU/D9v4iKfQx15CEvs1AKn1Z6mIPF05pSqbgIoz2mJBV6UM7e+hz
TRs=
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=localhost
issuer=/CN=localhost
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1198 bytes and written 302 bytes
Verification error: self signed certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 5311B8500C8AF327083E1465FE1E1A6A98E0996B4791150A01D6B130C7F0549909A4BDCDED388E9EDE124BB6C50E150A
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1510599077
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: no
---

Bitte entführen Sie dieses Problem nicht. Im Allgemeinen sollten Sie Stack Overflow verwenden, um diese Fragen zu stellen: Wenn Sie das Problem mit Anfragen überladen, neigen Sie nur dazu, es zu schließen.

@sg77 Ihr Zertifikat ist mit CA=FALSE gekennzeichnet, wodurch es nicht als ausstellendes Zertifikat geeignet ist. Ich vermute, curl passt seinen Code so an, dass er dieses Zertifikat als Pin und nicht als Root-CA verwendet. Requests tut dies nicht: Dieses Zertifikat kann keine Stammzertifizierungsstelle sein, daher wird es nicht validiert.

Ich empfehle, ein neues Zertifikat mit CA=TRUE zu prägen oder die BasicConstraints ganz wegzulassen.

@ashwini-kaklij Ich habe keine Ahnung, warum Ihre Überprüfung fehlschlägt, weil ich das Zertifikat nicht sehen kann. Bitte posten Sie es nicht hier : Richten Sie Ihre Frage stattdessen an StackOverflow.

@uttampawar Ihr Fehler wird dadurch verursacht, dass der Server aus irgendeinem Grund unseren TLS-Handshake nicht mag. In Ermangelung weiterer Details kann ich nicht feststellen, warum. Bitte bringen Sie Ihre Frage erneut zu Stack Overflow.

@Lukasa Ich wollte das Problem nicht entführen, sondern nur erhöhen. Vielleicht ist dies ein falscher Ort. Ich habe meine Kommentare und Beobachtungen hinzugefügt, da ich gesehen habe, dass es ähnlich ist. Ich freue mich über Ihr Feedback. Ich werde auf Stackoverflow fragen. Danke.

Bitte entführen Sie dieses Problem nicht. Im Allgemeinen sollten Sie Stack Overflow verwenden, um diese Fragen zu stellen: Wenn Sie das Problem mit Anfragen überladen, neigen Sie nur dazu, es zu schließen.

@sg77 Ihr Zertifikat ist mit CA=FALSE gekennzeichnet, wodurch es nicht als ausstellendes Zertifikat geeignet ist. Ich vermute, curl passt seinen Code so an, dass er dieses Zertifikat als Pin und nicht als Root-CA verwendet. Requests tut dies nicht: Dieses Zertifikat kann keine Stammzertifizierungsstelle sein, daher wird es nicht validiert.

Ich empfehle, ein neues Zertifikat mit CA=TRUE zu prägen oder die BasicConstraints ganz wegzulassen.

@ashwini-kaklij Ich habe keine Ahnung, warum Ihre Überprüfung fehlschlägt, weil ich das Zertifikat nicht sehen kann. Bitte _nicht hier posten_: Richten Sie Ihre Frage stattdessen an StackOverflow.

@uttampawar Ihr Fehler wird dadurch verursacht, dass der Server aus irgendeinem Grund unseren TLS-Handshake nicht mag. In Ermangelung weiterer Details kann ich nicht feststellen, warum. Bitte bringen Sie Ihre Frage erneut zu Stack Overflow.

Hallo Lukasa - Habe gerade deine Antwort gesehen. Sie haben auf @sg77 geantwortet und gesagt: „Ihr Zertifikat ist mit CA=FALSE gekennzeichnet“.

Wie können Sie feststellen, dass dies falsch ist, und wo / wie kann ich dies wieder auf WAHR setzen?

Danke.

Das Posten des Zertifikatschlüssels online ist wie das Posten Ihres Passworts

@ Synida

Das Posten des Zertifikatschlüssels online ist wie das Posten Ihres Passworts

Ähm nein. Das Posten des privaten Schlüssels des Zertifikats entspricht Ihrem Passwort.

Jede Zertifizierungsstelle im Unternehmen hat ihr Zertifikat in jedem gängigen Betriebssystem und Browser. Geben sie ihr Passwort an alle weiter?

https://en.wikipedia.org/wiki/Public-key_cryptography

Dieser Fehler ist mit ziemlicher Sicherheit darauf zurückzuführen, dass das Zertifikat selbst in irgendeiner Weise ungültig ist. Können Sie bitte das PEM-codierte Zertifikat selbst bereitstellen?

Wie kann ich auf dieses Zertifikat zugreifen?

Wenn Sie ein Anfänger des requests -Moduls in Python sind und einige Dinge tun möchten, die den Zugriff auf sichere Websites erfordern, besteht eine hohe Wahrscheinlichkeit, dass Sie durch diesen Fehler zum Scheitern verurteilt sind - Certificate verify failed und wie alle Programmieranfänger Sie wird versucht sein, auth = session.post( mysecureurl, verify=false) zu verwenden

Aber das ist eine sehr schlechte Praxis und wurde über viele SO-Posts entmutigt, aber Anfänger missbrauchen dies immer noch, weil der Fehler so blöd zu beheben ist.
Lassen Sie mich versuchen, etwas Licht in dieses Thema zu bringen.
Python(pip) und Conda und jede Python-basierte Software verwendet einen separaten Zertifikatsspeicher, genau wie alle Browser. Die Python-Requests-Bibliothek verwendet standardmäßig ihre eigene CA-Datei oder verwendet das Zertifikatpaket des certifi-Pakets, falls installiert. Außerdem verwendet pip im Gegensatz zu curl nicht die Systemzertifikate.
Daher müssen Sie für requests den Zertifikatsspeicher manuell über Conda oder Pip angeben.

Tldr;

  1. Exportieren Sie die gesamte .cer verschlüsselte Zertifikatskette mit einem Browser, wie in diesem erstaunlichen Blog , der hier gezeigt wird. Beachten Sie, dass es in diesem Blog nicht um conda certstore, sondern um git certstore geht, und es heißt nur, den Stamm zu exportieren, aber ich habe alle Zertifikatsketten in separate Dateien exportiert.
  2. Als nächstes installieren Sie certifi mit dem Befehl pip install certifi
  3. Überprüfen Sie den Standardpfad des Zertifikatspeichers von conda oder python:

import ssl
ssl.get_default_verify_paths() ODER
import certifi
certifi.where()

  1. Sobald Sie die Standarddatei cacert.pem gefunden haben, öffnen Sie diese (vorzugsweise in Notepad++) und hängen Sie das gesamte Zertifikat am Ende der Datei an. (Achten Sie auf die Zertifikatsabgrenzung -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- ). Speichern Sie die Datei und das war's.
    Oder wenn Sie Conda verwenden, verwenden Sie die Conda-Befehle:
    conda config --set ssl_verify <pathToYourFile>.crt
    (Mir ist aufgefallen, dass dieser Befehl Sachen in C:\Users\johndoe\.condarc aktualisiert)

  2. Verwenden Sie zur Bestätigung den folgenden Code:
    import certifi
    auth = session.post('https://mysecuresite.com/', cert=());

Wenn Sie Linux verwenden, können Sie über diesen Link auch benutzerdefinierte Cacerts in das systemweite oder Benutzerprofil ( .bashrc oder .bash_profile ) exportieren.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

eromoe picture eromoe  ·  3Kommentare

remram44 picture remram44  ·  4Kommentare

justlurking picture justlurking  ·  3Kommentare

Matt3o12 picture Matt3o12  ·  3Kommentare

mitar picture mitar  ·  4Kommentare