2010-12-18 25 views
13

Używam serwera, który akceptuje żądania https. Wygenerowałem własny certyfikat. Podczas odwiedzania strony w firefox pojawia się nieznany błąd certyfikatu, ale to w porządku. To (myślę) wskazuje, że przekierowanie portów i takie prace.Negocjacja SSL nie powiodła się z svn

Próbuję użyć svn z tym. Podczas używania svn na serwerze (ale przy użyciu zewnętrznego adresu IP) działa. Znów otrzymuję certyfikat jest nieznany, ale mnie to nie obchodzi.

Podczas korzystania svn na Mac OS XI dostać

negocjacji SSL nie powiodło się: kod błędu SSL -1/1/336032856

Znalazłem kilka postów na google na ten temat, ale wszyscy mówią, że to błąd z openssl w wersji 0.9.8 i że użycie czegoś wyższego powinno go naprawić.

Obecnie używam openssl 1.0.0c. Nie mam pojęcia, co jest nie tak. Sprawdziłem również dziennik błędów w httpd i nic nie pojawia się.

Wszelkie pomysły na ten temat naprawdę by pomogły.

Dzięki

Odpowiedz

7

Aktualizacja z SVN 1.6.15 do 1.6.16pl rozwiązać ten problem dla mnie.

+0

To jest poprawna odpowiedź. homebrew instaluje domyślnie 1.6.16. – dvydra

+0

1.6.17 również działa –

+1

1.7 działa również .. wygląda jak wersje> 1.6.15 praca – loostro

0

Zobacz, co się stanie, jeśli wyeliminujesz problem z SSL, dodając wygenerowany certyfikat do zaufanego magazynu certyfikatów klienta.

7

dostałam ten sam komunikat o błędzie, gdy moja konfiguracja Apache mylił - mój ServerName parametr w httpd.conf nie pasuje hosta w certyfikacie z podpisem własnym.

+0

To brzmi jak ścieżka do zejścia ... – sjas

2

Zacząłem otrzymywać ten błąd od starszych klientów subversion (Tortoise 1.6.4, myślę, i pysvn r1280), kiedy nasz serwer svn zaktualizował swoją instancję Apache. Wyszło to z użycia OpenSSL 0.9.8n do 1.0.0d.

Żółw został naprawiony przez uaktualnienie do wersji 1.6.16 (używa OpenSSL 1.0.0d).

Naprawianie pysvn było inną historią. W najnowszej wersji (r1360) pojawił się ten sam błąd. Nie było zbyt wiele informacji poza wskazówkami, że OpenSLL może wymagać aktualizacji. Próbowałem kopiowanie w różnych wersjach OpenSSL (libeay32.dll i ssleay32.dll) i oto wyniki:

  • 0.9.8j (istniejąca wersja DLL, wiązane z pysvn r1280) nie
  • 0.9.8o (w zestawie z najnowszej pysvn, r1360) nie
  • 0.9.8r (najnowsza z serii 0.9.8) nie
  • 1.0.0 * (seria 1.0 nie jest kompatybilny z pysvn binarny) FAIL
  • 0.9.8L (pobrane z klienta wiersza poleceń CollabNet SVN 1.6.9) SUKCES!

Więc niezależnie od tego, co naprawili w wydaniu L, wkrótce się zepsuło, albo jest coś specjalnego w plikach binarnych OpenSSL CollabNet.

1

W moim przypadku zaczęło się to dziać po zmianie niektórych certyfikatów po stronie serwera. Próbowałem usunąć .subversion/dir, aktualizując openssl, openssh, svn i nic ...

Naprawiono błąd, gdy zastąpiłem nazwę hosta URL adresem IP tego hosta. W istniejących kopiach roboczych wystarczyło z:

svn switch --relocate http://hostname.com https://ipaddress 

Nie jestem pewien, czy jest to bug czy co, ale wydaje się, że nowe certyfikaty nie są rozpoznawane i utrzymuje przy użyciu starych pamięci podręcznej te dla danej nazwy hosta.

+0

To rozwiązało również mój problem (wersja SVN 1.7.10), ale myślę, że to tylko obejście. Coś może się zmienić na moim serwerze SVN (nie mam nad nim kontroli), który powoduje, że SVN nie rozpoznaje już zaufanego certyfikatu serwera. –

1

Zgadzam się z wcześniejszą odpowiedzią Lukasa Cenovsky'ego, że ustawienie ServerName w konfiguracji apache rozwiązuje problem.

W tym linku http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf mówi się, że błąd pochodzi z biblioteki SSL.

pełny komunikat o błędzie (tak, aby umożliwić lepsze google indeksowanie) otrzymuję to:

 
$ svn ls https://www.OMITTED.dk/svn 
svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn' 
svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk) 

w pliku/etc/apache2/sites-available/ssl (Debian Linux) dodałem ServerName jako :

 
NameVirtualHost *:443 
    <VirtualHost *:443> 
     ServerAdmin [email protected] 
     SSLEngine On 
     ServerName www.OMITTED.dk 
0

Jeden krok naprzód, mój przypadek jest MSWindows stacji roboczej klienta i serwera CentOS z Apache.

Korzystając z Tortoise Subversion 1.6.16, zdaję sobie sprawę, że po wykonaniu "svn checkout https://OMITTED.dk/project", otrzymałem ten sam błąd uzgadniania SSL.

Co zrobiłem było

  1. aktualizacja c: \ windows \ system32 \ drivers \ etc \ hosts z "ip_address OMITTED.dk"
  2. aktualizować wpisy z katalogu projektu. Zmodyfikuj projekt/wpisy w pliku i zamień adres IP na OMITTED.dk.

Tak więc wypróbowałem polecenie: svn update path_to_project --non-interactive --trust-server-cert. Nadzieja będzie przydatna

Powiązane problemy