Ich kann mein Projekt mit SSH klonen, aber es funktioniert nicht, wenn ich das Projekt mit HTTPS klonen möchte.
Die Fehlermeldung, die es mir zeigt, lautet:
Server-Zertifikatsüberprüfung fehlgeschlagen. CAfile: /etc/ssl/certs/cacertificates.crt CRLfile: none
Lets's encrypt 30. September 2021 Ablauf der ROOT-CA
Eine weitere Quelle für diesen Fehler ist eine abgelaufene Root-CA, gestern ist es bei einer von ihnen passiert, wenn Sie Let's Encrypt verwenden: https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/
Sie können dies bestätigen, indem Sie ausführen
openssl s_client -showcerts -connect $hostname:$port -servername $hostname | grep "Zertifikat ist abgelaufen"In diesem Fall müssen Sie das Gitlab-Zertifikat bearbeiten, in /etc/gitlab/ssl/$hostname.crt
Ersetzen Sie den abgelaufenen DST Root CA X3 Block in der Datei durch den Inhalt von https://letsencrypt.org/certs/isrgrootx1.pem und laden Sie den Server neu.
Zuletzt aktualisiert: 30. Sep 2021 | Alle Dokumentationen anzeigen
Der Hauptfaktor dafür, ob eine Plattform Let's Encrypt-Zertifikate validieren kann, ist, ob diese Plattform das ISRG-„ISRG Root X1“-Zertifikat von ISRG vertraut. Bis September 2021 konnten einige Plattformen unsere Zertifikate validieren, auch wenn sie ISRG Root X1 nicht enthalten, da sie dem „DST Root CA X3“-Zertifikat von IdenTrust vertrauten. Ab Oktober 2021 werden nur die Plattformen Let's Encrypt-Zertifikate validieren, die ISRG Root X1 vertrauen (mit Ausnahme von Android).
Falls Ihr System ziemlich aktuell ist, aber aus irgendeinem Grund das automatische Update nicht funktioniert hat, sollten folgende Schritte ausreichen:
apt update
apt upgrade
sudo dpkg-reconfigure ca-certificatesund im Rekonfigurationsstadium deselect "DST Root CA X3" Zertifikat
Um das Problem auf alten Linux-Servern wie Ubuntu 16 oder Debian 8 jessie zu lösen, sind nur wenige Schritte erforderlich:
openssl auf Version >=1.0.2 aktualisieren
Auf Debian jessie die Backports-Quelle aktivieren, fügen Sie diese Zeile zur sources.list hinzu:
deb http://archive.debian.org/debian jessie-backports main contrib non-free
und führen Sie aus apt-get install -t jessie-backports openssl
Security-Updates für das ca-certificates-Paket sicherstellen
apt upgrade
die neuesten LetsEncrypt-Root-CA-Zertifikate herunterladen:
sudo curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt -o /usr/local/share/ca-certificates/isrgrootx1.crt
sudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx1.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx1.crt
sudo curl -k https://letsencrypt.org/certs/letsencryptauthorityx2.pem.txt -o /usr/local/share/ca-certificates/letsencryptauthorityx2.crt
sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx1.crt
sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx2.crt
sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx3.crt
sudo curl -k https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem.txt -o /usr/local/share/ca-certificates/letsencryptx4.crt
sudo dpkg-reconfigure ca-certificateswährend des Rekonfigurationsstadiums, bitte deselect "DST Root CA X3" Zertifikat
Nach diesen Schritten sollte apt update für LetsEncrypt-basierte Quellen funktionieren und wget und curl sollten nicht meckern.
Besondere Anmerkung zu curl -k erlaubt die Verbindung zu 'unsicheren' SSL-Servern, was in diesem Fall zutrifft, da das LetsEncrypt-Zertifikat nicht vertrauenswürdig ist.
Die am meisten gewählte Antwort ist leider falsch. Sie wird zwar die gewünschte Wirkung haben, aber aus den falschen Gründen.
Die Befehle in VonC's Antwort fügen alle Zertifikate in der Kette zum Trust-Anchor-Speicher hinzu. Diese Zertifikate sind jedoch keine Trust-Anker (oder Root-CA-Zertifikate in anderen Worten); es handelt sich um Endnutzer- und Zwischen-CA-Zertifikate.
Der TLS-Standard RFC 5246 besagt:
Zertifikatsliste
Dies ist eine Sequenz (Kette) von Zertifikaten. Das Zertifikat des Senders MUSS zuerst in der Liste stehen. Jedes folgende Zertifikat MUSS das vorherige direkt beglaubigen. Da die Zertifikatsvalidierung erfordert, dass Root-Schlüssel unabhängig verteilt werden, darf das selbstsignierte Zertifikat, das die Root-Zertifizierungsstelle angibt, aus der Kette weggelassen werden, unter der Annahme, dass der entfernte Teil es bereits besitzt, um es in jedem Fall zu validieren.
Daher könnte der Befehl von VonC (und anderen) durchaus alle falschen Zertifikate hinzufügen und nicht das Root-CA.
Ein Endnutzer- oder Zwischen-CA-Zertifikat ist kein Trust-Anchor. Diese Zertifikate können sich im Laufe der Zeit ändern, und in diesem Fall wird dasselbe Problem erneut auftreten. Außerdem, was passiert, wenn das Endnutzerzertifikat aus irgendeinem Grund widerrufen wird? Ihr Computer könnte weiterhin dem widerrufenen Zertifikat vertrauen - in der Praxis kann die genaue Reaktion je nach verwendeter Kryptobibliothek unterschiedlich sein, da dies nicht gut definiert ist in den Standards und daher Variationen in der Implementierung unterliegt.
Der korrekte Weg, dieses Problem zu beheben, besteht darin, das letzte Zertifikat in der Kette zu überprüfen, zu bestätigen, dass es sich nicht um ein Root-CA handelt (da dies vom Server gesendet werden Kann - siehe das oben zitierte RFC-Auszug) und falls dies der Fall ist, den Issuer und möglicherweise das AKI-Feld zu überprüfen, um festzustellen, welches Root-CA dieses erste Zwischen-CA-Zertifikat ausgestellt hat. Nachdem die Details herausgearbeitet wurden, müssen Sie das Repository dieses Root-CA besuchen und das Zertifikat (und den Hash überprüfen) dieses herunterladen, bevor Sie es herunterladen. Überprüfen Sie das CP/CPS dieses Root-CA, bevor Sie sich entscheiden, es in Ihren Trust-Anchor-Speicher zu installieren.
Wenn das letzte Zertifikat das Root-CA ist, verwenden Sie die openssl x509...-Befehle, um die Details anzuzeigen, und führen Sie dann eine Sorgfaltspflicht durch, bevor Sie entscheiden, ob Sie dieses einzige Zertifikat in Ihren Trust-Anchor-Speicher installieren sollten.
Es kann und sollte keinen automatischen Prozess geben, um das oben Genannte auszuführen, da Sie die Herkunft des Trust-Ankers überprüfen müssen, bevor Sie entscheiden, ihn Ihrem Trust-Anchor-Speicher hinzuzufügen. Fragen Sie sich, warum es nicht Teil des ca-certificate-Pakets (oder eines entsprechenden für Ihre Distribution) war, bevor Sie es blind installieren.
Es kann jedoch hilfreich sein, etwas Ähnliches wie das Folgende auszuführen, um den Subject und Issuer des letzten Zertifikats in der Kette anzuzeigen, was Ihnen dabei helfen könnte, das fehlende Root-CA-Zertifikat zu verfolgen:
echo -n | openssl s_client -showcerts -servername www.github.com -connect www.github.com:443 2>/dev/null | tac | awk '/-END CERTIFICATE-/{f=1} f;/-BEGIN CERTIFICATE-/{exit}' | tac | openssl x509 -noout -subject -issuerWas in meinem Fall Ende Mai 2021 zu folgendem Ergebnis führt:
Subject=C = US, O = "DigiCert, Inc.", CN = DigiCert High Assurance TLS Hybrid ECC SHA256 2020 CA1
Issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CAAus dem obigen Beispiel können wir sehen, dass der Server das Zwischen-CA-Zertifikat gesendet hat, nicht das Root (der Subject und Issuer sind unterschiedlich). Dieses Zwischen-CA-Zertifikat wurde von DigiCert's High Assurance EV Root CA unterzeichnet. Wir können nun zum DigiCert-Repository gehen und dieses bestimmte Zertifikat herunterladen.
Bevor Sie dieses Zertifikat installieren, stellen Sie sicher, dass es dasjenige ist, das Ihr Zwischen-CA signiert hat, indem Sie openssl x509 -noout -text -in gegen es ausführen und den Wert der X509v3 Authority Key Identifier-Erweiterung mit derselben Erweiterung im Zertifikat vergleichen, das vom Server gesendet wurde. Hinweis: Sie können diese Erweiterung auf dem Zwischen-CA-Zertifikat, das vom Server gesendet wurde, anzeigen, indem Sie -subject -issuer am Ende des vorherigen Befehls zu -text ändern.
Sobald Sie sicher sind, dass das Root-CA-Zertifikat, das Sie heruntergeladen haben, das richtige ist, und Sie eine Sorgfaltspflicht durchgeführt haben und entschieden haben, dass Sie diesem Root-CA vertrauen, fügen Sie es Ihrem Trust-Anchor-Speicher hinzu:
sudo mv /usr/local/share/ca-certificates/
sudo update-ca-certificatesBeachten Sie, dass die Datei im PEM-Format vorliegen muss und der Dateiname mit .crt enden muss, da sonst update-ca-certificates sie nicht erkennen wird.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
