Requests: Error de SSL: apretón de manos incorrecto

¿Podría decirnos cómo ha instalado las solicitudes y qué versión ha instalado?

Es casi seguro que se trata de un problema de SNI, por lo que, dependiendo de cómo se instaló la biblioteca, es posible que debamos agregar algunas dependencias opcionales.

las solicitudes se instalaron como dependencia para smartsheet-python-sdk a través de pip:

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

El paquete eliminado en pip e instalar desde yum no ayudará ...

@pensnarik ¿Puedes intentar ejecutar pip install -U requests[security] en tu entorno y luego intentarlo de nuevo?

Gracias, Lukasa, por tu consejo, pero no ayudó ...

[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')],)",)

¿Puede mostrarme a qué host se está conectando?

Lukasa, por supuesto: https://api.smartsheet.com/2.0 , estoy usando la envoltura de Python para la API de smartsheet (https://github.com/smartsheet-platform/smartsheet-python-sdk).

¿Y tiene certifi instalado en su entorno?

Sí tengo:

[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

Ajá, está bien, llegamos allí.

api.smartsheet.com sirve su TLS utilizando lo que se conoce como "certificado con firma cruzada". Esto se usó porque Verisign, la CA de api.smartsheet.com , originalmente usaba un certificado raíz de 1024 bits. Estos fueron obsoletos y reemplazados por certificados raíz más fuertes, pero es posible que algunos navegadores y sistemas más antiguos no hayan recibido actualizaciones, por lo que sitios como api.smartsheet.com ofrecen un certificado raíz que está firmado por la raíz de 1024 bits.

Normalmente eso no es un problema, _excepto_:

• certifi eliminó las raíces débiles de 1024 bits
• OpenSSL anterior a 1.0.2 apesta en la construcción de cadenas de certificados y, por lo tanto, no valida correctamente la raíz con firma cruzada.

Puedes resolver esto de dos formas. La primera forma, mejor pero más drástica, es actualizar su OpenSSL a 1.0.2 o posterior. Me temo que esto es difícil de hacer en Centos. La forma menos buena pero más efectiva es obtener el resultado de ejecutar python -c "import certifi; print certifi.old_where()" y luego establecer la variable de entorno REQUESTS_CA_BUNDLE en la ruta impresa.

Argh, el SDK de la hoja inteligente anula esa variable de entorno al usar explícitamente certifi.

Nuevo plan. Justo al principio después de importar la hoja inteligente, antes de hacer _cualquier otra cosa_, ¿puede agregar las siguientes líneas?

import smartsheet.session
import certifi
smartsheet.session._TRUSTED_CERT_FILE = certifi.old_where()

Con suerte, eso debería ayudar. No debería necesitar la variable de entorno con este enfoque.

Desafortunadamente, no funciona incluso si cambio esta línea en /usr/lib/python2.7/site-packages/smartsheet/session.py:

_TRUSTED_CERT_FILE = certifi.where()

para

_TRUSTED_CERT_FILE = certifi.old_where()

Cuando cambio esta var de mi código, tampoco ayuda ...

En este punto, estoy bastante seguro de que esto no es un error en las solicitudes y, de hecho, es un problema con el contenedor de la API de la hoja inteligente. ¿Has intentado informarles de esto?

Hrm. ¿Está seguro de que ese código se está ejecutando? ¿Puede utilizar declaraciones impresas para confirmar que se está utilizando?

¡La degradación de certifi de 2015.11.20.1 a 2015.4.28 soluciona el problema!

ubuntu @ ip-172-31-58-148 : ~ / solicita $ clear
ubuntu @ ip-172-31-58-148 : ~ / solicita $ python
Python 2.7.6 (predeterminado, 22 de junio de 2015, 17:58:13)
[GCC 4.8.2] en linux2
Escriba "ayuda", "derechos de autor", "créditos" o "licencia" para obtener más información.

solicitudes de importación
request.get ('https://logo.clearbit.com/beutifi.com')
request / packages / urllib3 / util / ssl_.py: 318: SNIMissingWarning: Se ha realizado una solicitud HTTPS, pero la extensión SNI (indicación del nombre del sujeto) para TLS no está disponible en esta plataforma. Esto puede hacer que el servidor presente un certificado TLS incorrecto, lo que puede provocar fallas de validación. Puede actualizar a una versión más reciente de Python para resolver esto. Para obtener más información, consulte https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
request / packages / urllib3 / util / ssl_.py: 122: InsecurePlatformWarning: Un verdadero objeto SSLContext no está disponible. Esto evita que urllib3 configure SSL de forma adecuada y puede provocar que algunas conexiones SSL fallen. Puede actualizar a una versión más reciente de Python para resolver esto. Para obtener más información, consulte https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InseguroPlataformaAdvertencia
Rastreo (llamadas recientes más última):
Expediente "", línea 1, en
Archivo "request / api.py", línea 71, en get
solicitud de devolución ('get', url, params = params, * _kwargs)
Archivo "solicitudes / api.py", línea 57, en la solicitud
return session.request (método = método, url = url, * _kwargs)
Archivo "solicitudes / sesiones.py", línea 477, en la solicitud
resp = self.send (preparación, * _send_kwargs)
Archivo "solicitudes / sesiones.py", línea 587, en envío
r = adapter.send (solicitud, * _kwargs)
Archivo "solicitudes / adaptadores.py", línea 491, en envío
elevar SSLError (e, solicitud = solicitud)
request.exceptions.SSLError: [Errno 1] _ssl.c: 510: error: 14077410 : rutinas SSL

Esta es mi aportación a este problema. No sucede con cada solicitud https.

@sProject Debería resolver ambas advertencias antes de que podamos determinar si tiene un nuevo problema. Si recibió solicitudes de pip, ejecute pip install pyopenssl pyasn1 ndg-httpsclient . Si recibió solicitudes de su proveedor de sistema, debe instalar esos tres paquetes desde allí.

Este error parece haberse resuelto hace más de dos meses. Si me equivoco en esta conclusión y todavía hay un error en las solicitudes, estaré feliz de volver a abrir esto.

¡Gracias a todos por colaborar en las solicitudes!

El ejemplo de pygodaddy plantea la misma excepción.

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')],)",)

La degradación de @pensnarik no lo soluciona. Esto es Fedora 24, Python 2.7.12.

# 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 te está enviando una cadena de certificados incompleta. Eso significa que nos falta uno de los certificados intermedios y no podemos crear una cadena de confianza. Deberá agregar el certificado intermediario faltante a la tienda de confianza certifi o deberá comunicarse con GoDaddy y decirles que solucionen su problema.

@Lukasa ¿cómo se puede verificar si el problema está en las solicitudes o en el emisor del certificado?
Tengo un certificado emitido por Entrust y mis navegadores están bastante bien con él cuando busco la URL.
Pero cuando trato de llegar a esa URL a través de solicitudes, tengo [SSL: CERTIFICATE_VERIFY_FAILED]

Trazabilidad completa

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

paquetes instalados

$ pip list
certifi (2016.9.26)
pip (9.0.1)
requests (2.12.4)
setuptools (32.3.1)
wheel (0.29.0)

Detalles del certificado

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

Es casi seguro que el problema no está en el emisor, sino en su servidor. ¿Puede mostrarme el resultado de ejecutar openssl s_client -connect "<your-host>:<your-port>" -showcerts -servername "<your-host>" contra su servidor, por favor?

No estoy seguro de haber usado el comando correctamente, pero eso es algo:

$ 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

Sí, entonces el servidor está equivocado.

Este es un problema muy común con TLS. La validación de un certificado TLS se realiza construyendo primero una cadena de certificados que nos lleva desde un certificado para el que el servidor puede probar que tiene la clave privada (la "hoja") a un certificado en el que confiamos (la "raíz"). Para OpenSSL hay una regla adicional: la raíz debe estar autofirmada.

En la mayoría de los casos, esta cadena tiene más de dos pasos: es decir, la hoja no está firmada por la raíz, sino que está firmada por un llamado certificado intermedio . Ese intermedio puede estar firmado por la raíz, pero también puede estar firmado por otros intermedios, hasta que finalmente lleguemos a un intermedio que fue firmado por una raíz.

Por ejemplo, para https://python-hyper.org , la cadena es la siguiente:

1. python-hyper.org, la "hoja", que solicité y emití
2. Let's Encrypt Authority X3, un certificado intermedio utilizado por el proyecto Let's Encrypt
3. DST Root CA X3, el certificado raíz en el que mi navegador web (y solicitudes) confían

La cadena correcta para el sitio al que accede debe ser :

1. infoproducts.alcatel-lucent.com, la hoja
2. Entrust Certification Authority - L1K, el certificado intermedio que emitió la hoja
3. Entrust Root Certification Authority - G2, el certificado raíz que emitió el intermedio

Para su caso de uso, Requests se envía con el certificado número 3 en su base de datos de confianza como raíz de confianza. Sin embargo, su servidor solo envía el certificado número 1. Las solicitudes no pueden pasar del certificado 1 al certificado 3 sin tener el certificado 2, y el servidor no lo envía. La mayoría de los navegadores se envían con certificados intermedios de uso común, o pueden mantener cachés de ellos, pero las solicitudes no pueden hacer eso, por lo que no tiene forma de obtener el certificado 2. Sin el certificado 2, la validación debe fallar.

Los servidores TLS configurados correctamente envían el certificado hoja y todos los intermediarios necesarios . Esto es para asegurar que los clientes que nunca han visto a los intermediarios y que no pueden buscarlos dinámicamente aún puedan validar la cadena. Como comparación, consulte el resultado de un comando como el suyo que se ejecuta en 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)
---

Tenga en cuenta que el servidor envió dos certificados en mi caso, mientras que en el suyo solo envió uno.

Este es el error. Vuelva a configurar su servidor para enviar todos los intermediarios relevantes, así como la hoja.

Mientras estoy aquí, debo tener en cuenta que ejecutar Qualys SSL Labs en su servidor también le habría informado sobre este problema. =)

