Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Within our network we have a server which runs the Subversion Edge server. I have configured Edge to use SSL on port 8443. We have been happily connecting to SVN via clients such as Tortoise SVN, both from within the network and remotely via the public IP address. The SSL certificate that Edge is using is just the one it has generated itself i.e. self signed.

We have TeamCity installed within our network, and it is able to connect to the Edge SVN repository without any problems.

We also have an installation of TeamCity at an external location, however at the external location TeamCity will not connect to SVN, it responds with an error:

We know that the network at the external location uses a Proxy, but we have modified the servers file specifying the Proxy details, i.e.:

[global] http-proxy-exceptions = localhost http-proxy-host = ourproxy http-proxy-port = 8080

Before we amended the proxy settings, when we tried to connect to the SVN repository via TeamCity, the error was:

jetbrains.buildServer.vcs.VcsRootVcsException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/svn/TheWebsite

After we amended the proxy settings the error was:

jetbrains.buildServer.vcs.VcsRootVcsException: svn: E175002: handshake alert: unrecognized_name svn: E175002: OPTIONS request failed on '/svn/TheWebsite'

First of all I thought the error might indicate something to do with authorization. So, I turned SSL off on our SVN Edge Server, and the external TeamCity was able to connect via HTTP without any problems. This leads me to believe, rightly or wrongly, that it is something to do with the SSL certificate. The SSL certificate on our SVN Edge server is self signed and issued to svnedge.collab.net, which of course does not match our external URL.

So my question is, does anyone know from experience whether the "handshake alert" error is because a) the proxy is stripping out the credentials or b) teamcity is complaining that the common name in the certification (svnedge.collab.net) does not match the URL of our repo? This article, http://www.webapper.com/blog/index.php/2007/02/09/troubleshooting-javaxnetsslsslhandshakeexception/, seems to suggest the mismatch of common name would throw this error.

Any help or advice would be greatly appreciated.

Regards, dotdev

share|improve this question

2 Answers 2

I resolved this issue after a Java upgrade on our TeamCity instance by setting the jsse.enableSNIExtension property based on a the top answer given to http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0

The correct way to do so will depend on the version of TC you're running, as documented at http://confluence.jetbrains.com/display/TCD8/Configuring+TeamCity+Server+Startup+Properties#ConfiguringTeamCityServerStartupProperties-ServerisRunViaShellScript

share|improve this answer

I had a similar issue and jsse.enableSNIExtension=false didnt solve it. The problem was much simpler:

my svn passwort, hat several special character, which apparently were misinterpreden by the browse, I assume. Anyway, changing the passwort to one only with normal letters and numbers, solved the issue

share|improve this answer

Your Answer

 
discard

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.