hi,

ich versage gerade kläglich dabei ein paar Quellen von einem SVN Server zu laden. Leider ist der Server auf https - was dazu führt das meine SVN Clients (1x turtoise auf Windows, 1x svn auf ubuntu) beide folgenden Fehler werfen:

"SSL negotiation failed: SSL error: unknown protocol (..url.. )"

und google mir keinen schritt weiter hilft.

jemand eine Idee ?

danke

Ich empfehle zu lesen: Version Control with Subversion

Mache ein einfaches Checkout via https

Phil

Leider ist der Server auf https ...

jemand eine Idee ?

Also https ist kein Problem, ansich. Bei sourceforge ist es auch https und das geht, prizipiell (selbst schon gemacht).

Was hast du denn genau versucht/getan?

svn co https://svn.typo3.org/FLOW3/Distribution

war der erste Antrieb, ich will einen Blick auf Flow3 werfen

als das nicht ging eine Referenzverbindung:

svn co https://svn.collab.net/repos/svn

svn ls ...

geht auch nicht.

und entsprechend ein checkout (und / oder) import in tourtoise mit o.g. Adressen.

Was mich verwirrt ist das "unknown protocol", hätte er gesagt er kann nur nicht Verbinden würde ich auf die Firewall tippen.

Detailierter: (aus dem Ubuntu heraus)

svn co https://svn.typo3.org/FLOW3/Distribution

svn: PROPFIND request failed on '/FLOW3/Distribution'

