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

A URL é o seu remoto. Builds baseados no OpenSSL 1.1.1 imprimem “self signed”, sem hífen; a libcurl 8.22 imprime “SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19)”.

O que significa

O servidor Git (ou algo na frente dele) enviou uma cadeia completa que termina em uma raiz autoassinada, e essa raiz não está no bundle de CAs que a libcurl do git usa. Quando isso acontece com hosts públicos como github.com, a raiz quase sempre pertence a um proxy com inspeção de TLS na sua rede; em servidores auto-hospedados, à CA da empresa.

Por que acontece

• Um proxy corporativo com inspeção de TLS

  comum

  Zscaler, Netskope, Palo Alto, Fortinet e produtos semelhantes descriptografam o tráfego e o criptografam de novo com a própria raiz. O Windows confia nessa raiz por meio de política de grupo; o WSL, o Docker, as imagens de CI e o arquivo de CAs que acompanha o Git for Windows, não.

• O servidor Git auto-hospedado envia a própria raiz privada

  comum

  Um GitLab ou Gitea interno que serve o certificado folha, o intermediário e a raiz da empresa ainda precisa que a raiz esteja instalada em cada cliente.

• Varredura de HTTPS do antivírus

  ocasional

  Produtos de segurança de endpoint com recursos de “HTTPS scanning” ou “web shield” inserem a própria raiz na máquina; ela aparece nesta cadeia do mesmo jeito que a raiz de um proxy.

Como corrigir

1. 1.

   Identificar a raiz

   Imprima a cadeia de um host público. Se o certificado do topo tiver o nome da sua empresa ou de um fornecedor de segurança, a conexão está sendo inspecionada, e é nessa raiz que o git precisa confiar. Se você não o reconhecer de jeito nenhum, não confie nele: investigue primeiro.

   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 o repositório de certificados do Windows

   O Git for Windows com http.sslBackend schannel confia em tudo aquilo em que o Windows confia, o que, em máquinas gerenciadas, já inclui a raiz do proxy.

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

3. 3.

   Adicionar a raiz ao bundle que o git usa

   O http.sslCAInfo substitui o bundle padrão, então monte um arquivo que contenha as raízes públicas e também a raiz do proxy ou da 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 a raiz em todo o sistema no Linux

   O update-ca-certificates adiciona a raiz de uma só vez para o git, o curl, o wget, o pip e a maioria das outras ferramentas.

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

5. 5.

   Diagnóstico temporário: pular a verificação em um único comando

   Só para confirmar o diagnóstico. Desativar a verificação no trabalho real entrega suas credenciais do Git e seu código-fonte a quem fizer a terminação da conexão.

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

← Ver toda a base de erros de assinatura