Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

After upgrading a Debian server from stable to testing, svn clients can no longer connect to the subversion server.

Our svn clients are required to connect using client certificates and the subversion server is hosted under Apache. Subversion was upgraded from 1.6.17 to 1.7.13. Apache2 was upgraded from 2.2.22 to 2.4.6.

The svn client receives the following error message when updating:

Updating '.':
svn: E175002: Unable to connect to a repository at URL 'https://myserver/svn/myproject/dev/trunk'
svn: E175002: OPTIONS of 'https://myserver/svn/myproject/dev/trunk': SSL handshake failed: SSL error: An unexpected TLS packet was received. (https://myserver)

On the Apache server, only one message appears and it is in other_vhosts_access.log:

myserver.localdomain:80 - - [06/Jan/2014:19:02:57 -0500] "\x16\x03" 400 0 "-" "-"

Here is the configuration of the subversion virtual directory:

<VirtualHost *:443>
   ServerName myservername
   SSLEngine On
   SSLCertificateFile      /etc/apache2/ssl/myservercert.crt
   SSLCertificateKeyFile   /etc/apache2/ssl/myservercert.key
   SSLCACertificateFile    /etc/apache2/ssl/myserver-CA.crt
   SSLVerifyClient require
   SSLVerifyDepth 10
   <Location /svn >
      SSLRequire %{SSL_CLIENT_S_DN_C} eq "XX" and %{SSL_CLIENT_S_DN_ST} eq "XX" and %{SSL_CLIENT_S_DN_O} eq "XX" and %{SSL_CLIENT_S_DN_OU} eq "XX"
      DAV svn
      SVNParentPath /root/subversion/root
      Require valid-user
      AuthType Basic
      AuthName "Subversion Repository"
      AuthUserFile /root/subversion/.apache-htpasswd
      AuthzSVNAccessFile /root/subversion/.apache-auth

Can anyone point me in the right direction to solve this problem? Thanks.

share|improve this question
up vote 5 down vote accepted

When upgrading Apache from 2.2 to 2.4, file links under sites-enabled must end with .conf where in the past they didn't require a specific file extension.

If your site configuration filename under sites-available does not have an extension .conf, then you may want to rename it, then run: a2ensite filename to add it to sites-enabled.

Example, if your site config file is called MySite:

cd /etc/apache2
rm sites-enabled/MySite
cd sites-available
mv MySite MySite.conf
a2ensite MySite
apache2ctl configtest
apache2ctl restart

So, the problem above was due to my site configuration not being picked up when the Apache2 service started.

share|improve this answer

I strongly suspect that Apache is answering for HTTP on port 443 rather than HTTPS. Connect to port 443 with TELNET and do a GET / and I suspect you'll get a response. If you do, that tells you that Apache is listening for plain ol' HTTP.

I'm not familiar with Debian configuration contrivances so I'm hard-pressed to tell you where to start looking. If you find that you're getting unencrypted HTTP on port 443 then it's likely that the server isn't loading mod_ssl for some reason.

share|improve this answer
<h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> Reason: You're speaking plain HTTP to an SSL-enabled server port.<br /> – Chris C. Jan 7 '14 at 1:44
Well, crap. My psychic powers have failed me on this one, then. – Evan Anderson Jan 7 '14 at 7:24

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.