it-swarm.com.de

Wie kann ich dafür sorgen, dass git ein selbstsigniertes Zertifikat akzeptiert?

Gibt es eine Möglichkeit, mit Git ein selbstsigniertes Zertifikat anzunehmen?

Ich verwende einen https-Server, um einen git-Server zu hosten, aber das Zertifikat ist jetzt selbst signiert.

Wenn ich versuche, das Repo dort zum ersten Mal zu erstellen:

git Push Origin master -f

Ich bekomme den Fehler:

error: Cannot access URL     
https://the server/git.aspx/PocketReferences/, return code 22

fatal: git-http-Push failed
528

Um ein bestimmtes Zertifikat dauerhaft anzunehmen

Versuchen Sie http.sslCAPath oder http.sslCAInfo. Antwort von Adam Spiers gibt einige großartige Beispiele. Dies ist die sicherste Lösung für die Frage.

So deaktivieren Sie die TLS/SSL-Überprüfung für einen einzelnen git-Befehl

Übergeben Sie -c an git mit der richtigen config-Variablen, oder verwenden Sie Flows Antwort :

git -c http.sslVerify=false clone https://example.com/path/to/git

So deaktivieren Sie die SSL-Überprüfung für ein bestimmtes Repository

Wenn sich das Repository vollständig unter Ihrer Kontrolle befindet, können Sie Folgendes versuchen:

git config http.sslVerify false

Die weltweite Deaktivierung der TLS- (/ SSL-) Zertifikatsüberprüfung ist eine äußerst unsichere Vorgehensweise. Tu es nicht. Setzen Sie den obigen Befehl nicht mit einem --global-Modifikator ab.


Es gibt einige SSL-Konfigurationsoptionen in git. Aus der Manpage von git config:

http.sslVerify
    Whether to verify the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_NO_VERIFY environment variable.

http.sslCAInfo
    File containing the certificates to verify the peer with when fetching or pushing
    over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable.

http.sslCAPath
    Path containing files with the CA certificates to verify the peer with when
    fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CAPATH environment variable.

Einige andere nützliche SSL-Konfigurationsoptionen:

http.sslCert
    File containing the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CERT environment variable.

http.sslKey
    File containing the SSL private key when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_KEY environment variable.

http.sslCertPasswordProtected
    Enable git's password Prompt for the SSL certificate. Otherwise OpenSSL will
    Prompt the user, possibly many times, if the certificate or private key is encrypted.
    Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment variable.
941
Christopher

Sie können GIT_SSL_NO_VERIFY auf true setzen:

GIT_SSL_NO_VERIFY=true git clone https://example.com/path/to/git

oder alternativ konfigurieren Sie Git, um die Verbindung in der Befehlszeile nicht zu überprüfen:

git -c http.sslVerify=false clone https://example.com/path/to/git

Wenn Sie keine SSL-/TLS-Zertifikate überprüfen, sind Sie anfällig für MitM-Angriffe .

149
Flow

Ich bin kein großer Fan der [EDIT: Originalversionen der] vorhandenen Antworten, denn das Deaktivieren von Sicherheitsüberprüfungen sollte ein letzter Ausweg sein, nicht die erste angebotene Lösung. Auch wenn Sie selbstsignierten Zertifikaten beim ersten Empfang ohne eine zusätzliche Überprüfungsmethode nicht vertrauen können, macht die Verwendung des Zertifikats für nachfolgende git -Operationen das Leben für Angriffe, die nur after Sie haben das Zertifikat heruntergeladen. Mit anderen Worten, wenn das heruntergeladene Zertifikat ist echt ist, sind Sie von diesem Punkt an gut. Wenn Sie dagegen einfach die Überprüfung deaktivieren, sind Sie für jede Art von Man-in-the-Middle-Angriff offen zu jedem Zeitpunkt.

Um ein konkretes Beispiel zu nennen: das berühmte repo.or.cz Repository liefert ein selbstsigniertes Zertifikat . Ich kann diese Datei herunterladen und sie irgendwo ablegen wie /etc/ssl/certs und dann mache:

# Initial clone
GIT_SSL_CAINFO=/etc/ssl/certs/rorcz_root_cert.pem \
    git clone https://repo.or.cz/org-mode.git

# Ensure all future interactions with Origin remote also work
cd org-mode
git config http.sslCAInfo /etc/ssl/certs/rorcz_root_cert.pem

