Überprüfung des Serverzertifikats fehlgeschlagen. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: keine

333

Ich kann ein Projekt mit ssh per Klon pushen, aber es funktioniert nicht, wenn ich ein Projekt mit https klone.

Die Fehlermeldung, die mich anzeigt, lautet:

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

Antworten:

421

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"

Lange Antwort

Der Hauptgrund ist, dass Ihr Computer der Zertifizierungsstelle , die das auf dem Gitlab-Server verwendete Zertifikat signiert hat, nicht vertraut . Dies bedeutet nicht, dass das Zertifikat verdächtig ist, es kann jedoch selbstsigniert oder von einer Institution / Firma signiert sein, die nicht in der Liste der Zertifizierungsstellen Ihres Betriebssystems enthalten ist. Um das Problem auf Ihrem Computer zu umgehen , müssen Sie ihm sagen, dass er diesem Zertifikat vertrauen soll - wenn Sie keinen Grund haben, misstrauisch zu sein.

Sie müssen das für Ihren gitLab-Server verwendete Webzertifikat überprüfen und zu Ihrem hinzufügen </git_installation_folder>/bin/curl-ca-bundle.crt.

Um zu überprüfen, ob mindestens der Klon funktioniert, ohne das Zertifikat zu überprüfen, können Sie Folgendes festlegen:

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

Dies dient jedoch nur zum Testen, wie in " SSL funktioniert mit Browser, Wget und Curl, schlägt jedoch mit Git fehl " oder in diesem Blogbeitrag dargestellt .

Überprüfen Sie Ihre GitLab-Einstellungen, a in Ausgabe 4272 .


Geben Sie Folgendes ein, um das Zertifikat zu erhalten (das Sie Ihrer curl-ca-bundle.crtDatei hinzufügen müssten ):

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

(wobei ' yourserver.com' Ihr GitLab-Servername ist und YourHttpsGitlabPortnormalerweise der https-Port ist 443)

Geben Sie Folgendes ein, um die Zertifizierungsstelle (Certificate Authority Issuer) zu überprüfen:

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

Hinweis: Valeriy Katkov schlägt in den Kommentaren vor-servername , dem Befehl openssl eine Option hinzuzufügen , andernfalls wird dem Befehl in Valeriy's Fall kein Zertifikat für www.github.com angezeigt.

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

Findekano fügt in den Kommentaren hinzu :

Um den Standort von zu identifizieren curl-ca-bundle.crt, können Sie den Befehl verwenden

curl-config --ca

Siehe auch meine neuere Antwort " github: Überprüfung des Serverzertifikats fehlgeschlagen ": Möglicherweise müssen Sie diese Zertifikate neu kristallisieren:

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
quelle
8
Gibt die ursprüngliche Nachricht nicht an, wo das Zertifikat hinzugefügt werden soll? In meinem Fall curl-config --cazurückgegeben /etc/ssl/certs/ca-certificates.crt, wo ich das Zertifikat hinzufügen musste. Abgesehen davon war diese Antwort die erste Information, die mich mit diesem Problem in die richtige Richtung wies
uli_1973
1
Wie finden Sie den Git-Installationsordner?
Bhargav
1
@ Bhargav es hängt von Ihrem Betriebssystem ab. Unter Linux können Sie eine which git.
VonC
3
Ich rannte curl-config --ca, aber nichts wurde zurückgegeben.
Fernando Costa
1
Danke für den Tipp - du hast meinen Tag gerettet.
Janne
218

Hinweis: Dies hat erhebliche Auswirkungen auf die Sicherheit.

Öffnen Sie Ihr Terminal und führen Sie den folgenden Befehl aus:

export GIT_SSL_NO_VERIFY=1

Es funktioniert für mich und ich benutze Linux-System.

Afzal Masood
quelle
60
Kein Downvoting, da dies eine Problemumgehung ist, wenn Sie wissen, was Sie tun. Im allgemeinen Fall jedoch dringend davon abzuraten.
Tripleee
9
Ich würde nicht sagen, dass es eine Problemumgehung ist, wenn Sie wissen, was Sie tun. Wenn Sie wissen, was Sie tun, sollten Sie sich ein fehlgeschlagenes Zertifikat als "Vielleicht hat uns jemand gehackt" ansehen, nicht als "Na ja, Sicherheit sagt, jemand hat uns gehackt, wir müssen die Sicherheit deaktivieren." Es ist bestenfalls eine Notlösung, wenn etwas so schnell wie möglich geschoben werden muss.
srcspider
1
Durch den Export über dem Flag erhalte ich den Fehler. Fehler: RPC fehlgeschlagen; Ergebnis = 22, HTTP-Code = 403 schwerwiegend: Das Remote-Ende hat unerwartet aufgelegt Fehler: RPC fehlgeschlagen; Ergebnis = 22, HTTP-Code = 403 fatal: Das Remote-Ende legte unerwartet auf
Desu
7
git config --global http.sslverify false
Arbeitete
2
Großartig. Du hast meine Zeit gespart.
Sai Prateek
146

Eine andere Ursache für dieses Problem könnte sein, dass Ihre Uhr möglicherweise ausgeschaltet ist. Zertifikate sind zeitkritisch.

So überprüfen Sie die aktuelle Systemzeit:

date -R

Sie können NTP installieren, um die Systemzeit automatisch mit vertrauenswürdigen Internet-Zeitservern aus dem globalen NTP-Pool zu synchronisieren . Zum Beispiel zur Installation unter Debian / Ubuntu:

apt-get install ntp
Davidthings
quelle
5
Das war mein Problem. Meine Universität blockierte NTP-Pakete, was mein System daran hinderte, die Zeit zu aktualisieren. Nachdem ich die NTP-Server der Universität konfiguriert hatte, funktionierten die Dinge wieder. Danke für diesen Tipp!
Kyle
3
Dies war auch die Ursache für mein Problem. Ich habe ein eingebettetes Gerät verwendet, das das falsche Datum hatte!
Shervin Emami
Das war mein Problem mit Zertifikaten. Ich habe stundenlang nach allen möglichen Lösungen gesucht, bevor ich herausgefunden habe, dass das Problem darin besteht, dass die Serveruhr in die Zukunft gestellt wird. Es hat mir jedoch nicht geholfen, eine zukünftige Version von Node.js zu bekommen. :-(
Kevin Teljeur
1
@Katu es ist nicht gitper say, es ist der zugrunde liegende SSL-Austausch. Git wurde mit SSL-Unterstützung erstellt.
Yvan
1
Ich habe dies 10000 Mal positiv bewertet ... habe gesucht, warum es jetzt 6 Stunden lang nicht funktioniert hat ... Der Server war weniger als 7 Minuten ausgeschaltet und das hat den Trick gemacht ... DANKE!
dGo
66

Wenn Sie einen Git-Server in einem privaten Netzwerk verwenden und ein selbstsigniertes Zertifikat oder ein Zertifikat über eine IP-Adresse verwenden; Sie können auch einfach die globale Konfiguration von git verwenden, um die SSL-Überprüfungen zu deaktivieren:

git config --global http.sslverify "false"
Romain VDK
quelle
43

Hatte das gleiche Problem. Verursacht durch selbst ausgestellte Zertifizierungsstelle. Behebung des Problems durch Hinzufügen einer PEM-Datei zu / usr / local / share / ca-certificates / und Aufrufen

sudo update-ca-certificates

PS: PEM-Datei im Ordner ./share/ca-certificates MUSS die Erweiterung .crt haben

Nikolay Ruban
quelle
2
Arbeitete wie ein Zauber in Linux Mint 16 :)
Greuze
meinst du cert.pem oder cert.crt oder cert.pem.crt?
Moses Liao GZ
1
cert.pem sollte in cert.pem.crt umbenannt werden
Nikolay Ruban
34

Überprüfen Sie Ihre Systemuhr,

$ date

Wenn es nicht korrekt ist, schlägt die Zertifikatprüfung fehl. Um die Systemuhr zu korrigieren,

$ apt-get install ntp

Die Uhr sollte sich selbst synchronisieren.

Geben Sie zum Schluss den Klonbefehl erneut ein.

Mycowan
quelle
1
Ja! Ich hatte eine Instanz von Ubuntu für eine lange Zeit in VirtualBox ausgesetzt. Die Systemuhr wurde aus irgendeinem Grund nicht synchronisiert, als ich nicht suspendiert war. VonCs Antwort scheint sachkundig zu sein, aber ich bin wirklich froh, dass ich nicht eine Reihe von Sicherheitsbefehlen ausführen musste, die ich nicht verstehe. Überprüfen Sie dies zuerst!
AndyJost
24
GIT_CURL_VERBOSE=1 git [clone|fetch]…

