SVN, OSX10.7: Zawieszenie połączenia SSL nie powiodło się: kod błędu SSL -1/1/336032856

Question

Mam problemy z dostępem do repozytorium SVN z powodu błędu uzgadniania SSL. Oto dane wyjściowe, które dostaję:

$ 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) 

To zaczęło się dziać po przeniesieniu repozytorium na inny serwer. Wydano również nowy certyfikat bezpieczeństwa.

Widziałem problem podniesiony tutaj (Handshake failure with "SSL error code -1/1/336032856" on OS X 10.7) i przeczytaj FAQ, ale moja wersja SSL to 1.0.1c. Myślę, że jest to kwestia po stronie klienta, ponieważ żadne inne (Linux) maszyny nie wykazują problemu. Usunąłem swój folder ~/.subversion i usunąłem w moim pęku kluczy wszystko oznaczone svn lub ssl, ale wciąż nie było to szczęście. Domyślam się, że wciąż są klucze bezpieczeństwa przechowywane gdzieś, o czym nie wiem. Jakieś pomysły?

Answer 1

Wielkie dzięki dla Neda Deily'ego, jego uwagi były poprawne. Problem zniknął po pobraniu i zbudowaniu subversion 1.7.8 (http://subversion.apache.org/download/#recommended-release). Musiałem również pobrać i zbudować neon (http://www.webdav.org/neon/), aby umożliwić svn rozpoznanie adresu http i https. W końcu musiałem przenieść dostarczone pliki binarne svn do innego folderu, aby znaleźć nową wersję (nowa wersja została zainstalowana w/usr/local/bin, a wersja dostarczona przez Apple została zainstalowana w/usr/bin).

Answer 2

Ten błąd miałem również podczas próby sprawdzenia repozytorium na serwerze przy użyciu samopodpisanego certyfikatu.

Trzeba spełnić 2 warunki:

• CN (Common Name) w świadectwie powinna być zgodna z hosta używasz w adresie URL repo
• ServerName skonfigurowany w prowadzeniu wirtualnego hosta żądanie powinno również odpowiadać adresowi URL.

To ostatnie może wystarczyć.

Używałem domyślnej konfiguracji apache z Debiana, która nie ustawia żadnej konkretnej nazwy serwera (dlatego używana jest główna nazwa serwera z globalnej konfiguracji Apache). Uzyskanie dostępu do repozytorium za pośrednictwem prawdziwej nazwy hosta serwera działało (po pierwszym próbie połączenia pojawia się komunikat "Certyfikat nie jest wystawiony przez zaufany organ"), ale próbuje uzyskać do niego dostęp za pośrednictwem dowolnego innego aliasu (nawet przez jego IP) nie powiodło się z tym błędem.

W takim przypadku należy poprosić administratora serwera o rzeczywistą nazwę serwera (można go umieścić w stopce strony błędu 404) lub poprosić go o odpowiednie ustawienie.

Przykład:

$ 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? 

przechowywać go na stałe i jesteś dobry, aby przejść!

Answer 3

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

Może się to zdarzyć, gdy nazwa hosta zgłaszane przez serwer nie nazwę hosta mecz podaną w certyfikacie SSL. Upewnij się, że konfiguracja serwera używa poprawnych wartości dla Nazwa serwera i NameVirtualHost.

Answer 4

Może się to również zdarzyć z powodu TLS używającego SNI (https://en.wikipedia.org/wiki/Server_Name_Indication).

Biorąc używasz Apache coś takiego config

ServerName my-server 
ServerAlias another-name 

a klient łączy się z serwerem za pomocą tego adresu

svn ls https://svn-server 

gdy klient korzysta Sni powie to serwer podczas handshake

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

Serwer zna tylko nazwy "mój-serwer" "I«inna nazwa», stąd też podniesie ostrzeżenie TLS:

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

Ostrzeżenie to prowadzi do niewydolności Handshake, jako klient myśli coś złego się stało.

rozwiązanie byłoby dodać nazwę klient używa do aliasów serwera

ServerAlias another-name svn-server 

I nie zapomnij sprawdzić, że „Common Name” Certyfikat SSL lub aliasy pasuje również nazwa klienta używa.

Answer 5

Otrzymałem podobny błąd i okazało się, że przyczyną było wyłączenie zegara systemowego (właśnie minęły dni, a zegar systemowy był wyłączony o 1 godzinę).