How to solve svn error: E175002: SSL handshake failed: 'Remote host closed connection during hand'?

[Francis Vittini]

I'm currently testing the integration between JIRA 6.4.12 with Subversion.  I'm using the JIRA Subversion Plugin v2.1.2 as a solution to switch to as we will have to stop using Fisheye 3.2.5 once we upgrade to JIRA 7 due to JIRA 7 dropping support for integration to Fisheye 3.2.

Whenever i try to add a SVN repository that is hosted on a SVN server using SSL or HTTPS, i get the below error on the JIRA log file and the repository is not added.  This behavior doesn't happens for repositories hosted on an SVN server that is not using SSL or HTTPS.  Below is the complete error thread:

2017-11-06 15:15:27,712 http-apr-8444-exec-8 ERROR s2185000 915x307x1 fxeowb 172.23.35.98,172.20.212.242 /secure/AddSubversionRepository.jspa [plugin.ext.subversion.SubversionManagerImpl] Connection to Subversion repository https://sduvvrwm100.dev.ib.tor.scotiabank.com/svn/HTIAN_TEST/ failed: org.tmatesoft.svn.core.SVNException: svn: E175002: SSL handshake failed: 'Remote host closed connection during handshake'
org.tmatesoft.svn.core.SVNException: svn: E175002: SSL handshake failed: 'Remote host closed connection during handshake'
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:529)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:398)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:863)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:699)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:100)
    at com.atlassian.jira.plugin.ext.subversion.SubversionManagerImpl.activate(SubversionManagerImpl.java:243)
    at com.atlassian.jira.plugin.ext.subversion.SubversionManagerImpl.setup(SubversionManagerImpl.java:81)
    at com.atlassian.jira.plugin.ext.subversion.SubversionManagerImpl.<init>(SubversionManagerImpl.java:52)
    at com.atlassian.jira.plugin.ext.subversion.MultipleSubversionRepositoryManagerImpl.createSubversionManager(MultipleSubversionRepositoryManagerImpl.java:212)
    at com.atlassian.jira.plugin.ext.subversion.MultipleSubversionRepositoryManagerImpl.createRepository(MultipleSubversionRepositoryManagerImpl.java:198)
    at com.atlassian.jira.plugin.ext.subversion.action.AddSubversionRepositoryAction.doExecute(AddSubversionRepositoryAction.java:189)  <+1> (ActionSupport.java:165)
    at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:88)  <+7> (DefaultInterceptorChain.java:39) (NestedInterceptorChain.java:31) (ChainedInterceptor.java:16) (DefaultInterceptorChain.java:35) (GenericDispatcher.java:225) (GenericDispatcher.java:154) (JiraWebworkActionDispatcher.java:152)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)  <+2> (ApplicationFilterChain.java:303) (ApplicationFilterChain.java:208)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)  <+14> (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (ChainedFilterStepRunner.java:87) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (XContentTypeOptionsNoSniffFilter.java:22) (AbstractHttpFilter.java:31) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (HeaderSanitisingFilter.java:44) (ApplicationFilterChain.java:241) (ApplicationFilterChain.java:208) (IteratingFilterChain.java:46) (DelegatingPluginFilter.java:70)
    at com.atlassian.jira.onboarding.postsetup.ui.PostSetupAnnouncementsFilter.doFilter(PostSetupAnnouncementsFilter.java:61)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
    at com.atlassian.jira.tzdetect.IncludeResourcesFilter.doFilter(IncludeResourcesFilter.java:40)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
    at com.atlassian.jira.baseurl.IncludeResourcesFilter.doFilter(IncludeResourcesFilter.java:38)  <+8> (AbstractHttpFilter.java:31) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70) (ContextFilter.java:25) (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
    at com.atlassian.greenhopper.jira.filters.ClassicBoardRouter.doFilter(ClassicBoardRouter.java:59)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
    at com.atlassian.mywork.client.filter.ServingRequestsFilter.doFilter(ServingRequestsFilter.java:37)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
    at com.atlassian.prettyurls.filter.PrettyUrlsSiteMeshFixupFilter.doFilter(PrettyUrlsSiteMeshFixupFilter.java:36)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
    at com.atlassian.prettyurls.filter.PrettyUrlsDispatcherFilter.doFilter(PrettyUrlsDispatcherFilter.java:60)  <+3> (DelegatingPluginFilter.java:78) (IteratingFilterChain.java:42) (DelegatingPluginFilter.java:70)
   

I asked the team that support the SVN server that uses the HTTPS to send me their SSL Certificate, and i added it to my JIRA java key store, but still get the same error.

Has anyone gone through this issue before?

[Nic Brough -Adaptavist- · Accepted solution]

The usual culprit for this is that there's something wrong with the installation of the certificate that stops Java presenting something to Subversion that lets it get past the SSL handshake (note, it's usually NOT the certificate itself!)

Sometimes, it's the key chain on the server not matching the certificate, but when it's not that, the other time I've seen it is when Java is trying the various protocols available and choosing one that the target server thinks is compromised or invalid.

Try turning off the old broken TLS protocols - add this to your setenv.sh and restart Jira.

-Dhttps.protocols=TLSv1.1,TLSv1.2

[Francis Vittini]

Hi Nic,  Thanks for your response.

I tried your recommendation, but it didn't work. 

I think that the problem may be that as my JIRA server is also running under HTTPS, the SVN server I'm trying to connect to also need to have my JIRA servers SSL Certificate added to their java cacerts file. 

I'll ask them to add my SSL certificate and see what happens.  I'll post back if that works.

[Nic Brough -Adaptavist-]

Yes, that was the next step, to confirm the certificates are valid.

There's a utility called sslpoke which is really helpful because you can try remote urls with various certificates very quickly.

[Francis Vittini]

Hi Nic,

The issue is solved.  In addition to add that SVN servers' SSL certificate on my JAVA keystore, I also had to add that SVN server's FQDN/IP to the -Dhttp.nonProxyHosts list on my JIRA JVM parameters.

After I did that I was able to Add repositories from that SVN Server.

Thanks for your tips though.