Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
svn: OPTIONS of '': Could not read status line: SSL alert received: Handshake failed (

Has anybody else seen a similar problem?

share|improve this question

migrated from Dec 28 '10 at 9:54

This question came from our site for professional and enthusiast programmers.

I believe you have to supply SVN with an appropriate argument for client certificate. Can't find information on that... – usr-local-ΕΨΗΕΛΩΝ Dec 27 '10 at 16:01
Maybe this helps: – marcog Dec 27 '10 at 16:04
no luck with the link, already setup like that :( – themaestro Dec 27 '10 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 for subversion vhost configuration, problem resolved. – kokeksibir Aug 6 '13 at 13:00

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

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.

share|improve this answer
Just one hyphen on the -connect option. – Mojo Jun 27 '11 at 15:01

Maybe the problem is that you are using a new version of Collabnet's client as in ?

share|improve this answer

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
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.