Beachten Sie, dass mit lokalen git config hier (d. h. ohne --global) bedeutet, dass dieses selbstsignierte Zertifikat nur für dieses bestimmte Repository (Nice) als vertrauenswürdig eingestuft wird. Es ist auch schöner als mit GIT_SSL_CAPATH da es das Risiko beseitigt, dass git die Überprüfung über eine andere Zertifizierungsstelle durchführt, was möglicherweise gefährdet sein könnte.

129
Adam Spiers

Global .gitconfig für selbstsignierte Zertifizierungsstellen

Für mich und meine Kollegen ist es uns gelungen, selbstsignierte Zertifikate zum Laufen zu bringen, ohne sslVerify zu deaktivieren. Bearbeiten Sie Ihren .gitconfig , um mithilfe von git config --global -e diese hinzuzufügen:

# Specify the scheme and Host as a 'context' that only these settings apply
# Must use Git v1.8.5+ for these contexts to work
[credential "https://your.domain.com"]
  username = user.name

  # Uncomment the credential helper that applies to your platform
  # Windows
  # helper = manager

  # OSX
  # helper = osxkeychain

  # Linux (in-memory credential helper)
  # helper = cache

  # Linux (permanent storage credential helper)
  # https://askubuntu.com/a/776335/491772

# Specify the scheme and Host as a 'context' that only these settings apply 
# Must use Git v1.8.5+ for these contexts to work
[http "https://your.domain.com"]
  ##################################
  # Self Signed Server Certificate #
  ##################################

  # MUST be PEM format
  # Some situations require both the CAPath AND CAInfo 
  sslCAInfo = /path/to/selfCA/self-signed-certificate.crt
  sslCAPath = /path/to/selfCA/
  sslVerify = true

  ###########################################
  # Private Key and Certificate information #
  ###########################################

  # Must be PEM format and include BEGIN CERTIFICATE / END CERTIFICATE, 
  # not just the BEGIN PRIVATE KEY / END PRIVATE KEY for Git to recognise it.
  sslCert = /path/to/privatekey/myprivatecert.pem

  # Even if your PEM file is password protected, set this to false.
  # Setting this to true always asks for a password even if you don't have one.
  # When you do have a password, even with this set to false it will Prompt anyhow. 
  sslCertPasswordProtected = 0

Verweise:

Geben Sie bei git cloneing die config an

Wenn Sie es auf Repo-Basis anwenden müssen, werden Sie in der Dokumentation aufgefordert, nur git config --local in Ihrem Repo-Verzeichnis auszuführen. Nun, das ist nicht nützlich, wenn Sie das Repo noch nicht lokal geklont haben.

Sie können den global -> local hokey-pokey ausführen, indem Sie Ihre globale Konfiguration wie oben festlegen und diese Einstellungen dann in Ihre lokale Repokonfiguration kopieren, sobald sie geklont wird. 

ODER was Sie tun können, ist spezifizieren Sie die Konfigurationsbefehle unter git clone , die auf das Ziel-Repo angewendet werden, sobald es geklont wird.

# Declare variables to make clone command less verbose     
OUR_CA_PATH=/path/to/selfCA/
OUR_CA_FILE=$OUR_CA_PATH/self-signed-certificate.crt
MY_PEM_FILE=/path/to/privatekey/myprivatecert.pem
SELF_SIGN_CONFIG="-c http.sslCAPath=$OUR_CA_PATH -c http.sslCAInfo=$OUR_CA_FILE -c http.sslVerify=1 -c http.sslCert=$MY_PEM_FILE -c http.sslCertPasswordProtected=0"

# With this environment variable defined it makes subsequent clones easier if you need to pull down multiple repos.
git clone $SELF_SIGN_CONFIG https://mygit.server.com/projects/myproject.git myproject/

Einzeiler

EDIT: Siehe VonC s answer , das eine Einschränkung bezüglich absoluter und relativer Pfade für bestimmte Git-Versionen von 2.14.x/2.15 auf diesen einen Liner hinweist

git clone -c http.sslCAPath="/path/to/selfCA" -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" -c http.sslVerify=1 -c http.sslCert="/path/to/privatekey/myprivatecert.pem" -c http.sslCertPasswordProtected=0 https://mygit.server.com/projects/myproject.git myproject/

CentOS unable to load client key

Wenn Sie dies auf CentOS versuchen und Ihre .pem-Datei Ihnen anzeigt 

unable to load client key: "-8178 (SEC_ERROR_BAD_KEY)"

Dann möchten Sie diese StackOverflow-Antwort darüber, wie curl NSS anstelle von Open SSL verwendet.

Und Sie möchten curl von Quelle neu erstellen :

git clone http://github.com/curl/curl.git curl/
cd curl/
# Need these for ./buildconf
yum install autoconf automake libtool m4 nroff Perl -y
#Need these for ./configure
yum install openssl-devel openldap-devel libssh2-devel -y

./buildconf
su # Switch to super user to install into /usr/bin/curl
./configure --with-openssl --with-ldap --with-libssh2 --prefix=/usr/
make
make install

Computer neu starten, da sich libcurl noch als gemeinsam genutzte Bibliothek im Speicher befindet

Python, Pip und Conda

Related: Wie füge ich ein benutzerdefiniertes CA-Stammzertifikat zum CA Store hinzu, der von Python in Windows verwendet wird?

23
Josh Peak

Ich bin immer wieder auf dieses Problem gestoßen, also habe ich ein Skript geschrieben, um das selbstsignierte Zertifikat vom Server herunterzuladen und unter ~/.gitcerts zu installieren. Aktualisieren Sie dann git-config, um auf diese Zertifikate zu zeigen. Es wird in der globalen Konfiguration gespeichert, sodass Sie es nur einmal pro Remote ausführen müssen.

https://github.com/iwonbigbro/tools/blob/master/bin/git-remote-install-cert.sh

14
Craig

Diese Antwort ist ein Auszug aus diesem Artikel von Michael Kauffman.

Verwenden Sie Git für Windows mit einem Unternehmens-SSL-Zertifikat

Problem :

Wenn Sie ein Unternehmens-SSL-Zertifikat haben und Ihr Repo von der Konsole oder vom VSCode klonen möchten, wird die folgende Fehlermeldung angezeigt:

Fatal: Kein Zugriff auf ' https: // myserver/tfs/DefaultCollection/_git/Proj / ': Problem mit SSL-Zertifikat: Lokales Ausstellerzertifikat kann nicht abgerufen werden

Lösung :

  1. Exportieren Sie das selbstsignierte Stammzertifikat in eine Datei. Sie können dies in Ihrem Browser tun.

  2. Suchen Sie die Datei "ca-bundle.crt" in Ihrem Git-Ordner (aktuelle Version C:\Programme\Git\usr\ssl\certs, wurde jedoch in der Vergangenheit geändert). Kopieren Sie die Datei in Ihr Benutzerprofil. Öffnen Sie es mit einem Texteditor wie VSCode und fügen Sie den Inhalt Ihres exportierten Zertifikats am Ende der Datei hinzu.

Jetzt müssen wir git so konfigurieren, dass die neue Datei verwendet wird:

git config --global http.sslCAInfo C:/Users/<yourname>/ca-bundle.crt

Dadurch wird der Datei .gitconfig im Stammverzeichnis Ihres Benutzerprofils der folgende Eintrag hinzugefügt.

[http] sslCAInfo = C:/Users/<yourname>/ca-bundle.crt

7
AperioOculus

Überprüfen Sie Ihre Antivirus- und Firewall-Einstellungen.

Von einem Tag auf den anderen funktionierte git nicht mehr. Mit dem oben beschriebenen habe ich festgestellt, dass Kaspersky ein selbstsigniertes persönliches persönliches Antivirus-Stammzertifikat in die Mitte stellt. Ich habe es nicht geschafft, Git das Zertifikat gemäß den obigen Anweisungen akzeptieren zu lassen. Ich habe das aufgegeben. Was für mich funktioniert, ist das Deaktivieren der Funktion zum Scannen verschlüsselter Verbindungen.

  1. Öffnen Sie Kaspersky
  2. Einstellungen> Weitere> Netzwerk> Keine verschlüsselten Verbindungen prüfen

Danach arbeitet git wieder mit aktiviertem sslVerify.

Hinweis. Dies ist für mich immer noch nicht zufriedenstellend, da ich diese Funktion meines Anti-Virus aktiv haben möchte. In den erweiterten Einstellungen zeigt Kaspersky eine Liste von Websites an, die mit dieser Funktion nicht funktionieren. Github ist nicht als einer von ihnen aufgeführt. Ich werde es im Kaspersky-Forum überprüfen. Es scheint einige Themen zu geben, z. https://forum.kaspersky.com/index.php?/topic/395220-kis-interfer-mit-git/&tab=comments#comment-2801211

3
Henk

Seien Sie vorsichtig, wenn Sie einen Liner mit sslKey oder sslCert verwenden, wie in Josh Peak 's answer :

