verifica del certificato del server non riuscita. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: nessuno


335

Posso spingere per clonare progetto usando ssh, ma non funziona quando clono progetto con https.

Il messaggio di errore che mi mostra è:

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

Risposte:


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"

Risposta lunga

Il motivo di base è che il tuo computer non si fida dell'autorità di certificazione che ha firmato il certificato utilizzato sul server Gitlab . Ciò non significa che il certificato sia sospetto, ma potrebbe essere autofirmato o firmato da un'istituzione / azienda che non è nell'elenco dell'elenco di CA del sistema operativo. Quello che devi fare per aggirare il problema sul tuo computer è dirgli di fidarsi di quel certificato - se non hai motivo di essere sospettoso al riguardo.

Devi controllare il certificato web usato per il tuo server gitLab e aggiungerlo al tuo </git_installation_folder>/bin/curl-ca-bundle.crt.

Per verificare se almeno il clone funziona senza controllare detto certificato, è possibile impostare:

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

Ma questo sarebbe solo per il test, come illustrato in " SSL funziona con browser, wget e curl, ma fallisce con git ", o in questo post del blog .

Controlla le impostazioni di GitLab, nel numero 4272 .


Per ottenere quel certificato (che dovresti aggiungere al tuo curl-ca-bundle.crtfile), digita a:

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

(con ' yourserver.com' il nome del tuo server GitLab, ed YourHttpsGitlabPortè la porta https, di solito 443)

Per verificare la CA (emittente dell'autorità di certificazione), digitare 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 suggerisce nei commenti di aggiungere -servernameun'opzione al comando openssl, altrimenti il ​​comando non viene mostrato per www.github.com nel caso di Valeriy.

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

Findekano aggiunge nei commenti :

per identificare la posizione di curl-ca-bundle.crt, è possibile utilizzare il comando

curl-config --ca

Inoltre, vedi la mia risposta più recente " github: verifica del certificato del server non riuscita ": potrebbe essere necessario rinominare quei certificati:

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

8
Il messaggio originale non indica dove aggiungere il certificato? Nel mio caso è curl-config --catornato /etc/ssl/certs/ca-certificates.crt, che è dove ho dovuto aggiungere il certificato. A parte questo, questa risposta è stata la prima informazione che mi ha indicato nella giusta direzione con questo problema
uli_1973

1
Come trovi la cartella di installazione di git?
Bhargav,

1
@Bhargav dipende dal tuo sistema operativo. Su Linux, puoi fare un which git.
VonC,

3
Corsi curl-config --ca, ma non fu restituito nulla.
Fernando Costa,

1
Grazie per il suggerimento: mi hai salvato la giornata.
Janne,

220

Nota: questo ha importanti implicazioni per la sicurezza.

Apri il tuo terminale ed esegui il seguente comando:

export GIT_SSL_NO_VERIFY=1

Funziona per me e sto usando il sistema Linux.


60
Non effettuare il downvoting perché è una soluzione alternativa per quando sai cosa stai facendo. Tuttavia, lo consiglio vivamente contro questo nel caso generale.
Tripleee

9
Non direi che è una soluzione alternativa quando sai cosa stai facendo. Quando sai cosa stai facendo, dovresti vedere un certificato che fallisce come "forse qualcuno ci ha hackerato" e non "oh beh, la sicurezza dice che qualcuno ci ha hackerato, immagino che dobbiamo disabilitare la sicurezza". Nella migliore delle ipotesi è una misura di stopgap se qualcosa deve essere spinto al più presto.
srcspider,

1
esportando sopra la bandiera ottengo sotto error.error: RPC fallito; risultato = 22, codice HTTP = 403 fatale: l'estremità remota si è bloccata in modo imprevisto errore: errore RPC; risultato = 22, codice HTTP = 403 fatale: l'estremità remota si è bloccata in modo imprevisto
Desu,

8
Ha lavorato solo per me congit config --global http.sslverify false
Dinei,

2
Grande. Mi hai risparmiato tempo.
Sai prateek,

146

Un'altra causa di questo problema potrebbe essere che l'orologio potrebbe essere spento. I certificati sono sensibili al tempo.

Per controllare l'ora corrente del sistema:

date -R

È possibile prendere in considerazione l'installazione di NTP per sincronizzare automaticamente l'ora del sistema con time server Internet affidabili dal pool NTP globale . Ad esempio, per installare su Debian / Ubuntu:

apt-get install ntp

5
Questo era il mio problema La mia università stava bloccando i pacchetti ntp, impedendo al mio sistema di aggiornare i tempi. Dopo aver configurato i server ntp dell'università, le cose funzionavano di nuovo. Grazie per questo suggerimento!
Kyle

3
Questa è stata anche la causa del mio problema, stavo usando un dispositivo incorporato che aveva una data sbagliata!
Shervin Emami,

Questo era il mio problema, con i certificati. Ho passato ore a cercare soluzioni di ogni genere prima di scoprire che il problema era l'orologio del server che veniva impostato in futuro. Tuttavia, non mi ha aiutato a ottenere una versione futura di Node.js. :-(
Kevin Teljeur,

1
@Katu non è gitper dire, è lo scambio SSL sottostante. Git è realizzato con il supporto SSL.
Yvan,

1
Voterei questo 10000 volte .... Ho cercato perché non funzionasse per 6 ore intere ... Il server era spento da meno di 7 minuti e questo ha funzionato ... GRAZIE!
dGo

66

Se si utilizza un server git all'interno di una rete privata e si utilizza un certificato autofirmato o un certificato su un indirizzo IP; puoi anche semplicemente usare git global config per disabilitare i controlli ssl:

git config --global http.sslverify "false"

43

Ha avuto lo stesso problema. Causato dall'autorità di certificazione emessa autonomamente. Risolto aggiungendo il file .pem a / usr / local / share / ca-certificati / e chiamando

sudo update-ca-certificates

PS: il file pem nella cartella ./share/ca-certificates DEVE avere l'estensione .crt


2
Ha funzionato come un incantesimo in Linux mint 16 :)
greuze il

