Solicitudes de Python lanzando SSLError

Estoy trabajando en un script simple que involucra CAS, verificación de seguridad de jspring, redirección, etc. ¡Me gustaría usar las solicitudes de Python de Kenneth Reitz porque es un gran trabajo! Sin embargo, CAS requiere ser validado a través de SSL, así que primero tengo que pasar ese paso. No sé lo que quiere Python. ¿Dónde se supone que reside este certificado SSL?

Traceback (most recent call last):
  File "./test.py", line 24, in <module>
  response = requests.get(url1, headers=headers)
  File "build/bdist.linux-x86_64/egg/requests/api.py", line 52, in get
  File "build/bdist.linux-x86_64/egg/requests/api.py", line 40, in request
  File "build/bdist.linux-x86_64/egg/requests/sessions.py", line 209, in request 
  File "build/bdist.linux-x86_64/egg/requests/models.py", line 624, in send
  File "build/bdist.linux-x86_64/egg/requests/models.py", line 300, in _build_response
  File "build/bdist.linux-x86_64/egg/requests/models.py", line 611, in send
requests.exceptions.SSLError: [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

El problema que tiene es causado por un certificado SSL no confiable.

Como @dirk mencionó en un comentario anterior, la solución más rápida es la configuración verify=False:

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

Tenga en cuenta que esto hará que el certificado no se verifique. Esto expondrá su aplicación a riesgos de seguridad, como ataques de hombre en el medio.

Por supuesto, aplique el juicio. Como se menciona en los comentarios, esto puede ser aceptable para aplicaciones / scripts rápidos / descartables, pero realmente no debería ir al software de producción .

Si simplemente omitir la verificación del certificado no es aceptable en su contexto particular, considere las siguientes opciones, su mejor opción es establecer el verifyparámetro en una cadena que sea la ruta del .pemarchivo del certificado (que debe obtener mediante algún tipo de seguridad medio).

Entonces, a partir de la versión 2.0, el verifyparámetro acepta los siguientes valores, con su semántica respectiva:

• True: hace que el certificado se valide contra las autoridades de certificación de confianza de la propia biblioteca (Nota: puede ver qué Solicitudes de certificados raíz utiliza a través de la biblioteca Certifi, una base de datos de confianza de RC extraídos de Solicitudes: Certifi - Base de datos de confianza para humanos ).
• False: evita la validación del certificado por completo .
• Ruta a un archivo CA_BUNDLE para que las Solicitudes las usen para validar los certificados.

Fuente: Solicitudes - Verificación del certificado SSL

También eche un vistazo al certparámetro en el mismo enlace.

De la documentación de solicitudes de verificación SSL :

Las solicitudes pueden verificar certificados SSL para solicitudes HTTPS, al igual que un navegador web. Para verificar el certificado SSL de un host, puede usar el argumento de verificación:

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

Si no desea verificar su certificado SSL, haga verify=False

El nombre del archivo de CA para usar puede pasar por verify:

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

Si lo usa, verify=Trueentonces requestsusa su propio conjunto de CA que podría no tener CA que firmó su certificado de servidor.

$ pip install -U requests[security]

• Probado en Python 2.7.6 @ Ubuntu 14.04.4 LTS
• Probado en Python 2.7.5 @ MacOSX 10.9.5 (Mavericks)

Cuando se abrió esta pregunta (2012-05), la versión de Solicitudes era 0.13.1. En la versión 2.4.1 (2014-09) se introdujeron los extras de "seguridad", utilizando el certifipaquete si está disponible.

En este momento (2016-09) la versión principal es 2.11.1, que funciona bien sin ella verify=False . No es necesario usar requests.get(url, verify=False), si está instalado con requests[security]extras.

Encontré el mismo problema y el certificado SSL verificó un problema fallido al usar aws boto3, al revisar el código boto3, descubrí REQUESTS_CA_BUNDLEque no está configurado, así que solucioné ambos problemas configurándolo manualmente:

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

Para aws-cli, supongo que configurar REQUESTS_CA_BUNDLE ~/.bashrcsolucionará este problema (no probado porque mi aws-cli funciona sin él).

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

En caso de que tenga una biblioteca que se base requestsy no pueda modificar la ruta de verificación (como con pyvmomi), entonces tendrá que encontrar las cacert.pemsolicitudes agrupadas y agregar su CA allí. Aquí hay un enfoque genérico para encontrar la cacert.pemubicación:

ventanas

C:\>python -c "import requests; print requests.certs.where()"
c:\Python27\lib\site-packages\requests-2.8.1-py2.7.egg\requests\cacert.pem

linux

#  (py2.7.5,requests 2.7.0, verify not enforced)
root@host:~/# python -c "import requests; print requests.certs.where()"
/usr/lib/python2.7/dist-packages/certifi/cacert.pem

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

por cierto. @ request-devs, agrupar tus propias cacerts con request es realmente muy molesto ... especialmente el hecho de que no pareces usar el sistema ca store primero y esto no está documentado en ningún lado.

actualizar

en situaciones en las que está utilizando una biblioteca y no tiene control sobre la ubicación del paquete ca, también puede establecer explícitamente la ubicación del paquete ca para que sea el paquete ca de todo el host:

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

Tengo el mismo problema al usar gspread y estos comandos me funcionan:

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

Si desea eliminar las advertencias, use el código a continuación.

import urllib3

urllib3.disable_warnings()

y verify=Falsecon request.geto postmétodo

He encontrado un enfoque específico para resolver un problema similar. La idea es señalar el archivo cacert almacenado en el sistema y utilizado por otras aplicaciones basadas en SSL.

En Debian (no estoy seguro si es igual en otras distribuciones) los archivos de certificado (.pem) se almacenan en /etc/ssl/certs/So, este es el código que funciona para mí:

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

Para adivinar qué pemarchivo elegir, tengo que buscar la url y verificar qué Autoridad de certificación (CA) ha generado el certificado.

EDITAR: si no puede editar el código (porque está ejecutando una tercera aplicación), puede intentar agregar el pemcertificado directamente /usr/local/lib/python2.7/dist-packages/requests/cacert.pem(por ejemplo, copiarlo al final del archivo).

Si no te molesta el certificado, solo úsalo verify=False.

import requests

url = "Write your url here"

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

Después de horas de depuración, solo pude hacer que esto funcione con los siguientes paquetes:

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

utilizando OpenSSL 1.0.2g 1 Mar 2016

Sin estos paquetes verify=Falseno funcionaba.

Espero que esto ayude a alguien.

Me encontré con el mismo problema. Resulta que no había instalado el certificado intermedio en mi servidor (solo añádalo al final de su certificado como se ve a continuación).

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

Asegúrese de tener instalado el paquete de certificados de ca:

sudo apt-get install ca-certificates

Actualizar el tiempo también puede resolver esto:

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

Si está utilizando un certificado autofirmado, probablemente tendrá que agregarlo a su sistema manualmente.

Si las llamadas de solicitud están enterradas en algún lugar profundo del código y no desea instalar el certificado del servidor, entonces, solo con fines de depuración , es posible realizar solicitudes de monkeypatch:

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

¡Nunca lo use en producción!

Supongo que fue demasiado tarde para la fiesta, ¡pero quería pegar la solución para otros vagabundos como yo! Así que lo siguiente funcionó para mí en Python 3.7.x

Escriba lo siguiente en su terminal

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

Intente ejecutar su script / solicitudes nuevamente y vea si funciona (¡estoy seguro de que aún no se solucionará!). Si no funcionó, intente ejecutar el siguiente comando en la terminal directamente

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

Luché contra este problema por HORAS.

Traté de actualizar las solicitudes. Luego actualicé certifi. Apunté verificar a certifi.where () (el código hace esto de manera predeterminada de todos modos). Nada funcionó.

Finalmente actualicé mi versión de python a python 2.7.11. Estaba en Python 2.7.5 que tenía algunas incompatibilidades con la forma en que se verifican los certificados. Una vez que actualicé Python (y un puñado de otras dependencias) comenzó a funcionar.

Esto es similar a la respuesta de @ rafael-almeida, pero quiero señalar que a partir de las solicitudes 2.11+, no hay 3 valores que verifypuedan tomar, en realidad hay 4:

• True: valida contra las CA de confianza internas de las solicitudes.
• False: evita la validación del certificado por completo . (No recomendado)
• Ruta a un archivo CA_BUNDLE. las solicitudes usarán esto para validar los certificados del servidor.
• Ruta a un directorio que contiene archivos de certificados públicos. las solicitudes usarán esto para validar los certificados del servidor.

El resto de mi respuesta es sobre el n. ° 4, cómo usar un directorio que contiene certificados para validar:

Obtenga los certificados públicos necesarios y colóquelos en un directorio.

Estrictamente hablando, probablemente "debería" usar un método fuera de banda para obtener los certificados, pero también puede descargarlos usando cualquier navegador.

Si el servidor usa una cadena de certificados, asegúrese de obtener todos los certificados de la cadena.

De acuerdo con la documentación de las solicitudes, el directorio que contiene los certificados debe procesarse primero con la utilidad "rehash" ( openssl rehash).

(Esto requiere openssl 1.1.1+, y no todas las implementaciones de Windows openssl admiten rehash. Si openssl rehashno funciona para usted, puede intentar ejecutar el script rehash ruby ​​en https://github.com/ruby/openssl/blob/master /sample/c_rehash.rb , aunque no lo he intentado).

Tuve algunos problemas para obtener solicitudes para reconocer mis certificados, pero después de usar el openssl x509 -outform PEMcomando para convertir los certificados al .pemformato Base64 , todo funcionó a la perfección.

También puedes simplemente hacer una repetición perezosa:

try:
    # As long as the certificates in the certs directory are in the OS's certificate store, `verify=True` is fine.
    return requests.get(url, auth=auth, verify=True)
except requests.exceptions.SSLError:
    subprocess.run(f"openssl rehash -compat -v my_certs_dir", shell=True, check=True)
    return requests.get(url, auth=auth, verify="my_certs_dir")

Actualmente hay un problema en el módulo de solicitudes que causa este error, presente en v2.6.2 a v2.12.4 (ATOW): https://github.com/kennethreitz/requests/issues/2573

La solución para este problema es agregar la siguiente línea: 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'

Como mencionó @Rafael Almeida, el problema que tiene es causado por un certificado SSL no confiable. En mi caso, el servidor no confiaba en el certificado SSL. Para solucionar esto sin comprometer la seguridad, descargué el certificado y lo instalé en el servidor (simplemente haciendo doble clic en el archivo .crt y luego Instalar certificado ...).

No es factible agregar opciones si se solicitan solicitudes desde otro paquete. En ese caso, agregar certificados al paquete cacert es la ruta directa, por ejemplo, tuve que agregar "StartCom Class 1 Primary Intermediate Server CA", para lo cual descargué el certificado raíz en StartComClass1.pem. dado que mi virtualenv se llama caldav, agregué el certificado con:

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

uno de esos podría ser suficiente, no verifiqué

Estaba teniendo un problema de validación de certificación similar o similar. Leí que las versiones de OpenSSL inferiores a la 1.0.2, de las cuales depende la solicitud, a veces tienen problemas para validar certificados sólidos (ver aquí ). CentOS 7 parece usar 1.0.1e, que parece tener el problema.

No estaba seguro de cómo solucionar este problema en CentOS, así que decidí permitir certificados CA de 1024 bits más débiles.

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

Tuve que actualizar de Python 3.4.0 a 3.4.6

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

En mi caso, la razón fue bastante trivial.

Sabía que la verificación SSL había funcionado hasta unos días antes, y de hecho estaba trabajando en una máquina diferente.

El siguiente paso fue comparar el contenido y el tamaño del certificado entre la máquina en la que funcionaba la verificación y la que no.

Esto rápidamente me llevó a determinar que el Certificado en la máquina que funcionaba "incorrectamente" no era bueno, y una vez que lo reemplacé con el certificado "bueno", todo estuvo bien.