la verificación del certificado del servidor falló. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none


335

Puedo presionar por clonar un proyecto usando ssh, pero no funciona cuando clono un proyecto con https.

El mensaje de error que me muestra es:

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none

Respuestas:


422

TLDR:

hostname=XXX
port=443
trust_cert_file_location=`curl-config --ca`

sudo bash -c "echo -n | openssl s_client -showcerts -connect $hostname:$port -servername $hostname \
    2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  \
    >> $trust_cert_file_location"

Respuesta larga

La razón básica es que su computadora no confía en la autoridad de certificación que firmó el certificado utilizado en el servidor de Gitlab . Esto no significa que el certificado sea sospechoso, pero podría ser autofirmado o firmado por una institución / empresa que no está en la lista de CA de su sistema operativo. Lo que debe hacer para evitar el problema en su computadora es decirle que confíe en ese certificado, si no tiene ningún motivo para sospechar de él.

Debe verificar el certificado web utilizado para su servidor gitLab y agregarlo a su </git_installation_folder>/bin/curl-ca-bundle.crt.

Para verificar si al menos el clon funciona sin verificar dicho certificado, puede configurar:

export GIT_SSL_NO_VERIFY=1
#or
git config --global http.sslverify false

Pero eso sería solo para pruebas, como se ilustra en " SSL funciona con el navegador, wget y curl, pero falla con git ", o en esta publicación de blog .

Compruebe la configuración de un GitLab, en cuestión de 4272 .


Para obtener ese certificado (que necesitaría agregar a su curl-ca-bundle.crtarchivo), escriba a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

(con ' yourserver.com' ser el nombre de su servidor GitLab, y YourHttpsGitlabPortgeneralmente es el puerto https 443)

Para verificar la entidad emisora ​​de certificados (entidad emisora ​​de certificados), escriba a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGilabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | openssl x509 -noout -text | grep "CA Issuers" | head -1

Nota: Valeriy Katkov sugiere en los comentarios agregar una -servernameopción al comando openssl, de lo contrario, el comando no se muestra certificado para www.github.com en el caso de Valeriy.

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Findekano agrega en los comentarios :

para identificar la ubicación de curl-ca-bundle.crt, podría usar el comando

curl-config --ca

Además, vea mi respuesta más reciente " github: la verificación del certificado del servidor falló ": es posible que deba volver a instalar esos certificados:

sudo apt-get install --reinstall ca-certificates
sudo mkdir /usr/local/share/ca-certificates/cacert.org
sudo wget -P /usr/local/share/ca-certificates/cacert.org http://www.cacert.org/certs/root.crt http://www.cacert.org/certs/class3.crt
sudo update-ca-certificates
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt

8
¿El mensaje original no indica dónde agregar el certificado? En mi caso curl-config --cadevuelto /etc/ssl/certs/ca-certificates.crt, que es donde tuve que agregar el certificado. Aparte de eso, esta respuesta fue la primera información que me señaló en la dirección correcta con este problema
uli_1973

1
¿Cómo encuentras la carpeta de instalación de git?
Bhargav

1
@Bhargav depende de su sistema operativo. En Linux, puedes hacer un which git.
VonC

3
Corrí curl-config --ca, pero no me devolvieron nada.
Fernando Costa

1
Gracias por el consejo, me salvaste el día.
Janne

220

Nota: Esto tiene importantes implicaciones de seguridad.

Abra su terminal y ejecute el siguiente comando:

export GIT_SSL_NO_VERIFY=1

Funciona para mí y estoy usando el sistema Linux.


6060
No hacer downvoting porque es una solución para cuando sabes lo que estás haciendo. Sin embargo, recomendamos encarecidamente contra esto en el caso general.
tripleee

99
No diría que es una solución cuando sabes lo que estás haciendo. Cuando sabes lo que estás haciendo, deberías mirar un certificado que falla como "tal vez alguien nos hackeó" no "oh bueno, la seguridad dice que alguien nos hackeó, supongo que debemos desactivar la seguridad". En el mejor de los casos, es una medida provisional si algo necesita ser empujado lo antes posible.
srcspider

