fatal: unable to access 'https://git.example.com/team/app.git/': SSL certificate problem: self-signed certificate in certificate chain

La URL es la de tu remoto. Las compilaciones basadas en OpenSSL 1.1.1 imprimen «self signed» sin guion; libcurl 8.22 imprime «SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19)».

Qué significa

El servidor Git (o algo que tiene delante) envió una cadena completa que termina en una raíz autofirmada, y esa raíz no está en el bundle de CA que usa el libcurl de git. Cuando ocurre con hosts públicos como github.com, la raíz casi siempre pertenece a un proxy que inspecciona TLS en tu red; con servidores autoalojados, a la CA de la empresa.

Por qué ocurre

• Un proxy corporativo de inspección TLS

  frecuente

  Zscaler, Netskope, Palo Alto, Fortinet y productos similares descifran el tráfico y lo vuelven a cifrar con su propia raíz. Windows confía en ella a través de la política de grupo; el archivo de CA que incluye Git for Windows, WSL, Docker y las imágenes de CI no.

• El servidor Git autoalojado envía su raíz privada

  frecuente

  Un GitLab o Gitea interno que sirve el certificado hoja, el intermedio y la raíz de la empresa sigue necesitando que la raíz esté instalada en cada cliente.

• Análisis HTTPS del antivirus

  ocasional

  Los productos de seguridad de endpoints con funciones de «análisis HTTPS» o «escudo web» insertan su propia raíz en el equipo; aparece en esta cadena igual que la de un proxy.

Cómo solucionarlo

1. 1.

   Identificar la raíz

   Imprime la cadena de un host público. Si el certificado superior lleva el nombre de tu empresa o de un proveedor de seguridad, la conexión se está inspeccionando y esa es la raíz en la que git necesita confiar. Si no la reconoces en absoluto, no confíes en ella: investiga primero.

   openssl s_client -connect github.com:443 -servername github.com -showcerts </dev/null 2>/dev/null \
     | grep -E '^ *[0-9]+ s:|^ *i:'
   # A root named after your company or a security vendor = interception proxy

2. 2.

   Windows: usar el almacén de certificados de Windows

   Git for Windows con http.sslBackend schannel confía en todo aquello en lo que confía Windows, lo que en los equipos administrados ya incluye la raíz del proxy.

   # Git for Windows: use the Windows certificate store, which already trusts the proxy root
   git config --global http.sslBackend schannel

3. 3.

   Añadir la raíz al bundle que usa git

   http.sslCAInfo sustituye el bundle predeterminado, así que crea un archivo que contenga las raíces públicas más la raíz del proxy o de la empresa.

   # Linux/macOS/WSL: append the proxy root to a bundle that keeps the public roots
   cat /etc/ssl/certs/ca-certificates.crt corp-proxy-root.pem > ~/.config/git/ca-bundle.pem
   git config --global http.sslCAInfo ~/.config/git/ca-bundle.pem

4. 4.

   Instalar la raíz en todo el sistema en Linux

   update-ca-certificates añade el certificado raíz para git, curl, wget, pip y la mayoría de las demás herramientas a la vez.

   sudo cp corp-proxy-root.pem /usr/local/share/ca-certificates/corp-proxy-root.crt
   sudo update-ca-certificates

5. 5.

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

   Solo para confirmar el diagnóstico. Desactivar la verificación en el trabajo real entrega tus credenciales de Git y tu código fuente a quien termine la conexión.

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

← Explorar toda la base de datos de errores de firma