Einmal zertifizieren, bitte!

Mit dem folgenden Thema wird man in der Regel keine Berührung finden. Und dann aber vielleicht doch. Es geht um selbstsignierte Zertifikate und mögliche Probleme damit. Und in eben jene bin ich letztens gelaufen. Es hat etwas gedauert, eine Lösung zu finden, darum möchte ich hier nochmal zusammenfassend darüber berichten – und vielleicht jemand anderem damit Hilfestellung geben.

If you choose the quick and easy path, you will become an agent of evil

Mir wurde ein neues git-Repository zur Verfügung gestellt, in welches unser Projekt-Quellcode wandern sollte. Dieses Repository soll natürlich von jedem Entwickler, aber auch von unseren Tools jenkins und Upsource zugreifbar sein (ich werde beide Werkzeuge bald in eigenen Beiträgen vorstellen). Und so fingen die Probleme auch schon an. Natürlich handelte es sich in meinem Fall um ein selbstausgestelltes Zertifikat der Firma und Git weigert sich per default, selbstausgestellte Zertifikate zu akzeptieren. Man kann ihm natürlich beibringen, welche Zertifikate es annehmen soll und wo die benötigten Informationen liegen: man kann die SSL-Prüfung auch einfach abschalten. Prinzipiell ist das eher unschön, da die Rechner aber nur auf Firmen-interne Repositories zugreifen, wäre das in meinem Fall akzeptabel. Dafür setzt ihr in der git-Bash folgende Kommandos ab (je nachdem, ob ihr http oder https verwendet):

Mit diesen zwei Befehlen deaktiviert ihr die SSL-Überprüfung für http- und https-Verbindungen in der lokalen .gitconfig für das jeweilige Repository. Wenn ihr mehrere Repositories habt, für die ihr die Überprüfung abschalten wollt, könnt ihr das auch in eurer globalen .gitconfig abspeichern.

Achtung: Das gilt dann für _alle_ eure git Verbindungen!

Soweit, so gut. Wir können von unseren Entwicklungsrechnern auf das Repository zugreifen. Als nächstes ist der Jenkins dran. Der steht natürlich vor dem gleichen Problem. Der Windows-Service, der jenkins startet, läuft unter meinem Account, also müsste er eigentlich mit meiner globalen .gitconfig arbeiten. Tut er aber leider nicht. Da der Build-Rechner über keinen Internetzugriff verfügt und lediglich auf das Repository zugreifen darf, entschloss ich mich dafür, testweise System-weit die Verifizierung abzuschalten. Hierzu ersetzte ich einfach das –global durch –system. Und schon liefen auch die Build-Jobs wieder.

You must unlearn what you have learned

Zwar hatte ich jetzt alles am Laufen, zufrieden war ich jedoch nicht wirklich. Denn mit etwas mehr Aufwand lässt sich die Situation wesentlich sauberer (und vor allem sicherer) lösen. Zuerst benötigen wir das Zertifikat selbst, im X.509 Format mit PEM-Encoding. An dieses kommen wir recht leicht über das Tool Portecle. Als erstes müssen wir auf Examine -> Examine SSL/TLS Connection klicken.

Dann geben wir den Namen der Website unseres Repositorys ein – ich habe hier github als Beispiel gewählt. Wenn wir den Dialog bestätigen, kommt ein neues Fenster, das uns n Zertifikate anzeigt (in diesem Fall 2).

Nun können wir uns über einen Klick auf PEM Encoding das Zertifikat anzeigen lassen.

Den Text inkl. —-BEGIN CERTIFICATE—- und —-END CERTIFICATE—- kopieren wir in eine Textdatei. Mit allen weiteren Zertifikaten verfahren wir ebenso und hängen diese einfach an die Textdatei an. Diese speichern wir an einem Wunschort ab, z.B. als certificate.pem. Fertig. Jetzt müssen wir git noch erklären, wo es das Zertifikat findet:

Auch hier können wir wieder die lokale (default), die globale (–global) oder die System-weite (–system) .gitconfig beschreiben. Wenn der Pfad Leerzeichen enthält, setzen wir ihn am Besten in Anführungszeichen. Da wir bereits die SSL-Überprüfung deaktiviert haben, müssen wir sie unbedingt wieder anschalten.

Wenn wir die Verbindung jetzt testen, sollte alles funktionieren.

Nachdem ich das Zertifikat auf den Buildrechner kopiert und dort über die System-weite Konfiguration mit git bekannt gemacht hatte, ließen sich alle Projekte wieder bauen. Ist das nicht großartig? Das gleich Ergebnis wie zuvor, diesmal aber _ohne_ sämtliche Sicherheitsmechanismen auszuhebeln.

Much to learn you still have… This is just the beginning!

Entwickler und jenkins haben bereits Zugriff auf das git-Repository, fehlt also noch Upsource. Schließlich wollen wir ja unseren Code kontinuierlich reviewen. Upsource verwendet für seine Zertifikate einen Zertifikatscontainer namens cacert. Diesen finden wir im Installationsverzeichnis von Upsource unter internal/java/linux-x64/jre/lib/security/cacerts. Unter Windows bzw. macOS verwendet ihr statt linux-x64 eben den entsprechenden Ordner. Diese cacerts-Datei öffnen wir mit Portecle über File -> Open CA Certs Keystore. Wir werden nach einem Passwort gefragt, welches bei der mit Upsource mitgelieferten Version standardmäßig changeit lautet. Im Anschluss klicken wir auf das Icon, das für Import a trusted certificate into the loaded keystore steht (Tooltip), wählen unser erstelltes Zertifkat aus, bestätigen alle Dialoge und speichern im Anschluss das cacerts-File ab. Nach einem Neustart von Upsource kommt es ebenfalls mit dem Zertifikat zurecht.

Falls ihr noch Subversion verwendet und mit dem gleichen Problem kämpft, so gibt es auch dafür einen Lösungsweg, der hier im Detail beschrieben ist. Für Upsource benötigt ihr keinen anderen Weg, da könnt ihr es genauso machen wie oben beschrieben.

Quellen:

workaround sslVerify Atlassian
Detaillierte Lösung, dass git Zertifikate akzeptiert
Upsource Lösungsweg 

Leave a Reply

Your email address will not be published. Required fields are marked *