Probleme & Lösungen

Mac OSX: Subversion meldet »SSL handshake failed«

Von Matthias Loerke

FASTER Software – 15. August 2014
Erweiterungen in der Infrastruktur sind oftmals ein steiniger Weg. Besonders kleine Änderungen stellen den Administrator gelegentlich vor ungeahnte Schwierigkeiten. In unserem letzten Fall war das Ziel einem neuen Gerät den Zugriff auf die bestehende Quellcodeverwaltung zu ermöglichen.

Als ich kürzlich auf meinem MacBook versuchte auf unsere Quellcode-Verwaltung zuzugreifen, empfing mich die folgende freundliche Fehlermeldung: »SSL handshake failed: SSL error code -1/1/336032856« . Das Wort SSL ließ nichts gutes ahnen, dennoch ließ ich mich nicht entmutigen und begann mit der Fehlersuche.

Um Konnektivitätsprobleme auszuschließen testete ich den Zugriff über die Weboberfläche, mit einem Windows-Client sowie mit zwei verschiedenen Clients für Mac OS. Als Ergebnis funktionierten alle Zugriffe, bis auf die von den Mac-Clients. Da final auch der Zugriff auf dem Mac mittels Browser auf die Weboberfläche funktionierte, schloss ich Verbindungsprobleme erst einmal aus.

Wie befürchtet schien das Problem auf das verwendete SSL-Zertifikat hinauszulaufen. Da wir hier ein Zertifikat unserer internen CA verwenden, sind uns Probleme aus dieser Richtung nicht fremd. Die ersten Google-Treffer zur Fehlermeldung zeigten in Richtung OpenSSL, welches von den SVN-Clients verwendet wird. Die OpenSSL-Suit bietet einige Kommandozeilen-Tools mit deren Hilfe man Zertifikate bearbeiten und testen kann. Und in der Tat ergab ein Test mit „openssl s_client -connect [host]:[port]“ auch eine Fehlermeldung dass das Zertifikat nicht valide sei. Vorgreifend sei gesagt dass die Vertrauensstellung des Zertifikates nicht die Ursache des Problems war. Nach einigen Stunden des herumprobierens und -konfigurierens mit OpenSSL konnte ich die Verbindung mit dem Testtool erfolgreich aufbauen, mein SVN-Problem bestand jedoch unverändert.

Während des OpenSSL-Tests hatte ich bereits Bekanntschaft mit der erweiterten Konfiguration des VisualSVN-Servers gemacht. Eine Problematik war hier, dass das Root-Zertifikat nicht vom Server mitgeliefert wurde. Der zugrundeliegende Apache ließ sich jedoch dazu veranlassen, in dem man in der „httpd-custom.conf“ die Direktive „SSLCertificateChainFile“ ergänzt und auf das exportierte Root-Zertifikat verweist (PEM/CER-Format). Die „http-custom.conf“ ist eine Konfigurationsdatei die in der eigentlichen „http.conf“ am Ende als Include integriert ist. Da ein Kommentar in der „http.conf“ darauf hinweist keine manuellen Änderungen zu machen da die Datei von der Anwendung generiert wird, lassen sich zusätzliche Konfigurationen nur in der „http-custom.conf“ durchführen

Letztlich stieß ich auf die Ursache des Problems als ich die generierte „http.conf“ durchsah um die bestehenden Konfigurationsparameter zu prüfen: Als Hostname hatte die VisualSVN-Applikation leider den FQDN des Windows-Servers eingetragen. Da wir den Zugriff auf den Server über einen eigenen DNS-Namen durchführen, weicht dieser vom dem des tatsächlichen Hosts ab. SSL hatte sich also völlig zu Recht beschwert und die Verbindung verweigert. Eine Überprüfung in den Konfigurationsdialogen von VisualSVN zeigte den richtigen DNS-Namen, eine Korrektur musste hier also manuell erfolgen.

Als Lösung ergänzte ich in der „http-custom.conf“ die Direktive „ServerName“ mit dem richtigen DNS-Namen. Da sie in der Reihenfolge hinter der durch die Generierung gesetzten Direktive kommt, resultiert am Ende der richtige Hostname. Nach Neustart des VisualSVN-Servers ist der Verbindungsaufbau nun mit allen Clients möglich.