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

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

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

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.

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

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"

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

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.

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 ).

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.

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'

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

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.

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"

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

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.

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).

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.