git und https scheint sich hier zur „neverending story“ zu mausern :-) Trotzdem muß ich zu diesem Thema nochmals dringend etwas loswerden. Situation: Server ist eingerichtet, benutzt aber entweder ein selbstsigniertes Zertifikat oder von einer CA, die nicht „allgemein verbreitet“ ist (Firmen-CA, CAcert, etc.). Folge: Git meldet

error: SSL certificate problem: self signed certificate in certificate chain while accessing https://...
fatal: HTTP request failed

Klar, woher soll git auch das Zertifikat kennen… wirft man die Meldung in Google, landet man bei Empfehlungen wie dieser hier auf stackoverflow: Per Umgebungsvariable GIT_SSL_NO_VERIFY=true oder git-Konfiguration git config --global http.sslVerify false am besten gleich global die Überprüfung abschalten, dann gibt’s keine nervigen Fehlermeldungen mehr… JESUS H. CHRIST, DON’T DO THAT!

Hintergrund

(Wer’s eilig hat, kann zum nächsten Abschnitt springen)

Wer eine der obigen Lösungen nutzt, ist zwar die lästige Meldung los, öffnet einem Angreifer aber die Möglichkeit, sich selbst als der Server auszugeben - und so alle Daten im Klartext mitzulesen. Genau das soll die Prüfung des Zertifikats verhindern, schaltet man diese aus, ist man solchen Angriffen schutzlos ausgeliefert. Das ist das exakte äquivalent zur „nicht vertrauenswürdigen Verbindung“, die der Webbrowser bei machen Seiten meldet… wenn diese Seite zufällig gerade die der eigenen Bank ist, sollten ja auch die Alarmglocken schrillen (und man nicht nur einfach auf „jaja, ok“ klicken).

Wie man’s richtig macht

Zuerst benötigt man das Zertifikat der CA, welche der Server benutzt – aus einer vertrauenswürdigen Quelle. Das bedeutet (wenn man’s ganz genau machen will) ein Telefonat mit dem Administrator der Maschine. Alternativ kann man sich das Zertifikat einmal(!) vom Server holen und speichern:

openssl s_client -connect mein.server:443

Den Zertifikatsblock kopiert man sich in eine separate Datei. Aus Sicherheitssicht gibt es nun zwei Situationen: Entweder man hat tatsächlich das Orginalzertifikat erwischt – Glück gehabt, oder aber man bekam es bereits von einem Angreifer: Das bedeutet, daß man eine Fehlermeldung bekommen wird, wenn der Angreifer einmal abwesend ist (und man eine direkte Serververbindung bekommt). Ob man diese Unsicherheit riskieren will oder den aufwendigeren ersten Weg beschreitet, muß jeder selbst entscheiden.

Nun muß man git das Zertifikat noch bekannt machen. Einen neuen Clon legt man mit folgendem Befehl an:

GIT_SSL_CAINFO=/pfad/zum/zertifikat.crt git clone https://repo.url

In einem bestehenden Clon konfiguriert man das zugehörige Serverzertifikat folgendermaßen:

git config http.sslCAinfo /pfad/zum/zertifikat.crt

Bottom line: Kaum Mehraufwand, und dafür eine saubere Prüfung der Gegenseite. Oh, und tut mir bitte den Gefallen und ratet die entsprechenden „Tips“ auf stackoverflow ‘runter…