intendi cert.pem o cert.crt o cert.pem.crt?
Moses Liao GZ,

1
cert.pem dovrebbe essere rinominato in cert.pem.crt
Nikolay Ruban,

34

Controlla l'orologio di sistema,

$ date

Se non è corretto, il controllo del certificato fallirà. Per correggere l'orologio di sistema,

$ apt-get install ntp

L'orologio dovrebbe sincronizzarsi.

Immettere infine nuovamente il comando clone.


1
Sì! Ho avuto un'istanza di Ubuntu sospesa in VirtualBox per molto tempo. L'orologio di sistema non si sincronizzava per nessun motivo quando non avevo sospeso. La risposta di VonC sembra ben informata, ma sono davvero felice di non dover eseguire un sacco di comandi di sicurezza che non capisco. Controlla prima questo!
AndyJost,

24
GIT_CURL_VERBOSE=1 git [clone|fetch]…

dovrebbe dirti dov'è il problema. Nel mio caso era dovuto al fatto che cURL non supportava i certificati PEM quando costruito contro NSS, a causa del fatto che tale supporto non era principale in NSS ( # 726116 # 804215 # 402712 e altro ).


4
Bella aggiunta con il GIT_CURL_VERBOSE. Non l'ho menzionato nella mia risposta. +1
VonC

18

O semplicemente esegui questo commento per aggiungere il certificato del server al tuo database:

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

Quindi esegui di nuovo clonazione git.


1
Non so se questo funziona per chiunque, ma ho bisogno di "tee" per aggiungere il file cert come root: echo -n | openssl s_client -showcerts -connect yourserver.com:443 2> / dev / null | sed -ne '/ -BEGIN CERTIFICATE - /, / - END CERTIFICATE- / p' | sudo tee -a /etc/ssl/certs/ca-certificates.crt
ywu

