SVN, OSX10.7: handshake SSL non riuscito: codice errore SSL -1/1/336032856

Question

Ho problemi ad accedere a un repository svn a causa di un errore di handshake SSL. Ecco l'output che ottengo

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

Questo ha iniziato a verificarsi dopo che il repository è stato spostato su un altro server. È stato anche emesso un nuovo certificato di sicurezza.

Ho visto il problema sollevato qui (Handshake failure with "SSL error code -1/1/336032856" on OS X 10.7) e leggere la faq, ma la mia versione ssl è 1.0.1c. Penso che questo sia un problema lato client, poiché nessun'altra macchina (linux) mostra il problema. Ho cancellato la mia cartella ~/.subversion e cancellato nel mio portachiavi qualsiasi cosa contrassegnata svn o ssl, ma ancora senza fortuna. La mia ipotesi è che ci siano ancora delle chiavi di sicurezza immagazzinate da qualche parte che non conosco. Qualche idea?

Answer 1

Mille grazie a Ned Deily, i suoi commenti erano corretti. Il problema è scomparso dopo aver scaricato e creato la subversion 1.7.8 (http://subversion.apache.org/download/#recommended-release). Ho anche dovuto scaricare e compilare neon (http://www.webdav.org/neon/), per consentire a svn di riconoscere l'indirizzo http e https. Infine, ho dovuto spostare i binari svn forniti da Apple in un'altra cartella per ottenere la nuova versione trovata (la nuova versione è stata installata su/usr/local/bin, mentre la versione fornita da Apple è stata installata in/usr/bin).

Answer 2

Ho riscontrato questo errore anche durante il tentativo di estrarre un repository su un server utilizzando un certificato autofirmato.

hai bisogno di 2 requisiti:

• il CN (Common Name) nel certificato deve corrispondere al nome host che si sta utilizzando l'URL repo
• il ServerName configurato nella gestione della Virtual Host del la richiesta deve corrispondere anche all'URL.

Quest'ultimo potrebbe essere sufficiente.

Stavo usando la configurazione di apache default-ssl da Debian che non imposta alcun ServerName specifico (quindi viene utilizzato il ServerName principale dalla configurazione globale di Apache). L'accesso al repository tramite il vero nome host del server funzionava (si ottiene semplicemente il messaggio "Il certificato non viene emesso da un'autorità attendibile" all'avvio della prima volta che si tenta di connettersi) ma si tenta di accedervi tramite qualsiasi altro alias (anche dal relativo IP) non riuscito con questo errore.

Quindi la soluzione qui è chiedere al server admin qual è il ServerName reale (potrebbe essere elencato nel footer di una pagina di errore 404) o chiedergli di impostarlo di conseguenza.

Esempio:

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

Conservarlo in modo permanente e siete pronti per partire!

Answer 3

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

Questo può accadere quando il nome host riportato dal server non fa la partita hostname dato nel certificato SSL. Assicurarsi che la configurazione del server utilizzi i valori corretti per ServerName e NomeVirtualHost.

Answer 4

Ciò può verificarsi anche a causa di TLS che utilizza SNI (https://en.wikipedia.org/wiki/Server_Name_Indication).

Dato che si sta utilizzando Apache con qualcosa di simile configurazione

ServerName my-server 
ServerAlias another-name 

E il client si connette al server tramite questo URL

svn ls https://svn-server 

Se il client utilizza SNI vi dirà il server durante la handshake

Il server conosce solo se stesso con i nomi "my-server" "E 'un altro nome', quindi si alzerà un avvertimento TLS:

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

Questo avvertimento porta ad un fallimento stretta di mano, come il cliente pensa qualcosa di brutto è accaduto.

Una soluzione potrebbe essere quella di aggiungere il nome utilizzato dal client per gli alias del server

ServerAlias another-name svn-server 

E non dimenticate di controllare che il certificato SSL "Nome comune" o pseudonimi partite anche il nome del cliente utilizza.

Answer 5

Ho ricevuto un errore simile ed è emerso che la causa era che l'orologio di sistema era spento (l'ora legale era appena passata e l'orologio di sistema era spento di 1 ora).