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

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

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

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.

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

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"

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

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

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

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.

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'

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

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.

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

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

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.

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

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.