falha na verificação do certificado do servidor. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

335

Posso enviar por projeto clone usando ssh, mas ele não funciona quando clono projeto com https.

A mensagem de erro que me mostra é:

server certificate verification failed. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none

certificate ssl-certificate gitlab

— Sokhom Ratanak
fonte

422

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"

Resposta longa

O motivo básico é que o computador não confia na autoridade de certificação que assinou o certificado usado no servidor Gitlab . Isso não significa que o certificado seja suspeito, mas pode ser autoassinado ou assinado por uma instituição / empresa que não esteja na lista da lista de CAs do seu sistema operacional. O que você precisa fazer para contornar o problema no seu computador é dizer para confiar nesse certificado - se você não tiver nenhum motivo para suspeitar disso.

Você precisa verificar o certificado da web usado para o seu servidor gitLab e adicioná-lo ao seu </git_installation_folder>/bin/curl-ca-bundle.crt.

Para verificar se pelo menos o clone funciona sem verificar o certificado, você pode definir:

export GIT_SSL_NO_VERIFY=1
#or
git config --global http.sslverify false

Mas isso seria apenas para teste, conforme ilustrado em "O SSL funciona com o navegador, wget e curl, mas falha com o git ", ou nesta postagem do blog .

Verifique as configurações do GitLab, na edição 4272 .

Para obter esse certificado (que você precisaria adicionar ao seu curl-ca-bundle.crtarquivo), digite a:

echo -n | openssl s_client -showcerts -connect yourserver.com:YourHttpsGitlabPort \
  2>/dev/null  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

(com ' yourserver.com' sendo o nome do servidor GitLab e YourHttpsGitlabPorté a porta https, geralmente 443)

Para verificar a CA (emissor da autoridade de certificação), digite 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 sugere nos comentários a -servernameopção de adicionar ao comando openssl, caso contrário, o comando não recebe certificado para www.github.com no caso de Valeriy.

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Findekano acrescenta nos comentários :

para identificar a localização de curl-ca-bundle.crt, você pode usar o comando

curl-config --ca

Além disso, consulte minha resposta mais recente " github: falha na verificação do certificado do servidor ": talvez seja necessário renistar novamente esses 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

— VonC
fonte

8

A mensagem original não indica onde adicionar o certificado? No meu caso curl-config --caretornado /etc/ssl/certs/ca-certificates.crt, que é onde eu tive que adicionar o certificado. Para além de que esta resposta era a primeira informação me apontar na direção certa com esta questão

— uli_1973

1

Como você encontra a pasta de instalação do git?

— precisa saber é o seguinte

1

@Bhargav depende do seu sistema operacional. No Linux, você pode fazer um which git.

— VonC 29/01

3

Eu corri curl-config --ca, mas nada foi devolvido.

— Fernando Costa

1

Obrigado pela dica - você salvou o meu dia.

— Janne

220

Nota: Isso tem grandes implicações de segurança.

Abra seu terminal e execute o seguinte comando:

export GIT_SSL_NO_VERIFY=1

Funciona para mim e estou usando o sistema Linux.

— Afzal Masood
fonte

60

Não diminuindo o voto porque é uma solução alternativa para quando você sabe o que está fazendo. No entanto, recomendo fortemente contra isso no caso geral.

— tripleee

9

Eu não diria que é uma solução alternativa quando você sabe o que está fazendo. Quando você sabe o que está fazendo, deve ver um certificado falhando como "talvez alguém tenha nos hackeado" e não "oh, bem, a segurança diz que alguém nos hackeado, acho que precisamos desativar a segurança". É, na melhor das hipóteses, uma medida paliativa se algo precisar ser pressionado o mais rápido possível.

— Srcspider 28/05

1

exportando acima do sinalizador, fico abaixo do error.error: RPC falhou; resultado = 22, código HTTP = 403 fatal: O fim remoto desligou inesperadamente: RPC falhou; result = 22, HTTP code = 403 fatal: O lado remoto desligou inesperadamente

— Desu

8

Só trabalhou para mim comgit config --global http.sslverify false

— Dinei

2

Ótimo. Você economizou meu tempo.

— Sai prateek

146