git clone -c http.sslCAPath="/path/to/selfCA" \
  -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" \
  -c http.sslVerify=1 \
  -c http.sslCert="/path/to/privatekey/myprivatecert.pem" \
  -c http.sslCertPasswordProtected=0 \
https://mygit.server.com/projects/myproject.git myproject

Nur Git 2.14.x/2.15 (Q3 2015) kann einen Pfad wie ~username/mykey richtig interpretieren (während er dennoch einen absoluten Pfad wie /path/to/privatekey interpretieren kann).

commit 8d15496 (20 Jul 2017) von Junio ​​C Hamano (gitster) .
Geholfen hat: Charles Bailey (hashpling) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit 17b1e1d , 11 Aug 2017)

http.c: http.sslcert und http.sslkey sind beide Pfadnamen

Damals, als der moderne Codepfad http_options () erstellt wurde, um .__ zu parsen. verschiedene http. * -Optionen unter 29508e1 ("Isolierte gemeinsam genutzte HTTP-Anforderung Funktionalität", 2005-11-18, Git 0.99.9k), und wurde später für .__ korrigiert. Interation zwischen den mehreren Konfigurationsdateien in 7059cd9 ("http_init(): Fixieren der Konfigurationsdatei", 2009-03-09, Git 1.6.3-rc0), haben wir .__ analysiert. Konfigurationsvariablen wie http.sslkey, http.sslcert als normal Vanillestränge, weil git_config_pathname() das .__ versteht. Das Präfix "~[username]/" war nicht vorhanden. 

Später konvertierten wir einige davon (nämlich http.sslCAPath und http.sslCAInfo), um die Funktion zu verwenden, und fügten Variablen wie http.cookeyFilehttp.pinnedpubkey hinzu, um die Funktion von Anfang an zu verwenden. Aus diesem Grund verstehen diese Variablen alle das Präfix "~[username]/".

Machen Sie die restlichen zwei Variablen, http.sslcert und http.sslkey, auch sich der Konvention bewusst sind, da beide eindeutig Pfadnamen zu .__ sind. Dateien.

2
VonC

In der Datei .gitconfig können Sie den unten angegebenen Wert hinzufügen, um das selbstsignierte Zertifikat akzeptabel zu machen

sslCAInfo = /home/XXXX/abc.crt

Unter Windows funktionierte das für mich:

Fügen Sie den Inhalt Ihres selbstsignierten Zertifikats am Ende der Datei ca-bundle hinzu. Einschließlich der Zeilen ----- BEGIN CERTIFICATE ----- und ----- END CERTIFICATE -----

Der Speicherort der Datei ca-bundle ist normalerweise C:\Programme\Git\mingw64\ssl\certs

Fügen Sie anschließend den Pfad der Datei ca-bundle zur globalen Git-Konfiguration hinzu. Der folgende Befehl führt den Trick aus: git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"

Hinweis: Der Pfad ist abhängig von Ihrem lokalen Pfad der ca-Bundle-Datei!

1
rw026

Fügen Sie unter Verwendung der 64-Bit-Version von Git unter Windows das selbstsignierte CA-Zertifikat den folgenden Dateien hinzu:

  • C:\Programme\Git\mingw64\ssl\certs\ca-bundle.crt 
  • C:\Programme\Git\mingw64\ssl\certs\ca-bundle.trust.crt

Wenn es sich nur um ein selbstsigniertes Serverzertifikat handelt, fügen Sie es hinzu

  • C:\Programme\Git\mingw64\ssl\cert.pem
1
Flaviu

Meine Antwort mag spät sein, aber es hat bei mir funktioniert. Es kann jemandem helfen.

Ich habe die oben genannten Schritte ausprobiert und das hat das Problem nicht gelöst.

versuche diesen git config --global http.sslVerify false

0
Manjuboyz

Ich benutze eine Windows-Maschine und dieser Artikel hat mir geholfen. Grundsätzlich habe ich ca-bundle.crt im Editor geöffnet und Kettenzertifikate hinzugefügt (alle). Dieses Problem tritt normalerweise in Unternehmensnetzwerken auf, in denen zwischen System- und Git-Repo-Servern Zwischenhändler sitzen. Wir müssen alle Zertifikate in der Zertifikatskette mit Ausnahme des Blattzertifikats im Basis-64-Format exportieren und alle zu ca-bundle.crt hinzufügen und dann git für diese modifizierte CRT-Datei konfigurieren.

0
love gupta

So mach ich es:

git init
git config --global http.sslVerify false
git clone https://myurl/myrepo.git
0
JedatKinports