cURL ne fonctionne pas (erreur n ° 77) pour les connexions SSL sous CentOS pour les utilisateurs non root
Récemment, mon serveur a cessé de fonctionner pour les requêtes curl envoyées aux adresses https: // de mon serveur Web. Après avoir fouillé un peu, il semble que le serveur Web fonctionne en raison d’un problème.
Si je SSH sur le serveur en tant que root et appelle
curl -I -v https://google.com
... Je reçois la réponse suivante ...
* About to connect() to google.com port 443 (#0)
* Trying 173.194.67.113... connected
* Connected to google.com (173.194.67.113) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_SHA
* Server certificate:
* subject: CN=*.google.com,O=Google Inc,L=Mountain View,ST=California,C=US
* start date: May 22 15:50:20 2013 GMT
* expire date: Oct 31 23:59:59 2013 GMT
* common name: *.google.com
* issuer: CN=Google Internet Authority,O=Google Inc,C=US
> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: google.com
> Accept: */*
Toutefois, si je me connecte à l’un des comptes cPanel (également utilisé lors de l’exécution via le serveur Web), j’obtiens ce qui suit ...
* About to connect() to google.com port 443 (#0)
* Trying 173.194.67.101... connected
* Connected to google.com (173.194.67.101) port 443 (#0)
* Initializing NSS with certpath: none
* NSS error -5978
* Closing connection #0
* Problem with the SSL CA cert (path? access rights?)
curl: (77) Problem with the SSL CA cert (path? access rights?)
Je n'ai pas été en mesure de trouver une réponse définitive au problème, et ma société d'hébergement refuse de vous aider car elle est "en panne de support" même si cela a fonctionné correctement la semaine dernière!
J'ai trouvé la mention sur http://curl.haxx.se/docs/sslcerts.html that
"Si libcurl a été construit avec le support NSS, alors, selon la distribution du système d'exploitation, , Il sera probablement nécessaire de prendre des mesures supplémentaires pour utiliser la base de données CA Cert à l'échelle du système. RedHat est livré avec un module supplémentaire, libnsspem. Ainsi, ce qui permet à NSS de lire le paquet OpenSSL PEM CA. Cette bibliothèque est manquante dans OpenSuSE, et sans lui, NSS ne peut fonctionner qu'avec ses propres formats internes. NSS a également un nouveau format de base de données : https://wiki.mozilla.org/NSS_Shared_DB "
... mais je ne trouve aucune information sur la manière dont cela fonctionne sur l'ensemble du système sur mon serveur CentOS.
Info
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Quelqu'un peut-il expliquer pourquoi cela pourrait avoir soudainement changé ou, mieux encore, comment y remédier?
Merci
Il s'avère que le problème provenait de face que le script était exécuté à partir d'un "e-mail dirigé vers un script" de cPanel. Il était donc exécuté en tant qu'utilisateur. Il s'agissait donc d'un problème d'utilisateur, qui n'affectait pas du tout le serveur Web.
L'incapacité de l'utilisateur à accéder au répertoire/etc/pki était due au fait qu'il ne disposait que d'un accès ssh jailed. Une fois que j'ai accordé un accès complet, tout a bien fonctionné.
Merci pour l'info cependant, Rémi.
Si vous êtes récemment arrivé ici, comme je l’ai fait lors de la recherche de la même erreur en vain, vous constaterez peut-être qu’il s’agit d’une mise à jour de NSS provoquant un échec sur CentOS. Testez en exécutant yum update et voyez si vous obtenez des erreurs, curl crée également cette erreur. La solution est assez simple, il suffit d'installer NSS manuellement.
Continuer à lire...
Si vous êtes comme moi, une erreur semblable à celle-ci s'est produite:
curl: (77) Problem with the SSL CA cert (path? access rights?)
Cela a pris un certain temps à résoudre, mais a révélé que ce n'était pas la certification CA, car en les recréant et en vérifiant toute la configuration, je l'avais exclue. Cela aurait pu être libcurl alors je suis allé à la recherche de mises à jour.
Comme mentionné, j'ai recréé des certs CA. Vous pouvez le faire aussi, mais cela risque d’être une perte de temps. http://wiki.centos.org/HowTos/Https
La prochaine étape (devrait probablement être la première) était de vérifier que tout était à jour en exécutant simplement yum.
$ yum update
$ yum upgrade
Cela m'a donné une réponse affirmative qu'il y avait un problème plus important en jeu: Downloading Packages:
error: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD
Problem opening package nss-softokn-freebl-3.14.3–19.el6_6.x86_64.rpm J'ai commencé à lire sur la vérification des certificats avec NSS et sur le lien possible entre cette nouvelle mise à jour et mes problèmes. En effet, nss-softokn- * a besoin de nss-softokn-freebl- * a besoin de l'autre pour fonctionner. Le problème est qu'ils ne vérifient pas la compatibilité de leurs versions respectives et que, dans certains cas, cela finit par casser miam .
$ wget http://mirrors.linode.com/centos/6.6/updates/x86_64/Packages/nsssoftokn-freebl-3.14.3-19.el6_6.x86_64.rpm
$ rpm -Uvh nss-softokn-freebl-3.14.3–19.el6_6.x86_64.rpm
$ yum update
Vous devez bien sûr télécharger depuis le miroir le plus proche et vérifier la version/le système d'exploitation correct, etc. Nous avons essentiellement téléchargé et installé la mise à jour à partir du rpm pour corriger le problème. Comme @grumpysysadmin l'a souligné, vous pouvez raccourcir les commandes. @cwgtex a contribué à l'installation de la mise à niveau à l'aide de la commande RPM, ce qui simplifie encore le processus.
Pour résoudre les problèmes avec wordpress, vous devez redémarrer votre serveur http.
$ service httpd restart
Réessayez et succès!
Vérifiez que vous disposez des droits appropriés sur le groupe de certificats d’autorité de certification. Cela signifie généralement que tout le monde a accès en lecture aux fichiers CA du répertoire/etc/ssl/certs, par exemple /etc/ssl/certs/ca-certificates.crt.
Vous pouvez voir quels fichiers ont été configurés pour votre version curl avec le
$ curl-config --configure
'--prefix=/usr'
'--mandir=/usr/share/man'
'--disable-dependency-tracking'
'--disable-ldap'
'--disable-ldaps'
'--enable-ipv6'
'--enable-manual'
'--enable-versioned-symbols'
'--enable-threaded-resolver'
'--without-libidn'
'--with-random=/dev/urandom'
'--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt'
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
'CPPFLAGS=-D_FORTIFY_SOURCE=2'
Vous devez avoir ici un accès en lecture à /etc/ssl/certs/ca-certificates.crt
$ curl-config --configure
'--build' 'i486-linux-gnu'
'--prefix=/usr'
'--mandir=/usr/share/man'
'--disable-dependency-tracking'
'--enable-ipv6'
'--with-lber-lib=lber'
'--enable-manual'
'--enable-versioned-symbols'
'--with-gssapi=/usr'
'--with-ca-path=/etc/ssl/certs'
'build_alias=i486-linux-gnu'
'CFLAGS=-g -O2'
'LDFLAGS='
'CPPFLAGS='
Et pareil ici.
L'erreur est due à des fichiers de certificat de chaîne SSL corrompus ou manquants dans le répertoire PKI. Vous devez vous assurer que les fichiers sont bien regroupés en procédant comme suit: Dans votre console/terminal:
mkdir /usr/src/ca-certificates && cd /usr/src/ca-certificates
Entrez ce site: https://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates , obtenez votre certificat CA, pour votre SO, par exemple: ftp: //rpmfind.net/linux/Fedora/linux/updates/24/x86_64/c/ca-certificates-2016.2.8-1.0.fc24.noarch.rpm << CentOS. Copier l’URL du téléchargement et le coller dans l’URL: wget your_url_donwload_ca-ceritificated.rpmnow, installez votre rpm:
rpm2cpio your_url_donwload_ca-ceritificated.rpm | cpio -idmv
maintenant redémarrez votre service: mon exemple cette commande:
Sudo service2 httpd restart
très bien bon look
Je viens d'avoir un problème similaire avec l'erreur n ° 77 sur CentOS7. Il me manquait le lien symbolique /etc/pki/tls/certs/ca-bundle.crt qui est installé avec le RPM ca-certificates.
'curl' essayait d'ouvrir ce chemin pour obtenir les autorités de certification. J'ai découvert avec:
strace curl https://example.com
et vu clairement que l'ouverture a échoué sur ce lien.
Ma solution était:
yum reinstall ca-certificates
Cela devrait tout régler à nouveau. Si vous avez des autorités de certification privées pour une utilisation en entreprise ou avec une signature automatique, assurez-vous qu'elles se trouvent dans/etc/pki/ca-trust/source/anchor pour pouvoir les rajouter.
J'avais le même problème à chaque fois que j'essayais d'exécuter curl sur mon serveur https.
About to connect() to localhost port 443 (#0)
Trying ::1...
Connected to localhost (::1) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
J'ai observé ce problème lorsque j'ai mal configuré le chemin du magasin de clés. Après avoir corrigé le chemin du magasin de clés, cela a fonctionné.