Outra causa desse problema pode ser que seu relógio esteja desligado. Os certificados são sensíveis ao tempo.

Para verificar a hora atual do sistema:

date -R

Você pode considerar a instalação do NTP para sincronizar automaticamente a hora do sistema com servidores de horário da Internet confiáveis do pool NTP global . Por exemplo, para instalar no Debian / Ubuntu:

apt-get install ntp

— davidthings
fonte

5

Este foi o meu problema. Minha universidade estava bloqueando pacotes NTP, o que impedia que meu sistema atualizasse o tempo. Depois de configurar os servidores da universidade, as coisas estavam funcionando novamente. Obrigado por esta dica!

— Kyle

3

Essa também foi a causa do meu problema, eu estava usando um dispositivo incorporado que tinha a data errada!

— Shervin Emami 02/02

Este foi o meu problema, com certs. Passei horas analisando todos os tipos de soluções antes de descobrir que o problema era o relógio do servidor ser definido no futuro. No entanto, não me ajudou a obter uma versão futura do Node.js. :-(

— Kevin Teljeur 23/03

1

@ Katu, não é gitpor assim dizer, é a troca SSL subjacente. O Git é construído com suporte a SSL.

— Yvan

1

Eu voto isso mais de 10000 vezes .... tenho procurado por que não funcionou por 6 horas inteiras agora ... O servidor ficou fora por menos de 7 minutos e isso funcionou ... OBRIGADO!

— dGo 15/10

66

Se você estiver usando um servidor git dentro de uma rede privada e estiver usando um certificado autoassinado ou um certificado em um endereço IP; você também pode simplesmente usar a configuração global do git para desativar as verificações de ssl:

git config --global http.sslverify "false"

— Romain VDK
fonte

43

Teve o mesmo problema. Causada pela autoridade de certificação auto-emitida. Resolvi adicionando o arquivo .pem em / usr / local / share / ca-certificates / e chamando

sudo update-ca-certificates

PS: arquivo pem na pasta ./share/ca-certificates DEVE ter extensão .crt

— Nikolay Ruban
fonte

2

Trabalhou como um encanto no Linux Mint 16 :)

— greuze

você quer dizer cert.pem ou cert.crt ou cert.pem.crt?

— Moses Liao GZ

1

cert.pem deve ser renomeado para cert.pem.crt

— Nikolay Ruban

34

Verifique o relógio do sistema,

$ date

Se não estiver correto, a verificação do certificado falhará. Para corrigir o relógio do sistema,

$ apt-get install ntp

O relógio deve sincronizar-se.

Por fim, insira o comando clone novamente.

— Mycowan
fonte

1

Sim! Eu tive uma instância do Ubuntu suspensa no VirtualBox por um longo tempo. O relógio do sistema não foi sincronizado por qualquer motivo quando cancelei a suspensão. A resposta do VonC parece bem informada, mas estou muito feliz por não ter que executar vários comandos de segurança que não entendo. Verifique isso primeiro!

— AndyJost 24/02/19

24

GIT_CURL_VERBOSE=1 git [clone|fetch]…

