2

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 127.0.0.1 - - [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 >
      SSLRequireSSL
      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
   </Location>
</VirtualHost>

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

Improve this question

2 Answers 2

Reset to default
6

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.

Improve this answer
3

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.

Improve this answer
2
  • <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, 2014 at 1:44
  • Well, crap. My psychic powers have failed me on this one, then.
    – Evan Anderson
    Jan 7, 2014 at 7:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .