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

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

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

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.

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

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"

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

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.

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 ).

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.

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'

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

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.

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"

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

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.

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).

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.