SSL negotiation failed with svn

I am running a server that accepts https requests. I have generated my own certificate. When going to the site in firefox I get the unknown certificate error, but that's fine. This (I think) indicates that port forwarding an开发者_运维技巧d such works.

I am trying to use svn with this. When using svn on the server (but using the external ip) it works. Again I get the certificate is unknown, but I don't care.

When using svn on mac OS X I get

SSL negotiation failed: SSL error code -1/1/336032856

I've found several posts on google about this, but they all say it's a bug with openssl version 0.9.8, and that using something higher should fix it.

I am currently using openssl 1.0.0c. I have no idea what's going wrong. I also checked the error log in httpd and nothing comes up.

Any ideas on this would really help.

Thanks

Upgrading from SVN 1.6.15 to 1.6.16 fix this issue for me.

I received the same error message when my Apache configuration was wrong - my ServerName parameter in httpd.conf did not match hostname in the self-signed certificate.

I started getting this error from older subversion clients (Tortoise 1.6.4 i think, and pysvn r1280) when our svn server had its Apache instance upgraded. It went from using OpenSSL 0.9.8n to 1.0.0d.

Tortoise got fixed by upgrading to 1.6.16 (uses OpenSSL 1.0.0d).

Fixing pysvn was a different story. The latest version (r1360) came bac kwith the same error. There didn't seem to be much info around apart from hints that OpenSLL might need upgrading. I tried copying in different versions of OpenSSL (libeay32.dll and ssleay32.dll) and here are the results:

• 0.9.8j (the existing DLL version, bundled with pysvn r1280) FAIL
• 0.9.8o (bundled with the latest pysvn, r1360) FAIL
• 0.9.8r (the latest in the 0.9.8 series) FAIL
• 1.0.0* (the 1.0 series is not binary compatible with pysvn) FAIL
• 0.9.8L (nabbed from CollabNet SVN 1.6.9 command line client) SUCCESS!

So whatever they fixed in release L got broken again soon after, or there's something special about CollabNet's OpenSSL binaries.

In my case it started happening after some certificates changes on the server side. I tried deleting the .subversion/ dir, updating openssl, openssh, svn, and nothing...

It got finally fixed when I replaced the url host name with the ip address of that host. In existing working copies was enough with:

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

Not sure if this is a bug or what, but it seems that the new certificates are not recognized and keeps using the old cached ones for a given host name.

I agree with the earlier answer by Lukas Cenovsky, that setting ServerName in the apache configuration fixes the problem.

In this link http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf it is said that the error originates from the SSL library.

The full error message(just to enable better google indexing) I receive is:

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

In the file /etc/apache2/sites-available/ssl (debian linux) I added the ServerName as:

NameVirtualHost *:443
  <VirtualHost *:443>
        ServerAdmin webmaster@localhost
        SSLEngine On
        ServerName www.OMITTED.dk

See what happens if you eliminate the SSL problem by adding your generated certificate to your client's trusted certificate store.

One step ahead, my case is a MSWindows Client workstation and a CentOs server with Apache.

Using Tortoise Subversion 1.6.16, I realise that after execute a "svn checkout https://OMITTED.dk/project", I got the same ssl handshake error.

What I did was

1. update c:\windows\system32\drivers\etc\hosts with "IP_address OMITTED.dk"
2. update the entries with the project directory. Edit the file project/entries and replace the IP_address by OMITTED.dk.

Thus I try the command : svn update path_to_project --non-interactive --trust-server-cert. Hope will be usefull