cURL no funciona(Error#77) para conexiones SSL en CentOS para usuarios no root
nss (6)
Acabo de tener un problema similar con el error # 77 en CentOS7. Me faltaba el enlace /etc/pki/tls/certs/ca-bundle.crt que está instalado con el RPM de certificados ca.
''curl'' intentaba abrir esta ruta para obtener las Autoridades de Certificación. Lo descubrí con:
strace curl https://example.com
y vio claramente que el abierto falló en ese enlace.
Mi solución fue:
yum reinstall ca-certificates
Eso debería configurar todo de nuevo. Si tiene CA privadas para uso corporativo o autofirmado, asegúrese de que estén en / etc / pki / ca-trust / source / anchors para que se vuelvan a agregar.
Recientemente, mi servidor dejó de funcionar para las solicitudes de curl a direcciones https: // para mi servidor web. Después de buscar un poco, parece que es un problema con el usuario que ejecuta el servidor web.
Si hago SSH en el servidor como root & call
curl -I -v https://google.com
... recibo la siguiente respuesta ...
* 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: */*
Sin embargo, si inicio sesión como cualquiera de las cuentas de cPanel (también se usa cuando se ejecuta a través del servidor web) obtengo lo siguiente ...
* 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?)
¡No he podido encontrar una respuesta definitiva al problema, y mi empresa de alojamiento se niega a ayudar ya que está "Fuera de soporte" a pesar de que funcionó bien la semana pasada!
Encontré una mención en http://curl.haxx.se/docs/sslcerts.html que
"Si libcurl se creó con soporte de NSS, entonces, dependiendo de la distribución del sistema operativo, es probable que se requieran algunos pasos adicionales para usar el certificado de CA de todo el sistema. RedHat se envía con un módulo adicional, libnsspem.so, que permite a NSS lea el paquete OpenSSL PEM CA. Falta esta biblioteca en OpenSuSE y, sin ella, NSS solo puede trabajar con sus propios formatos internos. NSS también tiene un nuevo formato de base de datos: https://wiki.mozilla.org/NSS_Shared_DB "
... pero no puedo encontrar información sobre cómo funciona este sistema en todo mi sistema en mi servidor CentOS.
Información
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
¿Alguien puede arrojar algo de luz sobre por qué esto podría haber cambiado repentinamente, o mejor aún cómo solucionarlo?
Gracias
Compruebe que tiene los derechos correctos establecidos en el paquete de certificados de CA. Por lo general, eso significa acceso de lectura para todos a archivos CA en el directorio / etc / ssl / certs, por ejemplo /etc/ssl/certs/ca-certificates.crt.
Puede ver qué archivos se han configurado para su versión de rizo con el
curl-config --configure comando:
$ 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''
Aquí necesita acceso de lectura a /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=''
Y lo mismo aquí.
El error se debe a archivos de certificado de cadena SSL corruptos o faltantes en el directorio PKI. Deberá asegurarse de que los archivos se agrupen, siguiendo estos pasos: En su consola / terminal:
mkdir /usr/src/ca-certificates && cd /usr/src/ca-certificates
Ingrese a este sitio: https://rpmfind.net/linux/rpm2html/search.php?query=ca-certificates , obtenga su certificado CA, para su SO SO, por ejemplo: ftp://rpmfind.net/linux/fedora/linux/updates/24/x86_64/c/ca-certificates-2016.2.8-1.0.fc24.noarch.rpm << CentOS. Copie la url de descarga y péguela en url: wget your_url_donwload_ca-ceritificated.rpm ahora, instale yout rpm:
rpm2cpio your_url_donwload_ca-ceritificated.rpm | cpio -idmv
ahora reinicie su servicio: mi ejemplo este comando:
sudo service2 httpd restart
muy bien buena mirada
Me había enfrentado al mismo problema cada vez que intentaba ejecutar curl en mi servidor 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
Observé este problema cuando configuré incorrectamente la ruta del almacén de claves. Después de corregir la ruta del almacén de claves funcionó.
Resulta que el problema fue con la cara que el script se estaba ejecutando desde un cPanel "correo electrónico enviado a un script", por lo que se estaba ejecutando como usuario, por lo que era un problema del usuario, pero no afectaba en absoluto al servidor web.
La causa por la cual el usuario no pudo acceder al directorio / etc / pki se debió a que solo tenían acceso ssh a la cárcel. Una vez que concedí el acceso completo, todo funcionó bien.
Gracias por la información, Remi.
Si llegó recientemente aquí como lo hice cuando busqué el mismo error en vano, puede encontrar que es una actualización de NSS que causa fallos en CentOS. Pruebe ejecutando yum update y vea si obtiene errores, curl también crea este error. La solución es bastante simple, simplemente instale NSS manualmente.
Sigue leyendo
Si eres como yo arrojó un error similar a este:
curl: (77) Problem with the SSL CA cert (path? access rights?)
Esto tomó algún tiempo para resolverlo, pero descubrió que no era el certificado de CA porque al recrearlo y verificar toda la configuración que había descartado. Podría haber sido libcurl, así que fui en busca de actualizaciones.
Como mencioné recreé los certificados de CA. Puedes hacer esto también, pero puede ser una pérdida de tiempo. http://wiki.centos.org/HowTos/Https
El siguiente paso (probablemente debería haber sido mi primero) fue verificar que todo estuviera actualizado simplemente ejecutando yum.
$ yum update
$ yum upgrade
Esto me dio una respuesta afirmativa de que había un problema mayor en juego: 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 Comencé a leer sobre Verificación de certificados con NSS y cómo esta nueva actualización puede estar relacionada con mis problemas. Así que yum está roto. Esto se debe a que nss-softokn- * necesita nss-softokn-freebl- * se necesitan mutuamente para funcionar. El problema es que no verifican la compatibilidad de las demás versiones y, en algunos casos, terminan rompiendo yum. Vamos a arreglar las cosas:
$ 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
Por supuesto, debe descargar de su espejo más cercano y verificar la versión correcta / SO, etc. Básicamente, descargamos e instalamos la actualización desde el rpm para arreglar yum. Como @grumpysysadmin señaló, puede acortar los comandos. @cwgtex contribuyó a que debería instalar la actualización utilizando el comando RPM, lo que simplifica aún más el proceso.
Para arreglar las cosas con wordpress necesitas reiniciar tu servidor http.
$ service httpd restart
Intenta de nuevo y el éxito!