10

I'm having trouble accessing an svn repository due to an SSL handshake error. Here's the output I get

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

This started happening after the repository was moved to another server. A new security certificate was issued as well.

I've seen the issue raised here (Handshake failure with "SSL error code -1/1/336032856" on OS X 10.7) and read the faq, but my ssl version is 1.0.1c. I think this is a client side issue, since no other (linux) machines exhibit the problem. I've deleted my ~/.subversion folder and deleted in my keychain anything marked svn or ssl, but still no luck. My guess is there are still security keys stored somewhere that I don't know about. Any ideas?

Community
  • 1
  • 1
dmagree
  • 265
  • 1
  • 2
  • 10
  • Which version of `svn` are you using? Try `which svn` and `svn --version`. If it's the Apple-supplied one from Xcode, it's not using openssl 1.0.1c since that version is not shipped with OS X. – Ned Deily Feb 26 '13 at 00:00
  • which svn returns usr/bin/svn, and svn --version returns 1.6.17 – dmagree Feb 26 '13 at 03:02
  • That is undoubtedly the Apple-supplied version and installing a new version of openssl has no effect on it. So this appears to be the same problem as the issue you cite. – Ned Deily Feb 26 '13 at 06:02

5 Answers5

4

I had this error too when trying to check out a repository on a server using a self-signed certificate.

You have to meet 2 requirements:

  • the CN (Common Name) in the certificate should match the hostname you're using in the repo URL
  • the ServerName configured in the Virtual Host handling the request should match the URL too.

The latter could be enough.

I was using the default-ssl apache config from Debian which doesn't set any specific ServerName (so the main ServerName from the global Apache config is used). Accessing the repository through the real hostname of the server was working (you just get the "The certificate is not issued by a trusted authority" warning the first time you try to connect) but trying to access it through any other alias (even by its IP) failed with this error.

So the workaround here is to ask the server admin what's the real ServerName (it may be listed in the footer of a 404 error page) or ask him to set it accordingly.

Example:

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

Store it permanently and you're good to go!

Capsule
  • 6,118
  • 1
  • 20
  • 27
3

This can also happen due to TLS using SNI (https://en.wikipedia.org/wiki/Server_Name_Indication).

Given you are using Apache with something like this config

ServerName  my-server
ServerAlias another-name

And the client connects to your server using this URL

svn ls https://svn-server

When the Client uses SNI it will tell the server during the handshake 

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

The server only knows itself by the names "my-server" and "another-name", hence it will raise a TLS warning:

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

This warning leads to a handshake failure, as the client thinks something bad happened.

A solution would be to add the name the client uses to the server aliases

ServerAlias another-name svn-server

And do not forget to check that the SSL certificate's "Common Name" or aliases also matches the name the client uses.

fr00tyl00p
  • 327
  • 3
  • 10
2

Many thanks to Ned Deily, his comments were correct. The problem disappeared after I downloaded and built subversion 1.7.8 (http://subversion.apache.org/download/#recommended-release). I also had to download and build neon (http://www.webdav.org/neon/), to allow svn to recognize http and https address. Finally, I had to move the apple-supplied svn binaries to another folder to get the new version found (new version was installed to /usr/local/bin, while the apple-supplied version was installed in /usr/bin).

dmagree
  • 265
  • 1
  • 2
  • 10
1

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

This can happen when the hostname reported by the server does not the match hostname given in the SSL certificate. Make sure your server configuration uses correct values for ServerName and NameVirtualHost.

hustxxb
  • 31
  • 1
1

I received a similar error and it appeared that the cause was that the system clock was off (daylight savings had just passed, and the system clock was off by 1 hour).

James Wierzba
  • 16,176
  • 14
  • 79
  • 120