deve lhe dizer onde está o problema. No meu caso, era devido ao cURL não suportar certificados PEM quando criados contra o NSS, devido a esse suporte não ser principal no NSS ( # 726116 # 804215 # 402712 e mais ).

— Tobu
fonte

4

Adição agradável com o GIT_CURL_VERBOSE. Eu não mencionei isso na minha resposta. 1

— VonC 15/04

18

Ou simplesmente execute este comentário para adicionar o certificado do servidor ao seu banco de dados:

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

Então git clone novamente.

— phiphu
fonte

1

Não sei se isso funciona para ninguém, mas preciso de "tee" para anexar o arquivo cert como root: echo -n | openssl s_client -showcerts -connect yourselferver.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt

— ywu

No meu caso, o servidor possui um certificado válido, mas meu banco de dados não o inclui, com este comando resolvi, mas devo dizer que esse comando deve ser executado com privilégios de root.

— hermeslm

10

Eu errei com meus arquivos CA enquanto configurava o proxy goagent. Não é possível extrair dados do github e recebe o mesmo aviso:

falha na verificação do certificado do servidor. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

use o método Vonc, obtenha o certificado no github e coloque-o no /etc/ssl/certs/ca-certificates.crt, problema resolvido.

eco -n | openssl s_client -showcerts -connect github.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p'

— IFQ
fonte

8

não é necessário definir a verificação git ssl para definir como false. É causado quando o sistema não possui todos os certificados de autoridade de autoridade de certificação. Principalmente as pessoas que possuem certificado SSL genuíno sem o certificado intermediário.

Apenas adicionando o texto completo do certificado intermediário (toda a cadeia de CA e certificado intermediário ausentes) a

sudo gedit /etc/ssl/certs/ca-certificates.crt

funciona sem executar o update-ca-certificates.

O mesmo vale para certificados gerados manualmente, basta adicionar o texto do certificado da CA.

No final: Empurre com sucesso: tudo está atualizado

— abcdef12
fonte

1

O mesmo pode ser causado se o servidor não estiver configurado corretamente com toda a cadeia de CA SSL.

— precisa saber é o seguinte

Problemas em cadeia podem ser a causa, como comentou o abcdef12. Eu tive esse problema com o git 1.9.1 - o servidor estava enviando a cadeia de certificação: # 0 server cert; # 1 server cert (novamente); # 2 signat cert. A duplicata na cadeia foi a razão pela qual o git não gostou.

— jah

8

O que fiz para resolver este problema no terminal (Ubuntu 18.04):

openssl s_client -showcerts -servername www.github.com -connect www.github.com:443

Eu tenho dois pedaços de pedaços de certificado. E eu copiei os pedaços de certificado para o meu arquivo de certificado para /etc/ssl/certs/ca-certificates.crt.

— mindcoder
fonte

Esta solução resolve meu problema idêntico no Ubuntu 16.04.

— user3072843

O que exatamente você quer dizer com pedaços de certificado ? O bloco entre ---BEGIN CERTIFICATE---e --- END CERTIFICATE ---?

— B - rian 27/02

3

Eu instalei o Xubuntu em um Raspberry pi 2, encontrei o mesmo problema com o tempo, pois a sincronização NTP e automática do servidor estava desativada (ou não instalada). Obter NTP

sudo apt-get install ntp

e altere "Hora e data" de "Manual" para "Manter sincronizado com os servidores da Internet"

— user273711
fonte

1

Eventualmente, adicione o http.sslverify ao seu .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

— Mickael L
fonte

1

Melhor usar a linha de comando git config http.sslVerify false. Você está sugerindo editar a configuração do Git por repositório, não globalmente como sugerido por @ romain-vdk?

— ahogen 03/01

1

A primeira coisa que você deve procurar é a permissão de arquivo de /etc/ssle /etc/ssl/certs.

Cometi o erro de remover permissões de arquivo (ou remover os rm -rf /etc/ssl/*diretórios SSL ) ao usar o ssl-certnome / ID do grupo enquanto trabalhava na minha Ferramenta de Gerenciamento de Autoridade de Certificação .

Foi então que percebi exatamente a mesma mensagem de erro para wgete curlferramentas do navegador CLI:

server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Depois que eu trouxe a permissão de arquivo dos diretórios /etc/ssle , essas ferramentas do navegador CLI começaram a ficar um pouco mais fáceis:/etc/ssl/certo+rx-w

mkdir -p /etc/ssl/certs
chmod u+rwx,go+rx /etc/ssl /etc/ssl/certs

Também tive que recriar o subdiretório Java e reconstruir os diretórios de certificado da CA Confiável:

mkdir /etc/ssl/certs/java
chmod u+rwx,go+rx /etc/ssl/certs/java
update-ca-certificates

e a costa estava limpa.

— John Greene
fonte

0

Acabei de encontrar o mesmo problema com um repositório git que sempre funciona para mim. O problema era que eu o acessei por meio de acesso Wi-Fi público, que redireciona para um portal cativo na primeira conexão (por exemplo, para exibir anúncios e concordar com o TOS).

— Tosha
fonte

0

Copie o certificado e o pacote configurável em um arquivo .crt e verifique se há uma linha em branco entre os certificados no arquivo.

Isso funcionou para mim em um servidor GitLab depois de tentar tudo na Internet.

— shambhu
fonte