No se puede verificar localmente la autoridad del emisor

19

No puedo abrir ninguna URL https usando wget o curl:

$ wget https://www.python.org
--2015-04-27 17:17:33--  https://www.python.org/
Resolving www.python.org (www.python.org)... 103.245.222.223
Connecting to www.python.org (www.python.org)|103.245.222.223|:443... connected.
ERROR: cannot verify www.python.org's certificate, issued by "/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA":
  Unable to locally verify the issuer's authority.
To connect to www.python.org insecurely, use '--no-check-certificate'.

$ curl https://www.python.org
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Esto está usando wget 1.12 y curl 7.30.0 en CentOS 5.5. Parece que algo está mal con mi tienda de certificados local, pero no tengo idea de cómo proceder desde aquí. ¿Algunas ideas?

Actualización: después de actualizar el paquete openssl de 0.9.8e-12.el5_4.6 a 0.9.8e-33.el5_11, ahora hay un error diferente:

$ wget https://pypi.python.org
--2015-04-28 10:27:35--  https://pypi.python.org/
Resolving pypi.python.org (pypi.python.org)... 103.245.222.223
Connecting to pypi.python.org (pypi.python.org)|103.245.222.223|:443... connected.
ERROR: certificate common name "www.python.org" doesn't match requested host name "pypi.python.org".
To connect to pypi.python.org insecurely, use '--no-check-certificate'.
centos ssl certificates aco
fuente
Creo que los certificados raíz están en el ca-certificatespaquete. ¿Está instalado este paquete? Tal vez intente reinstalarlo. Si ese no es el problema, ejecute strace -o /tmp/wget.strace wget https://www.python.orgy publique el seguimiento resultante, eso debería decirnos dónde está el problema.
Gilles 'SO- deja de ser malvado'
@Gilles: actualicé el paquete openssl de 0.9.8e-12.el5_4.6 a 0.9.8e-33.el5_11 y el error desapareció (¿quizás esto reinstaló los certificados raíz?), Pero ahora hay un error diferente.
aco
Eso parece un error transitorio con este sitio específico. ¿Funcionan otros sitios?
Gilles 'SO- deja de ser malvado'
@Gilles - Otros sitios web tampoco funcionan. Por ejemplo, Google devuelve el error: el nombre común del certificado "google.com" no coincide con el nombre de host solicitado "www.google.com.au".
aco
Podría solucionar el mismo problema deshabilitando Selinux: crypt.gen.nz/selinux/disable_selinux.html ¡Salud!

Respuestas:

2

wgetanterior a 1.14 no admite Nombre alternativo del sujeto (SAN) *. PyPI utiliza una SAN como alternativa a su CN en su certificado, y wget se está ahogando con la falta de coincidencia. La actualización de wget debería resolverlo.

* o posiblemente Indicación del nombre del servidor (SNI): no estoy seguro de qué se aplica aquí.

Referencias

Heath Raftery
fuente
1

Solución 1:

openssl s_client -connect whateversite.com:443 -debug

Obtenga la clave del certificado y cópiela en /etc/ssl/certs.

$ wget https://www.python.org --ca-certificate=/etc/ssl/certsfile

Si quieres ir de forma insegura, prueba la solución 2

Solución 2:

$ wget https://www.python.org --no-check-certificate

o usando Curl 

$ curl https://www.python.org --insecure
Ruban Savvy
fuente
9
“Doctor, no puede caminar sobre la pierna izquierda. - Solución 1: mueva lo que necesita cerca de su silla para que no necesite pararse. Solución 2: salta ”. No, la solución es curar el problema. Lo cual, aquí, significa reparar o reinstalar los certificados de CA raíz.
Gilles 'SO- deja de ser malvado'
44
esto solo es bueno para certificados
autofirmados
1
Sí, esta es una mala idea. Solución 1 es inseguro demasiado . Todo lo que está haciendo es pasar por alto la verificación de wget al confiar automáticamente en el certificado a partir de este momento. Debería solucionar el problema subyacente solucionando realmente los certificados raíz a los que wget tiene acceso.
Andrew Ferrier
Aunque esto es solo una solución si sus administradores de sistemas lo obligan a usar listas de certificados raíz rotas o configuraciones de seguridad draconianas, no merece el odio.
nurettin
0

Actualiza la hora en el servidor. ¡Un segundo puede causar este problema!

Comprobar con: date

Redhat / CentOS 6/7 yum -y install ntpdate; /usr/sbin/ntpdate -u pool.ntp.org

Ubuntu / Debian apt-get -y install ntpdate; /usr/sbin/ntpdate -u pool.ntp.org

usuario1926449
fuente
0

echo "check_certificate = off" >> ~ / .wgetrc

Robert A
fuente
1
Esto es bastante peligroso de sugerir.
tela
Esto se refiere solo al wgetcomando y no es la solución sino la solución.
mrc02_kr