Fixing connection issue for Subversion: “svn: E120171: Error running context: An error occurred during SSL communication”

Subversion (SVN) is a source control management tool that hosts code files where developers can checkout and collaborate with each other. However, git is still the most popular source control management tool, and many enterprises want to migrate from Subversion to git. One customer had a Subversion setup in a Windows server machine and a client setup in Red Hat Linux (RHEL) box, and the customer wanted to connect to Window’s Subversion from Red Hat Linux box so the migration to GitHub can be carried out.
First, to make sure that the client side (RHEL) can reach out to server side (Windows server), we had to check the connection. This can be done from the client side, but it really depends on what machine it is.
If this is a Linux/Mac client:
ping URL_TO_TESTIf this is a Windows client:
Test-NetConnection -Port SOME_PORT -ComputerName "URL_TO_TEST"where URL_TO_TEST is either the URL where the Subversion server is hosted or an IP address. SOME_PORT will be whatever the port it it trying to connect to.
In Windows, you can also trying this:
New-Object Net.Sockets.TcpClient URL_TO_TEST, SOME_PORTNow, in our case, it was verified that the client side can talk to the server side because some packets are coming back. What happened next was to test out Subversion connection with the following command:
svn ls URL_TO_SUBVERSION_TRUNKBut it was returnining errors like this:
svn: E170013: Unable to connect to a repository at URL 'URL_TO_SUBVERSION_TRUNK'
svn: E120171: Error running context: An error occurred during SSL communicationThis indicates that either:
- There is a problem with server side SSL certificate. For example, it got expired or wrong
- There is a problem making a handshake between the client side and server side with the SSL certificate
Typical troubleshootings steps are going to be like this:
- Verify in the server side that the certificate is valid and not expired
- Try to bypass certificate by “trusting it”
- Try to extract certificate from serverside and import in the client side
Verify in the server side that the certificate is valid and not expired
This involves the step of checking certificate from server side. The customer was using Visual SVN that is running on a Windows server, and the troubleshooting really depends on how the customer configured it.
Trying to bypass certificate by “trusting it”
For example, curl has an option to pass -k which can use insecure connection. For svn command, it should have an option --trust-server-cert , but it is possible that you don’t have that option depending on what svn client or what version of svn client it is. But typically, if you run a command like svn ls SUBVERSION_URL , it should ask you whether you want to trust.
Try to extract certificate from server side and import in the client side
This is probably most difficult step. You can try to open up a browser and download the certificate and share with a client side. Or, you need to generate with something like openssl and share with a client side.
In our case, though, what happened was that the TLS version in the server side was not compatible with the TLS connection in client side. Here was a solution that worked.
Step 1: Find out where SSL config file is located
This command should show the directory where our openssl.conf file is.
openssl version -d
Once you discover that file, try to open it with a text editor like VIM. For example, vim /etc/pki/openssl.conf
Step 2: Modify the openssl.conf file
Modify the files by making the following changes:
At the top of file, make sure it has this line or add it:
openssl_conf = default_confAt the end of file, make sure it has these lines or add them:
[ default_conf ] ssl_conf = ssl_sect [ssl_sect] system_default = ssl_default_sect [ssl_default_sect] MinProtocol = TLSv1 CipherString = DEFAULT:@SECLEVEL=1
Then, one more important step! You need to export this variable with a following command:
export OPENSSL_CONF=PATH_TO_URL_OPENSSL_CONF_FILEOr, you can add the path to your BASH SHELL or ZSHELL.
Then, when you try that svn ls or Subversion commands, it should work.