1
al exportar el indicador anterior, obtengo un error inferior. error: RPC falló; resultado = 22, código HTTP = 403 fatal: el extremo remoto colgó inesperadamente error: RPC falló; resultado = 22, código HTTP = 403 fatal: el extremo remoto colgó inesperadamente
Desu

8
Sólo trabajado para mí congit config --global http.sslverify false
Dinei

2
Excelente. Me salvaste el tiempo.
Sai prateek

146

Otra causa de este problema podría ser que su reloj podría estar apagado. Los certificados son sensibles al tiempo.

Para verificar la hora actual del sistema:

date -R

Puede considerar instalar NTP para sincronizar automáticamente la hora del sistema con servidores de tiempo de Internet confiables del grupo NTP global . Por ejemplo, para instalar en Debian / Ubuntu:

apt-get install ntp

55
Este fue mi problema. Mi universidad estaba bloqueando paquetes ntp, lo que impedía que mi sistema actualizara el tiempo. Una vez que configuré los servidores ntp de la universidad, las cosas volvieron a funcionar. Gracias por este consejo!
Kyle

3
Esta también fue la causa de mi problema, ¡estaba usando un dispositivo incorporado que tenía una fecha incorrecta!
Shervin Emami

Este fue mi problema, con certs. Pasé horas buscando todo tipo de soluciones antes de descubrir que el problema era que el reloj del servidor se estaba preparando para el futuro. Sin embargo, no me ayudó a obtener una versión futura de Node.js. :-(
Kevin Teljeur el

1
@Katu no es gitpor decir, es el intercambio SSL subyacente. Git está construido con soporte SSL.
Yvan

1
Lo voté 10000 veces ... he estado buscando por qué no funcionó durante 6 horas completas ahora ... El servidor estuvo apagado por menos de 7 minutos y esto funcionó ... ¡GRACIAS!
dGo

66

Si está utilizando un servidor git dentro de una red privada y está utilizando un certificado autofirmado o un certificado sobre una dirección IP; También puede simplemente usar la configuración global de git para deshabilitar las comprobaciones de SSL:

git config --global http.sslverify "false"

43

Tuve el mismo problema Causado por la autoridad de certificación auto emitida. Lo resolvió agregando el archivo .pem a / usr / local / share / ca-certificados / y llamando

sudo update-ca-certificates

PD: el archivo pem en la carpeta ./share/ca-certificates DEBE tener la extensión .crt


2
Trabajó como un encanto en linux mint 16 :)
greuze

¿te refieres a cert.pem o cert.crt o cert.pem.crt?
Moses Liao GZ

1
cert.pem debería renombrarse a cert.pem.crt
Nikolay Ruban

34

Comprueba el reloj de tu sistema,

$ date

Si no es correcto, la verificación del certificado fallará. Para corregir el reloj del sistema,

$ apt-get install ntp

El reloj debe sincronizarse solo.

Finalmente ingrese el comando clonar nuevamente.


1
¡Si! Tuve una instancia de Ubuntu suspendida en VirtualBox durante mucho tiempo. El reloj del sistema no se sincronizó por el motivo que sea cuando lo suspendí. La respuesta de VonC parece estar bien informada, pero estoy muy contento de no tener que ejecutar un montón de comandos de seguridad que no entiendo. ¡Mira esto primero!
AndyJost

24
GIT_CURL_VERBOSE=1 git [clone|fetch]…

