SVN, OSX10.7: SSL handshake failed: SSL error code -1/1/336032856

Ich habe Probleme beim Zugriff auf ein svn-repository durch eine SSL-handshake-Fehler. Hier ist die Ausgabe, die ich bekommen

$ svn ls https://example.edu:40657/folder
svn: OPTIONS of 'https://example.edu:40657/folder': SSL handshake failed: SSL error code -1/1/336032856 (https://example.edu:40657)

Begann dies, nachdem das repository auf einen anderen server umgezogen. Ein neues Sicherheits-Zertifikat ausgestellt wurde sowie.

Gesehen hab ich die Frage hier (Handshake-Fehler "SSL-Fehler-code -1/1/336032856" auf OS X 10.7) und die faq gelesen, aber mein ssl-version ist 1.0.1 c. Ich denke, dies ist ein clientseitiges Problem, da keine andere (linux -) Maschinen, die das problem aufweisen. Habe ich gelöscht, meine ~/.subversion-Ordner und gelöscht in meinem Schlüsselbund nichts markiert svn oder ssl, aber immer noch kein Glück. Meine Vermutung ist, es gibt immer noch Sicherheit Schlüssel irgendwo gespeichert, dass weiß ich nicht. Irgendwelche Ideen?

  • Welche version von svn verwenden Sie? Versuchen which svn und svn --version. Wenn es die von Apple bereitgestellten eine von Xcode, es ist nicht mit openssl 1.0.1 c, da diese version ist nicht im Lieferumfang von OS X.
  • die svn zurück usr/bin/svn und svn --version gibt 1.6.17
  • Das ist zweifelsohne der von Apple mitgelieferten version und die Installation einer neuen version von openssl hat keine Wirkung auf Sie. Also das scheint das gleiche problem wie die Frage, die Sie zitieren.
InformationsquelleAutor dmagree | 2013-02-25
  1. 3

    Hatte ich diesen Fehler auch, wenn Sie versuchen, um zu überprüfen heraus ein repository auf einem server mit einem selbst signierten Zertifikat.

    Sie erfüllen müssen 2 Voraussetzungen:

    • der CN (Common Name) im Zertifikat sollte mit dem Hostnamen verwendest du in der repo-URL
    • der ServerName konfiguriert in der Virtuellen Host-handling die Anfrage sollte mit dem URL zu.

    Letzteres könnte genug sein.

    War ich mit dem Standard-ssl apache-config von Debian, die nicht alle bestimmten ServerName (also der Haupt-ServerName aus der globalen Apache-config benutzt wird). Zugriff auf das repository über den echten Hostnamen des Servers der Arbeit war (Sie bekommen nur die "Das Zertifikat ist nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt" Achtung: das erste mal, wenn Sie versuchen, eine Verbindung herstellen), aber der Versuch, darauf zuzugreifen, die durch eine andere alias (auch durch seine IP) nicht mit diesem Fehler.

    Also der workaround ist hier zu Fragen, der server-admin, was ist der eigentliche ServerName (kann es sein, aufgeführt in der Fußzeile eine 404-Fehler-Seite) oder ihn zu bitten, entsprechend zu setzen.

    Beispiel:

    $ svn co https://alias.or.ip.of.the.server.real.hostname/svn/test
svn: OPTIONS of 'https://alias.or.ip.of.the.server.real.hostname/svn/test': SSL negotiation failed: SSL    error code -1/1/336032856 (https://alias.or.ip.of.the.server.real.hostname)

$ svn co https://real.hostname.of.the.server/svn/test
Error validating server certificate for 'https://real.hostname.of.the.server:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: real.hostname.of.the.server
 - Valid: from Mon, 23 Sep 2013 10:55:49 GMT until Thu, 21 Sep 2023 10:55:49 GMT
 - Issuer: real.hostname.of.the.server
 - Fingerprint: 61:81:26:51:53:26:9a:ea:c1:28:b8:6d:22:13:05:8f:81:1a:ed:67
(R)eject, accept (t)emporarily or accept (p)ermanently?

    Dauerhaft und du bist gut zu gehen!

    InformationsquelleAutor Capsule
  2. 2

    Kann dies auch passieren durch TLS mit SNI (https://en.wikipedia.org/wiki/Server_Name_Indication).

    Gegeben, die Sie verwenden Apache mit sowas config

    ServerName  my-server
ServerAlias another-name

    Und der client verbindet sich mit Ihrem server mit dieser URL

    svn ls https://svn-server

    Wenn der Client SNI sagen Sie der server während des Handshakes 

    Btw. I think you are called "svn-server"

    Server kennt nur sich selbst durch den Namen "my-server" und "andere Namen", damit es ausgelöst wird eine TLS-Warnung:

    Warning: I am not called "svn-server". That name is unknown to me.

    Dieser Warnung führt zu einem handshake-Fehler, wie der Kunde denkt, etwas schlimmes passiert.

    Einen Lösung wäre, den Namen, den der client verwendet, um die server-Aliase

    ServerAlias another-name svn-server

    Und vergessen Sie nicht zu überprüfen, ob das SSL-Zertifikat ist "Common Name" oder Aliase passt auch der name, den der client verwendet.

    InformationsquelleAutor
  3. 1

    Vielen Dank Ned Deily, seine Kommentare waren korrekt. Das problem verschwand, nachdem ich heruntergeladen und gebaut subversion-1.7.8 (http://subversion.apache.org/download/#recommended-release). Ich hatte auch den download und build-neon (http://www.webdav.org/neon/), um zu erlauben, svn erkennt http-und https-Adresse. Schließlich hatte ich, um die von apple mitgelieferten svn-binaries in einen anderen Ordner, um die neue version gefunden (neue version wurde installiert in /usr/local/bin, während das von apple mitgelieferte version war installiert in /usr/bin).

    InformationsquelleAutor dmagree
  4. 1

    http://subversion.apache.org/faq.html#ssl-error-336032856

    Dies kann passieren, wenn der hostname berichtet von der server nicht das match hostname in das SSL-Zertifikat. Stellen Sie sicher, dass Ihre server-Konfiguration verwendet die richtigen Werte für ServerName und NameVirtualHost.

    InformationsquelleAutor hustxxb
  5. 1

    Erhielt ich eine ähnliche Fehlermeldung, und es zeigte sich, dass die Ursache war, dass die Systemuhr deaktiviert wurde (die Sommerzeit hatte sich gerade verabschiedet, und der system-Uhr wurde aus 1 Stunde).

    InformationsquelleAutor James Wierzba
Schreibe einen Kommentar