svn: PROPFIND of '/FLOW3/Distribution': SSL negotiation failed: SSL error: unknown protocol (https://svn.typo3.org)

danke

Das Zertifikat ist selbstsigniert, lad es runter und installiere es als gültiges auf Deinem Rechner.

HTH Phil

hast du auch ein "wie" für mich, auf linux.

Ist bei mir ein paar monate zu lange her ^^, auf Windows noch nie gemacht.

danke

unter BSD wird wie folgt vom SVN gefragt:

Error validating server certificate for 'https://svn.typo3.org:443':

 - The certificate is not issued by a trusted authority. Use the

   fingerprint to validate the certificate manually!

Certificate information:

 - Hostname: *.typo3.org

 - Valid: from Tue, 05 Feb 2008 15:12:38 GMT until Thu, 04 Feb 2010 15:12:38 GMT

 - Issuer: http://www.cacert.org, Root CA

 - Fingerprint: c9:dd:d9:1d:e3:b5:87:47:40:f7:ca:b2:68:f0:3c:1e:b9:0b:70:4b

(R)eject, accept (t)emporarily or accept (p)ermanently? 

Bein Windows werden Zertfikate in den Zertifikatbaum gespeichert. Man läd sie als *.der runter bzw muss *.pem konvertieren und dann einfügen. Evtl kann aber ein Windows SVN Client das auch automatisieren

Phil

P.S.: Das ist aber kein SVM Problem sondern ein generelles Deiner Konfiguration

Bearbeitet 18. Juni 200817 j von flashpixx

Also ich hab es grade mal probiert, RapidSVN unter Kubuntu... geht ohne Probleme auszuchecken :confused:

Execute: Checkout

Added: /tmp/trunk

Added: /tmp/trunk/GPL.txt

Added: /tmp/trunk/Configuration

Added: /tmp/trunk/Configuration/FLOW3.php

...

ich bekomme keine Aufforderung etwas anzunehmen o.ä.,

habe nachgesehen, man kann in der SVN-Konfiguration (Ubuntu) SSL-Zertifikate als .pem angeben. Evtl. funktioniert es dann, aber wie komme ich an das .pem file ?

danke

ich bekomme keine Aufforderung etwas anzunehmen o.ä.,

Also ich hab einfach nur einen checkout gemacht (List geht mit dem Client gar nicht, is mir vorher nie aufgefallen). Repository URL angegeben, lokalen Pfad und go. Mehr war da nicht...

EDIT:

Sitzt du vielleicht hinter einem Proxy o.ä. der den Port sperrt?

browser & co nehmen das Zertifikat an. Oder welchen Port meinst du ?

(Proxy ist in svn auch eingestellt)

Ich hab gerade mal im Web bissl gesucht: SSL negotiation failed: SSL error: unknown protocol

Dabei hab ich folgende Seite gefunden:

NSS and SSL Error Codes

Da ist zwar nicht direkt der Fehler dabei, aber Fehler wie z.B.

SSL_ERROR_UNSUPPORTED_VERSION -12279 "Peer using unsupported version of security protocol."

On a client socket, this means the remote server has attempted to negotiate the use of a version of SSL that is not supported by the NSS library, probably an invalid version number. On a server socket, this means the remote client has requested the use of a version of SSL older than version 2.

Also ich finde, das könnte auch die Ursache hierfür sein, also dass dein Client eine falsche Version o.ä. hat.

Da du das über einen Proxy machst, vielleicht filtert der da was aus?

Anderswo hab ich gelesen, dass du u.U. das Zertifikat updaten sollst. Hast du vielleicht schonmal auf den Server zugegriffen und dort wurde mittlerweile (wegen des OpenSSL Problems) ein neues Zertifikat erstellt und bei dir wird das eben als fehlerhaft erkannt?

Nachtrag: Dieser Fehler tritt wohl auch auf (nicht nur auf svn bezogen) wenn der Client keine SSL-Verbindung aufbaut bzw unterstützt. Das könnte u.U. wieder am Proxy liegen.

Bearbeitet 19. Juni 200817 j von JesterDay

Müsste der Proxy nicht HTTPS einfach "nicht filtern" ? Denn in die verschlüsselten Pakete kann er ja nicht schauen.

*Etwas ratlos sei*

Phil

Denn in die verschlüsselten Pakete kann er ja nicht schauen.

Noch ist ja nichts verschlüsselt, da der Client und der Server erst die Verbindung aushandeln (siehe Fehlermeldung. Der Client will Protocol Version X, der Server kennt aber nur Version Y -> unknown protocol, oder aber alles was SSL betrifft wird nicht durchgelassen und eine einfache nicht verschlüsselte Verbindung wird angefordert).

Nachtrag: Da es bei dir und bei mir geht, und er nen Proxy dazwischen hat liegt die Vermutung ja nahe, dass der was damit zu tun hat... wie auch immer.

Bearbeitet 19. Juni 200817 j von JesterDay

fehler gefunden und neuer fehler

Ich habe den Http Port des Proxys nicht den https Port verwendet.

Neues Problem:

svn co https://svn.typo3.org/FLOW/Distribution

... frage nach ssl und akzeptiert

svn: PROPFIND request failed on '/FLOW/Distribution'

svn: PROPFIND of '/FLOW/Distribution': 405 Method Not Allowed (https://svn.typo3.org)

ich hoffe ihr habt auch dafür eine idee

Mein erster Gedanke war Benutzername und Passwort (weil ich davon ausgehe, dass der Server nicht falsch konfiguriert ist * ), aber dann hab ich das gefunden

The 405 error that Charles is seeing, however, is most often caused by

a web proxy blocking WebDAV http requests (like PROPFIND). That's most

likely the problem.

*: Das tritt nämlich z.B. auch dann auf, wenn der Server keinen Zugriff auf das Verzeichnis hat o.ä.

Bearbeitet 19. Juni 200817 j von JesterDay

habe es gerade auch von zu hause versucht. Gleiches Problem (405), das einzige was hier zwischen ist, ist ein handelsüblicher Netzwerkrouter.

Wenn SVN so hohe Ansprüche an jeden stellt der zugreifen will ist das System mist (sorry ^^)

edit:

Vergesst es *beschämt in ecke stellt* das verzeichnis sollte schon korrekt sein.....

Bearbeitet 19. Juni 200817 j von Aiun

Ich kann eigentlich nur noch sagen, dass bei Dir in der Konfiguration nicht in Ordnung ist, denn weder unter OSX, WinXP und Ubuntu Linux (Edgy) kann ich Deine Fehler reproduzieren

HTH Phil

wie gesagt, der 405 war auf ein falsches verzeichnis zurück zu führen.