fatal: unable to access 'https://git.example.com/team/app.git/': server verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)

La URL es la de tu remoto. Las versiones más antiguas de Debian y Ubuntu (libcurl 7.x) imprimen el texto más corto «server certificate verification failed. CAfile: none CRLfile: none», donde «CAfile: none» solo significa que no se configuró ningún archivo de CA explícito y se usó el bundle del sistema.

Qué significa

El transporte HTTPS de git (libcurl compilado con GnuTLS en Debian y Ubuntu) no pudo verificar el certificado del servidor Git: ningún certificado de la cadena lleva a una CA del bundle que lee. «certificate signer not trusted» es la forma en que GnuTLS dice que el emisor es desconocido; todavía no se ha comprobado nada de tus credenciales ni del repositorio.

Por qué ocurre

• GitLab, Gitea o Bitbucket autoalojados con un certificado de la empresa

  frecuente

  Los servidores Git autoalojados suelen tener certificados emitidos por una CA interna. Los equipos de los desarrolladores reciben esa raíz mediante la gestión de dispositivos; los contenedores Linux, los runners de CI y las distribuciones de WSL normalmente no.

• El servidor Git no envía su certificado intermedio

  frecuente

  GitLab, Gitea y los proxies inversos que tienen delante suelen configurarse solo con el certificado hoja. Los navegadores suplen la carencia; GnuTLS no.

• Un proxy que inspecciona TLS se interpone entre tú y el host de Git

  ocasional

  Los clones desde github.com o gitlab.com que solo fallan en la red de la empresa los vuelve a firmar un proxy cuya raíz no está en el bundle del equipo.

• La imagen no tiene bundle de CA

  ocasional

  Una imagen slim con git instalado pero sin ca-certificates falla con todos los remotos HTTPS.

Cómo solucionarlo

1. 1.

   Ver qué certificados envía el servidor Git

   Si solo aparece el certificado hoja, corrige el servidor. Si la cadena termina en una raíz de la empresa o del proxy, instala esa raíz en el cliente.

   openssl s_client -connect git.example.com:443 -servername git.example.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'

2. 2.

   Confiar en una CA para un solo servidor Git

   http.<url>.sslCAInfo limita la CA personalizada a un solo host, así que los remotos públicos siguen usando el bundle del sistema. GIT_SSL_CAINFO hace lo mismo para un solo comando o un trabajo de CI.

   # Trust the company CA for this server only; other remotes keep the system bundle
   git config --global http."https://git.example.com/".sslCAInfo /etc/ssl/private-ca/corp-root-ca.pem
   git ls-remote https://git.example.com/team/app.git

3. 3.

   Añadir la raíz al bundle del sistema

   Instalar la raíz con update-ca-certificates corrige git, curl, wget y los gestores de paquetes de una sola vez. En las imágenes de Docker, hazlo en el Dockerfile; en CI, en la imagen del runner.

   sudo cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt
   sudo update-ca-certificates     # git, curl and wget read /etc/ssl/certs/ca-certificates.crt

4. 4.

   Propietarios del servidor: configurar la cadena completa

   El archivo de certificado que usa el frontal web del servidor Git debe contener el certificado hoja seguido de todos los intermedios.

   # GitLab Omnibus (/etc/gitlab/gitlab.rb): the .crt file must contain leaf + intermediates
   nginx['ssl_certificate'] = "/etc/gitlab/ssl/git.example.com.crt"
   # then: sudo gitlab-ctl reconfigure

5. 5.

   Diagnóstico temporal: omitir la verificación en un solo comando

   -c http.sslVerify=false en un solo comando confirma que la confianza es el único problema. Configurarlo de forma global envía tus credenciales y tu código a cualquiera que pueda interceptar la conexión.

   # Diagnostic only, for one command: never set http.sslVerify=false globally
   git -c http.sslVerify=false ls-remote https://git.example.com/team/app.git

← Explorar toda la base de datos de errores de firma