debería decirte dónde está el problema. En mi caso, se debió a que cURL no admitía certificados PEM cuando se creó contra NSS, debido a que ese soporte no era la línea principal en NSS ( # 726116 # 804215 # 402712 y más ).


44
Buena adición con el GIT_CURL_VERBOSE. No lo mencioné en mi respuesta. +1
VonC

18

O simplemente ejecute este comentario para agregar el Certificado del servidor a su base de datos:

echo $(echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpGilabPort 2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p') >> /etc/ssl/certs/ca-certificates.crt

Luego haz git clone nuevamente.


1
No sé si esto funciona para alguien, pero necesito "tee" para agregar el archivo cert como root: echo -n | openssl s_client -showcerts -connect yourserver.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt
ywu

En mi caso, el servidor tiene un certificado válido, pero mi base de datos no lo incluye, con este comando lo resolví pero debo decir que este comando debe ejecutarse con privilegios de root.
hermeslm

10

Me equivoqué con mis archivos CA mientras configuraba el proxy de goagent. No se pueden extraer datos de github y obtener la misma advertencia:

la verificación del certificado del servidor falló. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

use el método de Vonc, obtenga el certificado de github y póngalo en /etc/ssl/certs/ca-certificates.crt, problema resuelto.

echo -n | openssl s_client -showcerts -connect github.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p'


8

no es necesario configurar la verificación git ssl para que sea falso. Se produce cuando el sistema no tiene todos los certificados de autoridad de CA. La mayoría de las personas que tienen un certificado SSL genuino no tienen el certificado intermedio.

Simplemente agregue el texto completo del certificado intermedio (toda la cadena de CA faltante y certificado intermedio) a

sudo gedit /etc/ssl/certs/ca-certificates.crt 

funciona sin ejecutar el update-ca-certificates.

Lo mismo ocurre con los certificados generados manualmente, solo agregue el texto del certificado de CA.

Al final: Empuje exitoso: todo está actualizado


1
Lo mismo puede ser causado si el servidor no está configurado correctamente con toda la cadena de CA SSL.
abcdef12

Los problemas de la cadena pueden ser la causa, como comentó abcdef12. Tuve este problema con git 1.9.1: el servidor estaba enviando la cadena de certificados: # 0 server cert; Certificado de servidor n. ° 1 (nuevamente); Certificado de firmante n. ° 2 El duplicado en la cadena era la razón por la que a git no le gustaba.
jah

8

Lo que hice para resolver este problema en el terminal (Ubuntu 18.04):

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Tengo dos trozos de trozos de certificado. Y copié los fragmentos de certificado en mi archivo de certificado a /etc/ssl/certs/ca-certificates.crt.


Esta solución resuelve mi problema idéntico en Ubuntu 16.04.
user3072843

¿Qué quieres decir exactamente con trozos de certificado ? El bloque entre ---BEGIN CERTIFICATE---y --- END CERTIFICATE ---?
B - rian

3

Instalé Xubuntu en una Raspberry pi 2, encontré el mismo problema con el tiempo, ya que NTP y la sincronización automática del servidor estaban apagadas (o no instaladas). Obtener NTP

sudo apt-get install ntp

y cambie la "Hora y fecha" de "Manual" a "Mantener sincronizado con los servidores de Internet"


1

Finalmente, agregue http.sslverify a su .git / config.

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://server/user/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[http]
        sslVerify = false

1
Es mejor usar la línea de comando git config http.sslVerify false. ¿Está sugiriendo editar la configuración de Git por repositorio, no globalmente como lo sugiere @ romain-vdk?
ahogen

1

Lo primero que debe verificar es el permiso de archivo de /etc/ssly /etc/ssl/certs.

Cometí el error de eliminar los permisos de archivo (o eliminar los rm -rf /etc/ssl/*directorios SSL ) al usar el ssl-certnombre / ID del grupo mientras trabajaba en mi herramienta de administración de autoridad de certificación .

Fue entonces cuando noté exactamente el mismo mensaje de error wgety curllas herramientas del navegador CLI:

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Una vez que traje el permiso de archivos /etc/ssly /etc/ssl/certdirectorios o+rx-w, esas herramientas del navegador CLI comenzaron a respirar un poco más fácil:

mkdir -p /etc/ssl/certs
chmod u+rwx,go+rx /etc/ssl /etc/ssl/certs

También tuve que recrear el subdirectorio Java y reconstruir los directorios de certificados de Trusted CA:

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
update-ca-certificates

y la costa estaba despejada.


0

Acabo de encontrar el mismo problema con un repositorio git que siempre funciona para mí. El problema fue que accedí a través del acceso WiFi público, que redirige a un portal cautivo en la primera conexión (por ejemplo, para mostrar anuncios y aceptar tos).


0

Copie el certificado y el paquete en un archivo .crt y asegúrese de que haya una línea en blanco entre los certificados en el archivo.

Esto funcionó para mí en un servidor GitLab después de probar todo en Internet.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.