Nel mio caso, il server ha un certificato valido, ma il mio database non lo include, con questo comando ho risolto ma devo dire che questo comando deve essere eseguito con i privilegi di root.
hermeslm,

10

Ho incasinato i miei file CA mentre configuravo goagent proxy. Impossibile estrarre i dati da Github e ottenere lo stesso avviso:

verifica del certificato del server non riuscita. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: nessuno

usare il metodo di Vonc, ottenere il certificato da github e inserirlo in /etc/ssl/certs/ca-certificates.crt, problema risolto.

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


8

non è necessario impostare la verifica git ssl su false. È causato quando il sistema non dispone di tutti i certificati dell'autorità CA. Soprattutto le persone che hanno un certificato SSL autentico mancano del certificato intermedio.

Basta aggiungere il testo completo del certificato intermedio (intera catena di CA mancante e certificato intermedio) a

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

funziona senza eseguire il update-ca-certificates.

Lo stesso vale per i certificati generati manualmente, basta aggiungere il testo del certificato CA.

Alla fine: Push riuscito: tutto è aggiornato


1
Lo stesso può essere causato se il server non è configurato correttamente con tutta la catena CA SSL.
abcdef12,

I problemi a catena possono essere la causa, come ha commentato abcdef12. Ho avuto questo problema con git 1.9.1 - il server stava inviando la catena di certificati: # 0 server di certificati; # 1 server cert (di nuovo); # 2 firmatario certificato. Il duplicato nella catena era il motivo per cui a Git non piaceva.
jah

8

Cosa ho fatto per risolvere questo problema nel terminale (Ubuntu 18.04):

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

Ho preso due pezzi di pezzi certificati. E ho copiato i blocchi di certificato nel mio file di certificato in /etc/ssl/certs/ca-certificates.crt.


Questa soluzione risolve il mio identico problema in Ubuntu 16.04.
user3072843

Cosa intendi esattamente con i pezzi di certificazione ? Il blocco tra ---BEGIN CERTIFICATE---e --- END CERTIFICATE ---?
B - rian,

3

Ho installato Xubuntu su un Raspberry pi 2, ho riscontrato lo stesso problema con il tempo, poiché la sincronizzazione di NTP e Automatic Server era disattivata (o non installata). Ottieni NTP

sudo apt-get install ntp

e modifica "Ora e data" da "Manuale" a "Resta sincronizzato con i server Internet"


1

Alla fine, aggiungi http.sslverify al tuo .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

1
Meglio usare la riga di comando git config http.sslVerify false. Stai suggerendo di modificare la configurazione di Git su base per repository, non a livello globale come suggerito da @ romain-vdk?
Ahogen

1

La prima cosa da verificare è l'autorizzazione del file di /etc/ssle /etc/ssl/certs.

Ho commesso l'errore di eliminare le autorizzazioni dei file (o eliminare le rm -rf /etc/ssl/*directory SSL ) durante l'utilizzo del ssl-certnome / ID del gruppo mentre lavoravo sul mio strumento di gestione dell'autorità di certificazione .

Fu allora che notai lo stesso identico messaggio di errore per wgete gli curlstrumenti del browser della CLI:

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

Una volta portato a termine l' autorizzazione al file delle directory /etc/ssle , quegli strumenti del browser della CLI hanno iniziato a respirare un po 'più facilmente:/etc/ssl/certo+rx-w

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

Ho anche dovuto ricreare la sottodirectory Java e ricostruire le directory dei certificati CA affidabili:

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

e la costa era chiara.


0

Ho appena riscontrato lo stesso problema con un repository git che funziona sempre per me. Il problema era che ho effettuato l'accesso tramite l'accesso WiFi pubblico, che reindirizza a un portale captive alla prima connessione (ad esempio per mostrare annunci e concordare con quelli).


0

Fai copiare il certificato e il bundle in un file .crt e assicurati che ci sia una riga vuota tra i certificati nel file.

Questo ha funzionato per me su un server GitLab dopo aver provato tutto su Internet.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.