sollte Ihnen sagen, wo das Problem liegt. In meinem Fall lag es daran, dass cURL beim Erstellen gegen NSS keine PEM-Zertifikate unterstützte, da diese Unterstützung in NSS nicht die Hauptleitung war ( # 726116 # 804215 # 402712 und mehr ).

Tobu
quelle
4
Schöne Ergänzung mit dem GIT_CURL_VERBOSE. Ich habe es in meiner Antwort nicht erwähnt. +1
VonC
18

Oder führen Sie einfach diesen Kommentar aus, um das Serverzertifikat zu Ihrer Datenbank hinzuzufügen:

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

Dann klonen Sie noch einmal.

Phiphu
quelle
1
Ich weiß nicht, ob dies für irgendjemanden funktioniert, aber ich brauche "tee", um die Zertifikatsdatei als root anzuhängen: 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
In meinem Fall hat der Server ein gültiges Zertifikat, aber meine Datenbank enthält es nicht. Mit diesem Befehl habe ich mich aufgelöst, aber ich muss sagen, dass dieser Befehl mit Root-Rechten ausgeführt werden muss.
Hermeslm
10

Ich habe meine CA-Dateien durcheinander gebracht, während ich den goagent-Proxy eingerichtet habe. Es können keine Daten von Github abgerufen werden, und es wird dieselbe Warnung angezeigt:

Überprüfung des Serverzertifikats fehlgeschlagen. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: keine

Verwenden Sie die Methode von Vonc, holen Sie sich das Zertifikat von github und legen Sie es in /etc/ssl/certs/ca-certificates.crt ab. Das Problem wurde behoben.

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

IFQ
quelle
8

Es ist nicht erforderlich, die git ssl-Überprüfung auf false zu setzen. Dies wird verursacht, wenn das System nicht über alle CA-Berechtigungszertifikate verfügt. Meistens fehlt Personen mit einem echten SSL-Zertifikat das Zwischenzertifikat.

Fügen Sie einfach den vollständigen Text des Zwischenzertifikats (gesamte Kette der fehlenden Zertifizierungsstelle und des Zwischenzertifikats) hinzu

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

funktioniert ohne die update-ca-certificates .

Gleiches gilt für manuell generierte Zertifikate. Fügen Sie einfach den CA-Zertifikatstext hinzu.

Am Ende: Push erfolgreich: Alles ist aktuell

abcdef12
quelle
1
Gleiches kann verursacht werden, wenn der Server nicht ordnungsgemäß mit der gesamten SSL-CA-Kette konfiguriert ist.
abcdef12
Kettenprobleme können die Ursache sein, wie abcdef12 kommentierte. Ich hatte dieses Problem mit Git 1.9.1 - der Server hat die Zertifikatskette gesendet: # 0 Server Cert; # 1 Serverzertifikat (wieder); # 2 Unterzeichner cert. Das Duplikat in der Kette war der Grund, warum es git nicht gefiel.
Jah
8

Was ich getan habe, um dieses Problem im Terminal zu lösen (Ubuntu 18.04):

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

Ich habe zwei Stücke Zertifikatsstücke bekommen. Und ich habe die Zertifikatsblöcke in meine Zertifikatdatei kopiert /etc/ssl/certs/ca-certificates.crt.

Mindcoder
quelle
Diese Lösung löst mein identisches Problem in Ubuntu 16.04.
user3072843
Was genau meinst du mit Zertifikatsblöcken ? Der Block zwischen ---BEGIN CERTIFICATE---und --- END CERTIFICATE ---?
B - rian
3

Ich habe Xubuntu auf einem Raspberry pi 2 installiert und mit der Zeit das gleiche Problem festgestellt, da die NTP- und Automatic Server-Synchronisierung deaktiviert (oder nicht installiert) war. Holen Sie sich NTP

sudo apt-get install ntp

und ändern Sie "Uhrzeit und Datum" von "Manuell" in "Mit Internet-Servern synchron bleiben".

user273711
quelle
1

Fügen Sie schließlich die Datei http.sslverify zu Ihrer .git / config hinzu.

[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.
quelle
1
Verwenden Sie besser die Befehlszeile git config http.sslVerify false. Schlagen Sie vor, die Git-Konfiguration pro Repository zu bearbeiten, nicht global, wie von @ romain-vdk vorgeschlagen?
Ahogen
1

Das erste, worauf Sie achten sollten, ist die Dateiberechtigung von /etc/sslund /etc/ssl/certs.

Ich habe den Fehler gemacht, Dateiberechtigungen zu löschen (oder die SSL- rm -rf /etc/ssl/*Verzeichnisse wegzublasen ), wenn ssl-certich bei der Arbeit an meinem Certificate Authority Management Tool den Gruppennamen / die ID verwendet habe .

Zu diesem Zeitpunkt bemerkte ich genau die gleiche Fehlermeldung für wgetund curlCLI-Browser-Tools:

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

Nachdem ich die Dateiberechtigung von /etc/sslund für /etc/ssl/certVerzeichnisse auf o+rx-wden neuesten Stand gebracht hatte, atmeten diese CLI-Browser-Tools etwas leichter:

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

Ich musste auch das Java-Unterverzeichnis neu erstellen und die Trusted CA-Zertifikatverzeichnisse rekonstruieren:

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

und die Küste war klar.

John Greene
quelle
0

Ich habe gerade das gleiche Problem mit einem Git-Repository festgestellt, das immer für mich funktioniert. Das Problem war, dass ich über einen öffentlichen WiFi-Zugang darauf zugegriffen habe, der bei der ersten Verbindung zu einem Captive-Portal umleitet (zum Beispiel um Anzeigen zu schalten und mit tos übereinzustimmen).

Tosha
quelle
0

Lassen Sie das Zertifikat und das Bundle in eine CRT-Datei kopieren und stellen Sie sicher, dass zwischen den Zertifikaten in der Datei eine Leerzeile vorhanden ist.

Dies funktionierte für mich auf einem GitLab-Server, nachdem ich alles im Internet ausprobiert hatte.

Shambhu
quelle