Impossible de vérifier localement l'autorité de l'émetteur

19

Je ne peux pas ouvrir d'URL https à l'aide de wget ou 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.

Cela utilise wget 1.12 et curl 7.30.0 sur CentOS 5.5. Il semble que quelque chose ne va pas avec mon magasin de certificats local, mais je ne sais pas comment procéder à partir d'ici. Des idées?

Mise à jour: après la mise à niveau du paquet openssl de 0.9.8e-12.el5_4.6 à 0.9.8e-33.el5_11, il y a maintenant une erreur différente:

$ 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
la source
Je pense que les certificats racine sont dans le ca-certificatespackage. Ce package est-il installé? Essayez peut-être de le réinstaller. Si ce n'est pas le problème, exécutez strace -o /tmp/wget.strace wget https://www.python.orget publiez la trace résultante, cela devrait nous dire où est le problème.
Gilles 'SO- arrête d'être méchant'
@Gilles - J'ai mis à niveau le paquet openssl de 0.9.8e-12.el5_4.6 à 0.9.8e-33.el5_11 et l'erreur a disparu (peut-être que cela a réinstallé les certificats racine?), Mais maintenant il y a une erreur différente.
aco
Cela ressemble à une erreur transitoire avec ce site spécifique. Les autres sites fonctionnent-ils?
Gilles 'SO- arrête d'être méchant'
@Gilles - Les autres sites Web ne fonctionnent pas non plus. Par exemple, Google renvoie l'erreur: le nom commun du certificat "google.com" ne correspond pas au nom d'hôte demandé "www.google.com.au".
aco
Je pourrais résoudre le même problème en désactivant Selinux: crypt.gen.nz/selinux/disable_selinux.html Cheers!

Réponses:

2

wgetavant 1.14 ne prend pas en charge le nom alternatif du sujet (SAN) *. PyPI utilise un SAN comme alternative à son CN dans son certificat, et wget s'étouffe sur l'inadéquation. La mise à niveau de wget devrait le résoudre.

* ou éventuellement indication de nom de serveur (SNI) - je ne sais pas ce qui s'applique ici.

Les références:

Heath Raftery
la source
1

Solution 1:

openssl s_client -connect whateversite.com:443 -debug

Obtenez la clé de certificat et copiez-la /etc/ssl/certs.

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

Si vous voulez aller de manière non sécurisée, essayez la solution 2

Solution 2:

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

ou en utilisant Curl 

$ curl https://www.python.org --insecure
Ruban Savvy
la source
9
«Docteur, je ne peux pas marcher sur ma jambe gauche. - Solution 1: déplacez ce dont vous avez besoin près de votre chaise pour ne pas avoir à vous lever. Solution 2: hop. »Non, la solution est de résoudre le problème. Ce qui, ici, signifie réparer ou réinstaller les certificats d'autorité de certification racine.
Gilles 'SO- arrête d'être méchant'
4
ce n'est bon que pour les certificats auto-signés auto-signés
Pavel Niedoba
1
Oui, c'est une mauvaise idée. La solution 1 n'est pas sûre non plus . Tout ce que vous faites est de contourner la vérification de wget en faisant automatiquement confiance au certificat à partir de ce point. Vous devriez résoudre le problème sous-jacent en réparant les certificats racine auxquels Wget a accès.
Andrew Ferrier
Bien que ce ne soit qu'une solution de contournement si vos administrateurs système vous obligent à utiliser des listes de certificats racine brisées ou des paramètres de sécurité draconiens, cela ne mérite pas la haine.
nurettin
0

Mettez à jour l'heure sur le serveur. Une seconde peut provoquer ce problème!

Vérifier avec: 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

user1926449
la source
0

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

Robert A
la source
1
C'est assez dangereux à suggérer.
ploth
Cela ne concerne que la wgetcommande et ce n'est pas une solution mais une solution de contournement.
mrc02_kr