SVN checkout using TortoiseSVN causes "An error occurred during SSL communication" to appear whenever client certificates are required in conjunction with our new server, if the client certificate is already present in the local Windows certificate store. The client certificates are issued by a local CA, the CA certificate is present in the local Windows certificate store, and the CA certificate has not expired.
The problem appears to be 100% reproducible when attempting to checkout from the new server when the client certificate is present in the local Windows certificate store. The problem was not observed before attempting to use the new server. That is, SVN checkout using TortoiseSVN was working fine with the old server with client certificates present in the local Windows certificate store.
Question: Is there any way to modify how the new server is configured, or how clients are configured, to eliminate the problem, without bypassing client certificate authentication?
We used svnadmin dump and svnadmin load to migrate 33 Subversion repositories from one server to another. The directory structure is /Dirname/Reponame1/SVN, /Dirname/Reponame2/SVN, and so forth. This problem was not observed with the old server--only with the new one.
Both hosts are Linux systems running Apache.
Both hosts require client certificates and login via Apache Basic authentication.
The client certificates are issued by a CA that is trusted locally by virtue of the CA certificate loaded in the local Windows certificate store.
Using Tortoise SVN, whenever users attempt to run SVN Checkout, or connect to the new server, they see
"Error: Unable to connect to a repository at URL 'https://...'" and "Error running context: An error occurred during SSL communication."
The action creates the local folder, but fails to checkout any content.
When client certificate authentication is bypassed by commenting out the "SSLVerifyClient require" directive, the error is not observed.
It is currently a business requirement to enforce both client certificate authentication and login (Apache Basic Authentication).
When the client certificate is removed from the local Windows certificate store, the error does not occur.
As a short-term workaround, browser-based access to the new server is happening by importing the CA certificate and client certificate into Firefox's certificate store.
We're trying to find a way back to supporting browser-based access to the SVN repos on the new server by way of Chrome and MS Edge. For this to happen, the client certificate must be present in the local Windows certificate store. But when the client certificate is present in the local Windows certificate store, SVN Checkout referencing the new server produces the error.
Client systems are running Windows 10 TortoiseSVN 22.214.171.124085 - 64 bit, 2021/02/09 16:17:02 ipv6 enabled Subversion 1.14.1, -release apr 1.6.5 serf 1.3.9 OpenSSL 1.1.1i 8 Dec 2020 zlib 1.2.11 SQLite 3.29.0
Old Server cat /etc/redhat-release CentOS release 6.10 (Final)
rpm -qa|grep subv subversion-1.6.11-15.el6_7.x86_64
Repositories accessed via apache using HTTPS. httpd -v Server version: Apache/2.2.15 (Unix) Server built: Jun 19 2018 15:45:13
<Location /svn/Generic> SSLRequireSSL Dav On DAV svn SVNPath /Projects/Generic/SVN AuthType Basic AuthName "Generic" AuthUserFile /etc/httpd/conf/htpasswd AuthGroupFile /etc/httpd/conf/Groups Require group W2 Contractors SetHandler mod_python
The ssl.conf file contains SSLProtocol all -SSLv2 -SSLv3 SSLVerifyClient require SSLVerifyDepth 1
Powered by Subversion version 1.6.11 (r934486).
New Server Debian GNU/Linux 10 (buster)
apache2 -v Server version: Apache/2.4.38 (Debian) Server built: 2020-08-25T20:08:29
<Location /svn/Generic> SSLRequireSSL Dav On DAV svn SVNPath /Projects/Generic/SVN AuthType Basic AuthName "Generic" AuthUserFile /etc/apache2/htpasswd AuthGroupFile /etc/apache2/Groups Require group W2 Contractors SetHandler mod_python
The ssl.conf file contains SSLVerifyClient require SSLVerifyDepth 1
Powered by Apache Subversion version 1.10.4 (r1850624).
The ssl.conf file originally contained this, and the problem was present. SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
In an effort to make both servers as similar as possible, the SSLProtocol directive was changed to this: SSLProtocol all -SSLv3 +TLSv1.2
According to packet capture of traffic analyzed with Wireshark, packet protocol of new server traffic is listed at the top level as TLSv1.3, but the Server Hello, Change Cipher Spec, Application Data packet and packets that follow it list Version: TLS 1.2 (0x0303) inside the record layer.
Changing the SSLProtocol had no observable effect on the problem.