¡Gracias @Lukasa por esta respuesta educativa que diste! Realmente aprecio y lamento tener problemas con esto, era mi TLS-knowledge-gap =) Principalmente fui a los problemas porque en estaba todo bien en los navegadores y no funcionó en las solicitudes. Pero ahora tengo claro cuál es la causa raíz.

Creo que no hay una solución alternativa (descargue el certificado intermedio por adelantado) para este caso, pero ¿reconfigurar el servidor? Por el momento, omitiré los controles de verificación.

@hellt No hay necesidad de disculparse: esto es algo que no es muy obvio y es un error muy común de cometer, así que estás en buena compañía aquí. =)

De hecho, hay una solución. Puede pasar un paquete de certificados a verify para anular el uso del paquete de certifi. Este paquete puede, además de los certificados raíz, contener certificados intermedios que están disponibles para que OpenSSL los utilice para construir la cadena. Como resultado, lo que puede hacer es tomar la cadena de certificados (que está en un archivo que puede encontrar ejecutando python -c 'import certifi; print(certifi.where())' , copiarlo en otro lugar de su sistema de archivos y luego agregar el certificado intermedio al final de ese archivo. El intermedio tiene que estar en formato PEM. Si luego pasa la ruta al nuevo paquete de certificados al verify kwarg, verá que todo comienza a funcionar.

Luka,
¿Qué pasa si obtengo este tipo de error?
pip instalar certifi
Recogiendo certifi
No se pudo recuperar la URL https://pypi.python.org/simple/certifi/ : Hubo un problema al confirmar el certificado ssl: [Errno 2] No existe tal archivo o directorio - omitiendo
No se pudo encontrar una versión que cumpla con el requisito de certificación (de las versiones :)
No se encontró distribución coincidente para certifi

Q

Parece que tiene problemas para validar los certificados TLS de PyPI. Sin embargo, ese mensaje de error es un poco sorprendente. No sé del todo de dónde viene, pero sugiere un problema con la forma en que está configurado su pip o con su Python. ¿Encuentra errores similares con otros paquetes de Python?

Hola a todos,
Estoy tratando de hacer la autenticación kerberos usando Python dentro de la intranet de mi organización, pero obtengo este error.

solicitudes de importación
de request_kerberos importar HTTPKerberosAuth
r = solicitudes.get ("https: * * * * * ", auth = HTTPKerberosAuth ())

SSLError: ("apretón de manos incorrecto: Error ([('rutinas SSL', 'ssl3_get_server_certificate', 'verificación de certificado fallida')],)",)

¿Alguien sabe cómo agregar certificados para Python? ¿Ayudará eso a resolver esto?

@ ajitmuley5 mientras usa Requests, preguntas como la suya pertenecen a StackOverflow. Publique esto allí con la cantidad requerida de detalles. Hay personas que estarán encantadas de ayudarte sin iniciar discusiones sobre temas antiguos y cerrados.

@Lukasa ¡Gracias! sudo pip install -U solicitudes [seguridad] funcionó para mí.

Gracias a todos, tengo algunas ideas!