Ich konnte Ihre Bibliothek in CeontOS 7 mit Python 2.7.5 nicht verwenden. Ich habe diesen Fehler:
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 576, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 447, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",)
Das Aktualisieren von Python oder SSL-Bibliotheken hat nicht geholfen. Ich habe diesen Fehler in CentOS und Ubuntu, in Arch Linux funktioniert alles gut.
Könnten Sie uns bitte sagen, wie Sie Requests installiert haben und welche Version Sie installiert haben?
Dies ist mit ziemlicher Sicherheit ein SNI-Problem. Je nachdem, wie die Bibliothek installiert wurde, müssen wir möglicherweise einige optionale Abhängigkeiten hinzufügen.
request wurde als Abhängigkeit für smartsheet-python-sdk über pip installiert:
pip show requests
---
Metadata-Version: 2.0
Name: requests
Version: 2.10.0
Summary: Python HTTP for Humans.
Home-page: http://python-requests.org
Author: Kenneth Reitz
Author-email: [email protected]
Installer: pip
License: Apache 2.0
Location: /usr/lib/python3.4/site-packages
Requires:
Classifiers:
Development Status :: 5 - Production/Stable
Intended Audience :: Developers
Natural Language :: English
License :: OSI Approved :: Apache Software License
Programming Language :: Python
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3
Programming Language :: Python :: 3.3
Programming Language :: Python :: 3.4
Programming Language :: Python :: 3.5
Programming Language :: Python :: Implementation :: CPython
Programming Language :: Python :: Implementation :: PyPy
pip show smartsheet-python-sdk
---
Metadata-Version: 2.0
Name: smartsheet-python-sdk
Version: 1.0.1
Summary: Library that uses Python to connect to Smartsheet services (using API 2.0).
Home-page: http://smartsheet-platform.github.io/api-docs/
Author: Smartsheet
Author-email: [email protected]
Installer: pip
License: Apache-2.0
Location: /usr/lib/python3.4/site-packages
Requires: certifi, requests, six, python-dateutil, requests-toolbelt
Classifiers:
Development Status :: 5 - Production/Stable
Intended Audience :: Developers
Natural Language :: English
Operating System :: OS Independent
License :: OSI Approved :: Apache Software License
Programming Language :: Python
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3.3
Programming Language :: Python :: 3.4
Programming Language :: Python :: 3.5
Programming Language :: Python :: Implementation :: PyPy
Programming Language :: Python :: Implementation :: CPython
Topic :: Software Development :: Libraries :: Python Modules
Topic :: Office/Business :: Financial :: Spreadsheet
Paket in pip entfernt und Installation von yum hilft nicht...
@pensnarik Können Sie versuchen, pip install -U requests[security]
in Ihrer Umgebung auszuführen und es dann erneut versuchen?
Danke Lukasa für deinen Rat, aber es hat nicht geholfen...
[mutex<strong i="6">@unica1</strong> parser]$ sudo pip install -U requests[security]
[sudo] password for mutex:
Collecting requests[security]
Using cached requests-2.10.0-py2.py3-none-any.whl
Collecting pyOpenSSL>=0.13 (from requests[security])
Using cached pyOpenSSL-16.0.0-py2.py3-none-any.whl
Collecting ndg-httpsclient (from requests[security])
Requirement already up-to-date: pyasn1 in /usr/lib/python2.7/site-packages (from requests[security])
Collecting cryptography>=1.3 (from pyOpenSSL>=0.13->requests[security])
Using cached cryptography-1.3.2.tar.gz
Requirement already up-to-date: six>=1.5.2 in /usr/lib/python2.7/site-packages (from pyOpenSSL>=0.13->requests[security])
Requirement already up-to-date: idna>=2.0 in /usr/lib/python2.7/site-packages (from cryptography>=1.3->pyOpenSSL>=0.13->requests[security])
Requirement already up-to-date: setuptools>=11.3 in /usr/lib/python2.7/site-packages (from cryptography>=1.3->pyOpenSSL>=0.13->requests[security])
Requirement already up-to-date: enum34 in /usr/lib/python2.7/site-packages (from cryptography>=1.3->pyOpenSSL>=0.13->requests[security])
Requirement already up-to-date: ipaddress in /usr/lib/python2.7/site-packages (from cryptography>=1.3->pyOpenSSL>=0.13->requests[security])
Requirement already up-to-date: cffi>=1.4.1 in /usr/lib64/python2.7/site-packages (from cryptography>=1.3->pyOpenSSL>=0.13->requests[security])
Requirement already up-to-date: pycparser in /usr/lib/python2.7/site-packages (from cffi>=1.4.1->cryptography>=1.3->pyOpenSSL>=0.13->requests[security])
Building wheels for collected packages: cryptography
Running setup.py bdist_wheel for cryptography ... done
Stored in directory: /root/.cache/pip/wheels/14/df/02/611097a49d7739151deb68d0172dff5ae7cba01b82769e56ef
Successfully built cryptography
Installing collected packages: cryptography, pyOpenSSL, ndg-httpsclient, requests
Found existing installation: requests 2.6.0
DEPRECATION: Uninstalling a distutils installed project (requests) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
Uninstalling requests-2.6.0:
Successfully uninstalled requests-2.6.0
Successfully installed cryptography-1.3.2 ndg-httpsclient-0.4.0 pyOpenSSL-16.0.0 requests-2.10.0
You are using pip version 8.1.0, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
[mutex<strong i="7">@unica1</strong> parser]$ ./update_region_price.py
Traceback (most recent call last):
File "./update_region_price.py", line 129, in <module>
sys.exit(app.run(sys.argv))
File "./update_region_price.py", line 122, in run
self.update_basic()
File "./update_region_price.py", line 65, in update_basic
sheet = self.sm.Sheets.get_sheet(self.sheet_id, page_size=5000)
File "/usr/lib/python2.7/site-packages/smartsheet/sheets.py", line 460, in get_sheet
response = self._base.request(prepped_request, expected, _op)
File "/usr/lib/python2.7/site-packages/smartsheet/smartsheet.py", line 178, in request
res = self.request_with_retry(prepped_request, operation)
File "/usr/lib/python2.7/site-packages/smartsheet/smartsheet.py", line 242, in request_with_retry
return self._request(prepped_request, operation)
File "/usr/lib/python2.7/site-packages/smartsheet/smartsheet.py", line 208, in _request
res = self._session.send(prepped_request, stream=stream)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 585, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 477, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",)
Können Sie mir zeigen, mit welchem Host Sie sich verbinden?
Lukasa, natürlich: https://api.smartsheet.com/2.0 , ich verwende Python-Wrapper für die Smartsheet-API (https://github.com/smartsheet-platform/smartsheet-python-sdk).
Und haben Sie zufällig certifi
in Ihrer Umgebung installiert?
Ja, habe ich:
[mutex<strong i="6">@unica1</strong> parser]$ pip show certifi
---
Metadata-Version: 2.0
Name: certifi
Version: 2016.2.28
Summary: Python package for providing Mozilla's CA Bundle.
Home-page: http://certifi.io/
Author: Kenneth Reitz
Author-email: [email protected]
Installer: pip
License: ISC
Location: /usr/lib/python2.7/site-packages
Requires:
Classifiers:
Development Status :: 5 - Production/Stable
Intended Audience :: Developers
Natural Language :: English
Programming Language :: Python
Programming Language :: Python :: 2.5
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3.0
Programming Language :: Python :: 3.1
Programming Language :: Python :: 3.2
Programming Language :: Python :: 3.3
Programming Language :: Python :: 3.4
Aha, ok, wir sind angekommen.
api.smartsheet.com
bedient sein TLS mit einem sogenannten "kreuzsignierten Zertifikat". Dies wurde verwendet, weil Verisign, die CA für api.smartsheet.com
, ursprünglich ein 1024-Bit-Stammzertifikat verwendet hat. Diese wurden veraltet und durch stärkere Root-Zertifikate ersetzt, aber einige ältere Browser und Systeme haben möglicherweise keine Updates erhalten, sodass Sites wie api.smartsheet.com
ein Root-Zertifikat bereitstellen, das vom 1024-Bit-Root signiert ist.
Das ist normalerweise kein Problem, _außer_:
certifi
die schwachen 1024-Bit-Roots entferntSie können dies auf zwei Arten lösen. Der erste, bessere, aber drastischere Weg besteht darin, Ihr OpenSSL auf 1.0.2 oder höher zu aktualisieren. Auf Centos ist das schwer, fürchte ich. Die weniger gute, aber effektivere Methode besteht darin, die Ausgabe von python -c "import certifi; print certifi.old_where()"
und dann die Umgebungsvariable REQUESTS_CA_BUNDLE
auf den gedruckten Pfad zu setzen.
Argh, das Smartsheet SDK überschreibt diese Umgebungsvariable, indem es explizit certifi verwendet.
Neuer Plan. Können Sie gleich zu Beginn nach dem Importieren von Smartsheet, bevor Sie _irgendetwas_ tun, die folgenden Zeilen hinzufügen?
import smartsheet.session
import certifi
smartsheet.session._TRUSTED_CERT_FILE = certifi.old_where()
Das sollte hoffentlich helfen. Bei diesem Ansatz sollten Sie die Umgebungsvariable nicht benötigen.
Leider funktioniert es nicht, selbst wenn ich diese Zeile in /usr/lib/python2.7/site-packages/smartsheet/session.py ändere:
_TRUSTED_CERT_FILE = certifi.where()
zu
_TRUSTED_CERT_FILE = certifi.old_where()
Wenn ich diese Variable in meinem Code ändere, hilft es auch nicht ...
An dieser Stelle bin ich ziemlich zuversichtlich, dass dies kein Fehler in Anfragen ist, sondern tatsächlich ein Problem mit dem Smartsheet-API-Wrapper. Hast du versucht, ihnen das zu melden?
Hm. Sind Sie sicher, dass dieser Code ausgeführt wird? Können Sie print-Anweisungen verwenden, um zu bestätigen, dass es verwendet wird?
Ein Downgrade des Zertifikats von 2015.11.20.1 auf 2015.4.28 behebt das Problem!
ubuntu@ip-172-31-58-148 :~/requests$ clear
ubuntu@ip-172-31-58-148 :~/requests$ python
Python 2.7.6 (Standard, 22. Juni 2015, 17:58:13)
[GCC 4.8.2] unter Linux2
Geben Sie "Hilfe", "Copyright", "Credits" oder "Lizenz" ein, um weitere Informationen zu erhalten.
Importanfragen
request.get('https://logo.clearbit.com/beutifi.com')
request/packages/urllib3/util/ssl_.py:318: SNIMissingWarning: Es wurde eine HTTPS-Anfrage gestellt, aber die SNI-Erweiterung (Subject Name Indication) für TLS ist auf dieser Plattform nicht verfügbar. Dies kann dazu führen, dass der Server ein falsches TLS-Zertifikat vorlegt, was zu Validierungsfehlern führen kann. Sie können auf eine neuere Version von Python aktualisieren, um dieses Problem zu lösen. Weitere Informationen finden Sie unter https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNMissingWarning
request/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: Ein echtes SSLContext-Objekt ist nicht verfügbar. Dies hindert urllib3 daran, SSL richtig zu konfigurieren, und kann dazu führen, dass bestimmte SSL-Verbindungen fehlschlagen. Sie können auf eine neuere Version von Python aktualisieren, um dieses Problem zu lösen. Weitere Informationen finden Sie unter https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
Unsichere PlattformWarnung
Traceback (letzter Anruf zuletzt):
Datei "", Zeile 1, in
Datei "requests/api.py", Zeile 71, in get
Rückgabeanforderung('get', url, params=params, *_kwargs)
Datei "requests/api.py", Zeile 57, in der Anfrage
return session.request(method=method, url=url, *_kwargs)
Datei "requests/sessions.py", Zeile 477, in Anfrage
resp = self.send(prep, *_send_kwargs)
Datei "requests/sessions.py", Zeile 587, in send
r = adapter.send(request, *_kwargs)
Datei "requests/adapters.py", Zeile 491 in send
SSLError auslösen (e, request=request)
Requests.Exceptions.SSLError: [Errno 1] _ssl.c:510: error:14077410 :SSL- Routinen:SSL23_GET_SERVER_HELLO :sslv3-Warnungs-Handshake-Fehler
Dies ist mein Beitrag zu diesem Problem. Es passiert nicht bei jeder https-Anfrage.
@sProject Sie müssen diese beiden Warnungen beheben, bevor wir feststellen können, ob ein neues Problem pip install pyopenssl pyasn1 ndg-httpsclient
. Wenn Sie Anfragen von Ihrem Systemanbieter erhalten haben, sollten Sie diese drei Pakete von dort installieren.
Dieser Fehler scheint vor über zwei Monaten behoben worden zu sein. Wenn ich mit dieser Schlussfolgerung falsch liege und immer noch ein Fehler in Anfragen zu finden ist, öffne ich diesen gerne wieder.
Vielen Dank an alle für die Zusammenarbeit bei Anfragen!
Das Beispiel von pygodaddy wirft die gleiche Ausnahme auf
from pygodaddy import GoDaddyClient
client = GoDaddyClient()
if client.login(login[0],login[1]):
print client.find_domains()
else: print 'falhou'
$ ./dynip.py
Traceback (most recent call last):
File "./dynip.py", line 8, in <module>
if client.login(login[0],login[1]):
File "/usr/lib/python2.7/site-packages/pygodaddy/client.py", line 99, in login
r = self.session.get(self.default_url)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 501, in get
return self.request('GET', url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 497, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",)
Das Herabstufen des Zertifikats, wie von @pensnarik vorgeschlagen,
# pip list
Babel (2.3.4)
beautifulsoup4 (4.5.1)
blinker (1.4)
certifi (2016.9.26)
cffi (1.9.1)
chardet (2.3.0)
click (6.6)
cryptography (1.5.3)
cssselect (0.9.2)
decorator (4.0.10)
django-htmlmin (0.9.1)
dnspython (1.14.0)
enum34 (1.1.6)
extras (1.0.0)
first (2.0.1)
fixtures (3.0.0)
Flask (0.11.1)
Flask-Babel (0.11.1)
Flask-Gravatar (0.4.2)
Flask-Login (0.3.2)
Flask-Mail (0.9.1)
Flask-Principal (0.4.0)
Flask-Security (1.7.5)
Flask-SQLAlchemy (2.1)
Flask-WTF (0.12)
gps (3.16)
gssapi (1.2.0)
html5lib (1.0b3)
idna (2.1)
importlib (1.0.4)
iniparse (0.4)
ipaclient (4.3.2)
ipaddress (1.0.17)
ipalib (4.3.2)
ipaplatform (4.3.2)
ipapython (4.3.2)
itsdangerous (0.24)
Jinja2 (2.8)
jwcrypto (0.3.2)
kitchen (1.2.4)
linecache2 (1.0.0)
lockfile (0.12.2)
lxml (3.6.4)
M2Crypto (0.25.1)
MarkupSafe (0.23)
munch (2.0.4)
ndg-httpsclient (0.4.2)
netaddr (0.7.18)
nose (1.3.7)
numpy (1.11.1)
passlib (1.6.5)
pbr (1.10.0)
pif (0.7.3)
Pillow (3.3.1)
pip (8.1.2)
pip-tools (1.7.0)
ply (3.9)
psutil (4.3.0)
psycopg2 (2.6.2)
pwquality (1.3.0)
pyasn1 (0.1.9)
pyasn1-modules (0.0.8)
pycparser (2.17)
pycrypto (2.6.1)
pycurl (7.43.0)
pygobject (3.20.1)
pygodaddy (0.2.2)
pygpgme (0.3)
pyliblzma (0.5.3)
pyOpenSSL (16.2.0)
pyrsistent (0.11.13)
PySocks (1.5.7)
python-dateutil (2.5.3)
python-fedora (0.8.0)
python-ldap (2.4.27)
python-mimeparse (1.5.2)
python-nss (1.0.0)
python-yubico (1.3.2)
pytz (2016.6.1)
pyusb (1.0.0)
pyxattr (0.5.5)
qrcode (5.3)
reportlab (3.3.0)
requests (2.12.1)
requests-file (1.4.1)
rpm-python (4.13.0)
scdate (1.10.9)
setuptools (28.8.0)
simplejson (3.8.2)
six (1.10.0)
slip (0.6.4)
speaklater (1.3)
SQLAlchemy (1.0.14)
sqlparse (0.2.1)
SSSDConfig (1.14.2)
Terminator (0.98)
testscenarios (0.5.0)
testtools (2.2.0)
tldextract (2.0.2)
traceback2 (1.4.0)
typing (3.5.2.2)
uniconvertor (2.0)
unittest2 (1.1.0)
urlgrabber (3.10.1)
urllib3 (1.16)
Werkzeug (0.11.11)
WTForms (2.1)
yum-metadata-parser (1.1.4)
GoDaddy stellt Ihnen eine unvollständige Zertifikatskette bereit. Das bedeutet, dass uns eines der Zwischenzertifikate fehlt und wir keine Vertrauenskette aufbauen können. Entweder müssen Sie das fehlende Zwischenzertifikat zum Zertifikats-Truststore hinzufügen oder Sie müssen GoDaddy kontaktieren und ihnen sagen, dass sie ihr Chaos beseitigen sollen.
@Lukasa wie kann man überprüfen, ob das Problem bei Anfragen oder dem Zertifikatsaussteller liegt?
Ich habe ein von Entrust ausgestelltes Zertifikat und meine Browser sind damit einverstanden, wenn ich zur URL navigiere.
Aber wenn ich versuche, über Anfragen zu dieser URL zu gelangen, habe ich [SSL: CERTIFICATE_VERIFY_FAILED]
Vollständige Rückverfolgung
$ python main.py
Traceback (most recent call last):
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/packages/urllib3/connectionpool.py", line 594, in urlopen
chunked=chunked)
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/packages/urllib3/connectionpool.py", line 350, in _make_request
self._validate_conn(conn)
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/packages/urllib3/connectionpool.py", line 835, in _validate_conn
conn.connect()
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/packages/urllib3/connection.py", line 323, in connect
ssl_context=context)
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/packages/urllib3/util/ssl_.py", line 324, in ssl_wrap_socket
return context.wrap_socket(sock, server_hostname=server_hostname)
File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 376, in wrap_socket
_context=self)
File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 747, in __init__
self.do_handshake()
File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 983, in do_handshake
self._sslobj.do_handshake()
File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 628, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/adapters.py", line 423, in send
timeout=timeout
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/packages/urllib3/connectionpool.py", line 624, in urlopen
raise SSLError(e)
requests.packages.urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 64, in <module>
r = s.get('https://infoproducts.alcatel-lucent.com/cgi-bin/get_doc_list.pl?entry_id=1-0000000000662&srch_how=&srch_str=&release=&model=&category=&contype=&format=&sortby=&how=all_prod',
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/sessions.py", line 501, in get
return self.request('GET', url, **kwargs)
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/Users/romandodin/venvs/nokdok/lib/python3.5/site-packages/requests/adapters.py", line 497, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)
installierte Pakete
$ pip list
certifi (2016.9.26)
pip (9.0.1)
requests (2.12.4)
setuptools (32.3.1)
wheel (0.29.0)
Cert-Details
Subject infoproducts.alcatel-lucent.com
SAN infoproducts.alcatel-lucent.com
documentation.alcatel-lucent.com
Valid From Thu, 01 Dec 2016 13:15:08 GMT
Valid Until Sat, 01 Dec 2018 13:45:07 GMT
Issuer Entrust Certification Authority - L1K
Das Problem liegt mit ziemlicher Sicherheit nicht beim Emittenten, sondern bei Ihrem Server. Können Sie mir bitte die Ausgabe von openssl s_client -connect "<your-host>:<your-port>" -showcerts -servername "<your-host>"
auf Ihrem Server zeigen?
Ich bin mir nicht sicher, ob ich den Befehl richtig verwendet habe, aber das ist etwas:
$ openssl s_client -connect "infoproducts.alcatel-lucent.com:443" -showcerts -servername "infoproducts.alcatel-lucent.com"
CONNECTED(00000003)
depth=0 /C=US/ST=Illinois/L=Naperville/O=Alcatel-Lucent USA Inc./CN=infoproducts.alcatel-lucent.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Illinois/L=Naperville/O=Alcatel-Lucent USA Inc./CN=infoproducts.alcatel-lucent.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Illinois/L=Naperville/O=Alcatel-Lucent USA Inc./CN=infoproducts.alcatel-lucent.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=Illinois/L=Naperville/O=Alcatel-Lucent USA Inc./CN=infoproducts.alcatel-lucent.com
i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
-----BEGIN CERTIFICATE-----
MIIFeDCCBGCgAwIBAgIRAO3KTvH+nKgrAAAAAFDanDYwDQYJKoZIhvcNAQELBQAw
gboxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL
Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykg
MjAxMiBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxLjAs
BgNVBAMTJUVudHJ1c3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBMMUswHhcN
MTYxMjAxMTMxNTA4WhcNMTgxMjAxMTM0NTA3WjCBgTELMAkGA1UEBhMCVVMxETAP
BgNVBAgTCElsbGlub2lzMRMwEQYDVQQHEwpOYXBlcnZpbGxlMSAwHgYDVQQKExdB
bGNhdGVsLUx1Y2VudCBVU0EgSW5jLjEoMCYGA1UEAxMfaW5mb3Byb2R1Y3RzLmFs
Y2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AK23xiJ/GCWNJa8Oa6SAYwT7QTmIJOXGrfLLZM9ZWDK81SVLm5xUAVRYaYmb3t/U
KpzeUoL+cJIa2xJGdbj50ehUTbB3SOXW7dxr15fuWahSChqaNkI/NClNAxy2Vho5
HxEtsjmuoJ0cNRcZLHZndLtWi27js3ivGxFxUcl7O3rGGj9yb+XXwJvEOsITPfZ/
gpURnHfAurZrw1+xpsArQVOF6+K6KkPnjGoCj0XCyU3LnWc6akcwwwV+HXcW8H5G
/CPvcm3DpI+45v/P2vVJ9+LiEJVHngVYK2QQ8fMDrvS2vs563I4PLnnRds0eOJph
LfHmn87oSW5jCP3RnsW0czECAwEAAaOCAa4wggGqMA4GA1UdDwEB/wQEAwIFoDAT
BgNVHSUEDDAKBggrBgEFBQcDATAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js
LmVudHJ1c3QubmV0L2xldmVsMWsuY3JsMEsGA1UdIAREMEIwNgYKYIZIAYb6bAoB
BTAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAIBgZn
gQwBAgIwaAYIKwYBBQUHAQEEXDBaMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5l
bnRydXN0Lm5ldDAzBggrBgEFBQcwAoYnaHR0cDovL2FpYS5lbnRydXN0Lm5ldC9s
MWstY2hhaW4yNTYuY2VyMEwGA1UdEQRFMEOCH2luZm9wcm9kdWN0cy5hbGNhdGVs
LWx1Y2VudC5jb22CIGRvY3VtZW50YXRpb24uYWxjYXRlbC1sdWNlbnQuY29tMB8G
A1UdIwQYMBaAFIKicHTdvFM/z3vU981/p2DGCky/MB0GA1UdDgQWBBT9w+iH+fpG
UJ0IMw1vVpn+91hk6jAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQAgOcDq
0YsihBWAxA4WFIGkdB/JdOKLRQ0Hvc7KStgtdkB1AqkUv7oBnDCHesazw4vyWbjv
w7dBTtB95jq1ZHX6eHyUDUo2xBmjnaeb2lSAdVV6j10sl7lMfRQh7ba1Im0ibhfe
7gvBn0tUlmdGqqvDqokzV4lVX74Z9nKKKr5D9e3vJsb5AvbDC/eYguBK9Oy8EDa2
ZcuPve3mB68lVy5UDg21RVZE072qC0FlYhNasZlMVUUg7tgDMlynQeeoxHe7Rcic
pHANQxJqtN8/bsE2mO/ryRZALyC7mWeDvG522ZXMaKslwTUr+jokpyUF7tS786Pi
n4zJ/KNZK2suVwcK
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Illinois/L=Naperville/O=Alcatel-Lucent USA Inc./CN=infoproducts.alcatel-lucent.com
issuer=/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
---
No client certificate CA names sent
---
SSL handshake has read 1556 bytes and written 466 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 48D3C9611E37C997182C4F123E21BCFD909D8D4BE887B44355866B80D44E1163
Session-ID-ctx:
Master-Key: 0A4A9E2A10E33EAA248541C39AC71F2F879310BAE141A4EA26F425D56C27099FB6D6572C2CCFC763FC743ECF99DABB5B
Key-Arg : None
Start Time: 1483448892
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
closed
Ja, also ist der Server falsch.
Dies ist ein sehr häufiges Problem bei TLS. Eine TLS-Zertifikatsvalidierung wird durchgeführt, indem zuerst eine Zertifikatskette erstellt wird , die uns von einem Zertifikat führt, von dem der Server beweisen kann, dass er den privaten Schlüssel hat (das "Blatt") zu einem Zertifikat, dem wir vertrauen (das "Root"). Für OpenSSL gibt es eine zusätzliche Regel: Die Root muss selbstsigniert sein.
In den meisten Fällen ist diese Kette mehr als zwei Schritte lang, dh das Blatt wird nicht von der Wurzel signiert, sondern von einem sogenannten Zwischenzertifikat . Diese Zwischenstufe kann selbst von der Wurzel signiert sein, kann aber auch von anderen Zwischenstufen signiert sein, bis wir schließlich eine Zwischenstufe erreichen, die von einer Wurzel signiert wurde.
Für https://python-hyper.org lautet die Kette beispielsweise wie folgt:
Die richtige Kette für die Website, auf die Sie zugreifen, sollte lauten :
Für Ihren Anwendungsfall wird Requests mit Zertifikat Nummer 3 in seiner Vertrauensdatenbank als vertrauenswürdiger Stamm ausgeliefert. Ihr Server sendet jedoch nur Zertifikat Nummer 1. Anfragen können nicht von Zertifikat 1 zu Zertifikat 3 gehen, ohne dass Zertifikat 2 vorliegt, und der Server sendet es nicht. Die meisten Browser werden mit häufig verwendeten Zwischenzertifikaten geliefert oder können Caches davon verwalten, aber Requests kann dies nicht, sodass es keine Möglichkeit hat, an Zertifikat 2 zu gelangen. Ohne Zertifikat 2 muss die Validierung fehlschlagen.
Korrekt konfigurierte TLS-Server senden das Blattzertifikat und alle erforderlichen Vermittler . Dadurch soll sichergestellt werden, dass Clients, die die Intermediäre noch nie gesehen haben und sie nicht dynamisch abrufen können, die Kette dennoch validieren können. Sehen Sie sich zum Vergleich die Ausgabe eines Befehls wie Ihres gegen python-hyper.org
:
% openssl s_client -connect python-hyper.org:443 -showcerts -servername "python-hyper.org"
CONNECTED(00000003)
depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=python-hyper.org
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIFBDCCA+ygAwIBAgISAwji03rFoFMPZnEC0rLc7jg3MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzAxMDExMjA4MDBaFw0x
NzA0MDExMjA4MDBaMBsxGTAXBgNVBAMTEHB5dGhvbi1oeXBlci5vcmcwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCjF6VMEOe2qHsdbAnYstunDCW5/fBx
yhzNAxSqZKA5qfATdvhDmiPFnHJkQgUkUeGDwbBwemxuUFUaGZKTJDRhlrymLSkN
hkcouBzs/mxDjNlKacokJBm3hpu+oxYohhxPIZBs8NM4olUPDSG68r6sd1EwR+Ia
Lw//nRsMpcrGNmYy+howiBvV3CbuYsbgB59bJ+5y6G2ZqeHMwzFZ+No1oQmBck9T
KAvCh5TteQphzcM9s9NZiB6Z9C0s+vBPKOc1uLssCI3hfr29Af203CX2xgyBjXH7
M4WS17o1zLgs3Q2V03gQ7AmhtgjuJ+2NRf/d6Bsmk8ZhGnyyf+qbY+G/AgMBAAGj
ggIRMIICDTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFMD50AC8wul1eNKkGVxaAvXb
DSkDMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMHAGCCsGAQUFBwEB
BGQwYjAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0
Lm9yZy8wLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlw
dC5vcmcvMBsGA1UdEQQUMBKCEHB5dGhvbi1oeXBlci5vcmcwgf4GA1UdIASB9jCB
8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsGAQUFBwIBFhpodHRw
Oi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIwgZ4MgZtUaGlzIENl
cnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IFJlbHlpbmcgUGFy
dGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIENlcnRpZmljYXRl
IFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0Lm9yZy9yZXBvc2l0
b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAgX00tBHyz9GiDQjw+Id7sbT1lrtHrmtR
DB+kofnq9pkwIExDXT0bAZ14EnU6atiVqhF3j3KxvxIfbNvmSr7emmhPwt+KqOf7
/1m+gxg3ode9LIg6oLtVOfulecxkS4/Wj990O40vuRNdy4XT4PSNze8iuJtGALoS
U9kP8G/V6VnrdbTYhSIIUW9nm0XQcOUbvupFWtiwE8vZw4t0pQloeECdMuALgVO/
1xSu0kqZgidLOkFwei/xqItx7foREzVvq3kUHD1OAuPI1azHQjErQC3N12OmxmBU
3KDOsaJC2Uu8fqI/y1YOkO97hpsgFZX4BiQNaNhtyy7sscD/teVhWQ==
-----END CERTIFICATE-----
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=python-hyper.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 2638 bytes and written 451 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: BBDF2CA65B2142C1F0C416B28C4FDF8FD5118ED4D5FF8802789D0B54C6309469
Session-ID-ctx:
Master-Key: BD9B8B97EC439248CC5849EBF4B2ED18E0A73472EB8D86FE6F038C4E6944AFD8A163D80D47A3A3B28A6237A44C1B31CE
Key-Arg : None
Start Time: 1483447980
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Beachten Sie, dass der Server in meinem Fall zwei Zertifikate gesendet hat, während er in Ihrem nur eines gesendet hat.
Dies ist der Fehler. Bitte konfigurieren Sie Ihren Server neu, um alle relevanten Vermittler sowie das Blatt zu senden.
Während ich hier bin, sollte ich beachten, dass die Ausführung von Qualys SSL Labs auf Ihrem Server Sie auch auf dieses Problem aufmerksam gemacht hätte. =)
Danke @Lukasa für diese lehrreiche Antwort, die du gegeben hast! Ich weiß es wirklich zu schätzen und entschuldige mich für die Mühe, es war meine TLS-Wissenslücke =) Meistens ging ich zu Problemen, weil in Browsern alles gut war und in Anfragen nicht funktionierte. Aber jetzt ist mir klar, was die Ursache ist.
Ich glaube, es gibt keine Problemumgehung (Zwischenzertifikat im Voraus herunterladen) für diesen Fall, aber den Server neu zu konfigurieren? Verifizierungsprüfungen werde ich vorerst überspringen
@hellt Kein wirklich häufiger Fehler ist, also sind Sie hier in guter Gesellschaft. =)
Es gibt tatsächlich einen Workaround. Sie können ein Zertifikatspaket an verify
, um die Verwendung des Zertifikatspakets zu überschreiben. Dieses Bundle kann zusätzlich zu Root-Zertifikaten Zwischenzertifikate enthalten, die OpenSSL zum Aufbau der Kette zur Verfügung stellen. Als Ergebnis können Sie die Zertifikatskette nehmen (die sich in einer Datei befindet, die Sie finden können, indem Sie python -c 'import certifi; print(certifi.where())'
ausführen), diese an eine andere Stelle in Ihrem Dateisystem kopieren und dann das Zwischenzertifikat zum Ende dieser Datei. Das Zwischenprodukt muss im PEM-Format sein. Wenn Sie dann den Pfad zum neuen Zertifikatspaket an den verify
kwarg übergeben, werden Sie feststellen, dass alles funktioniert.
Lukas,
Was ist, wenn ich diese Art von Fehler erhalte;
Pip-Installationszertifikat
Zertifikate sammeln
URL https://pypi.python.org/simple/certifi/ konnte nicht abgerufen werden: Beim Bestätigen des SSL-Zertifikats ist ein Problem aufgetreten: [Errno 2] No such file or directory - skipping
Es konnte keine Version gefunden werden, die das Anforderungszertifikat erfüllt (von Versionen: )
Keine passende Distribution für Zertifikat gefunden
Q
Anscheinend haben Sie Probleme bei der Validierung der TLS-Zertifikate von PyPI. Diese Fehlermeldung ist jedoch etwas überraschend. Ich weiß nicht genau, woher es kommt, aber es deutet auf ein Problem entweder mit der Konfiguration Ihres Pip oder mit Ihrem Python hin. Treten ähnliche Fehler bei anderen Python-Paketen auf?
Hallo alle,
Ich versuche, die Kerberos-Authentifizierung mit Python im Intranet meiner Organisation durchzuführen, erhalte jedoch diesen Fehler.
Importanfragen
von request_kerberos importieren HTTPKerberosAuth
r = request.get("https: * * * * * ", auth=HTTPKerberosAuth())
SSLError: ("schlechter Handshake: Error([('SSL-Routinen', 'ssl3_get_server_certificate', 'Zertifikatsüberprüfung fehlgeschlagen')],)",)
Weiß jemand, wie man Zertifikate für Python hinzufügt? Wird das helfen, das Problem zu lösen?
@ajitmuley5 Während Sie Requests verwenden, gehören Fragen wie Ihre zu StackOverflow. Bitte posten Sie diese dort mit der erforderlichen Detailtiefe. Es gibt Menschen, die Ihnen gerne helfen, ohne Diskussionen über alte und geschlossene Themen zu beginnen.
@Lukasa Danke! sudo pip install -U Anfragen [Sicherheit] hat bei mir funktioniert.
Danke an alle, ich habe ein paar Ideen!
Hilfreichster Kommentar
Aha, ok, wir sind angekommen.
api.smartsheet.com
bedient sein TLS mit einem sogenannten "kreuzsignierten Zertifikat". Dies wurde verwendet, weil Verisign, die CA fürapi.smartsheet.com
, ursprünglich ein 1024-Bit-Stammzertifikat verwendet hat. Diese wurden veraltet und durch stärkere Root-Zertifikate ersetzt, aber einige ältere Browser und Systeme haben möglicherweise keine Updates erhalten, sodass Sites wieapi.smartsheet.com
ein Root-Zertifikat bereitstellen, das vom 1024-Bit-Root signiert ist.Das ist normalerweise kein Problem, _außer_:
certifi
die schwachen 1024-Bit-Roots entferntSie können dies auf zwei Arten lösen. Der erste, bessere, aber drastischere Weg besteht darin, Ihr OpenSSL auf 1.0.2 oder höher zu aktualisieren. Auf Centos ist das schwer, fürchte ich. Die weniger gute, aber effektivere Methode besteht darin, die Ausgabe von
python -c "import certifi; print certifi.old_where()"
und dann die UmgebungsvariableREQUESTS_CA_BUNDLE
auf den gedruckten Pfad zu setzen.