5

I am trying to checkout from my team's svn server. It requires client side authentication. I'm running Ubuntu 10.04.

Here's what I get:

$ svn checkout https://myproject.myserver.org/svn/project/
svn: OPTIONS of 'https://myproject.myserver.org/svn/project/': Could not read status line: SSL alert received: Handshake failed (https://myproject.myserver.org)

Has anybody else seen a similar problem?

5
  • I believe you have to supply SVN with an appropriate argument for client certificate. Can't find information on that... Dec 27, 2010 at 16:01
  • Maybe this helps: sgi.posterous.com/sslv3-alert-handshake-failure-with-svn-client
    – moinudin
    Dec 27, 2010 at 16:04
  • no luck with the link, already setup like that :(
    – themaestro
    Dec 27, 2010 at 17:38
  • I had the same problem. It turned out, I hadn't add ServerName in virtualhost definiton in Apache. Once I added ServerName myproject.myserver.org for subversion vhost configuration, problem resolved.
    – kokeksibir
    Aug 6, 2013 at 13:00
  • Posterus is no more. Perhaps that link got archived by the payback machine: web.archive.org Apr 24, 2018 at 0:04

3 Answers 3

3

Is it still not working? Time to break out the big guns. First, try to browse to it from the same server, see if you get the expected folder listing. If it fails, you might get a better reason, and if not, fire up OpenSSL instead:

openssl s_client -connect myproject.myserver.org:443

will give you a log of information about each step of the handshake, and the --debug option will show even more detail. It'll complain about having an invalid cert, bad time, or only outdated algorithms.

Of course, make sure you can even ping it and that https isn't firewalled off for some reason.

1
  • 4
    Just one hyphen on the -connect option.
    – Mojo
    Jun 27, 2011 at 15:01
2

Maybe the problem is that you are using a new version of Collabnet's client as in http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=364471 ?

0

Check the user's path spec PATH environment variable in ~/.bashrc (for that user).

If this one is messed up, quite some commands cannot be called by their common name.

Most likely, it just cannot find one binary executable - or the private key in ~/.ssh

... for a quick check (logged in as the user, which is not working):

echo $PATH
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .