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)

A URL é o seu remoto. Versões mais antigas do Debian e do Ubuntu (libcurl 7.x) imprimem a forma mais curta “server certificate verification failed. CAfile: none CRLfile: none”, em que “CAfile: none” só significa que nenhum arquivo de CA explícito foi configurado e que o bundle do sistema foi usado.

O que significa

O transporte HTTPS do git (a libcurl compilada com GnuTLS no Debian e no Ubuntu) não conseguiu verificar o certificado do servidor Git: nenhum certificado da cadeia leva a uma CA do bundle que ele lê. “certificate signer not trusted” é a forma de o GnuTLS dizer que o emissor é desconhecido; nada sobre suas credenciais ou o repositório chegou a ser verificado.

Por que acontece

• GitLab, Gitea ou Bitbucket auto-hospedado com certificado da empresa

  comum

  Servidores Git auto-hospedados costumam receber certificados de uma CA interna. Os notebooks dos desenvolvedores têm essa raiz via gerenciamento de dispositivos; contêineres Linux, runners de CI e distribuições do WSL geralmente não.

• O servidor Git não envia o intermediário

  comum

  GitLab, Gitea e os proxies reversos na frente deles muitas vezes são configurados só com o certificado folha. Os navegadores compensam a falta; o GnuTLS, não.

• Um proxy com inspeção de TLS fica entre você e o host Git

  ocasional

  Clones de github.com ou gitlab.com que só falham na rede da empresa passam por um proxy que reassina o tráfego com uma raiz que não está no bundle da máquina.

• A imagem não tem bundle de CAs

  ocasional

  Uma imagem slim com git instalado, mas sem ca-certificates, falha em todo remoto HTTPS.

Como corrigir

1. 1.

   Ver quais certificados o servidor Git envia

   Se só aparecer o certificado folha, corrija o servidor. Se a cadeia terminar em uma raiz da empresa ou do proxy, instale essa raiz no 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 em uma CA para um único servidor Git

   A opção http.<url>.sslCAInfo restringe a CA personalizada a um único host, então os remotos públicos continuam usando o bundle do sistema. GIT_SSL_CAINFO faz o mesmo para um único comando ou job 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.

   Adicionar a raiz ao bundle do sistema

   Instalar a raiz com update-ca-certificates corrige git, curl, wget e gerenciadores de pacotes de uma vez. Em imagens Docker, faça isso no Dockerfile; no CI, na imagem do 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.

   Donos do servidor: configurar a cadeia completa

   O arquivo de certificado usado pelo front-end web do servidor Git precisa conter o certificado folha seguido de todos os intermediários.

   # 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 temporário: pular a verificação em um único comando

   -c http.sslVerify=false em um único comando confirma que a confiança é o único problema. Definir isso globalmente entrega suas credenciais e seu código a qualquer pessoa que consiga interceptar a conexão.

   # 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

← Ver toda a base de erros de assinatura