2 votes

Erreur SSL avec subversion après la mise à niveau d'apache de 2.2 à 2.4

Après avoir mis à niveau un serveur Debian de stable à testing, les clients svn ne peuvent plus se connecter au serveur subversion.

Nos clients svn doivent se connecter en utilisant des certificats clients et le serveur subversion est hébergé sous Apache. Subversion a été mis à jour de 1.6.17 à 1.7.13. Apache2 a été mis à jour de 2.2.22 à 2.4.6.

Le client svn reçoit le message d'erreur suivant lors de la mise à jour :

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)

Sur le serveur Apache, un seul message apparaît et il se trouve dans other_vhosts_access.log :

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

Voici la configuration du répertoire virtuel de subversion :

<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>

Quelqu'un peut-il m'indiquer la bonne direction à suivre pour résoudre ce problème ? Merci.

6voto

Chris C. Points 305

Lors de la mise à jour d'Apache de la version 2.2 à la version 2.4, les liens de fichiers sous sites-enabled doivent se terminer par .conf alors qu'auparavant ils ne nécessitaient pas d'extension de fichier spécifique.

Si le nom du fichier de configuration de votre site sous sites-available n'a pas d'extension .conf, vous pouvez le renommer, puis exécuter : a2ensite nom de fichier pour l'ajouter à sites-enabled.

Par exemple, si le fichier de configuration de votre site s'appelle MySite :

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

Donc, le problème ci-dessus était dû au fait que la configuration de mon site n'était pas prise en compte au démarrage du service Apache2.

3voto

Evan Anderson Points 140581

Je soupçonne fortement qu'Apache répond pour HTTP sur le port 443 plutôt que pour HTTPS. Connectez-vous au port 443 avec TELNET et faites un GET / et je pense que vous obtiendrez une réponse. Si c'est le cas, cela signifie qu'Apache écoute le bon vieux HTTP.

Je ne suis pas familier avec les artifices de configuration de Debian et je suis donc bien en peine de vous dire où commencer à chercher. Si vous obtenez du HTTP non crypté sur le port 443, il est probable que le serveur ne charge pas mod_ssl pour une raison quelconque.

0 votes

<h1>Mauvaise requête</h1> <p>Votre navigateur a envoyé une requête que ce serveur n'a pas pu comprendre.<br />Raison : vous parlez en HTTP simple à un port de serveur activé par SSL.<br />

0 votes

Eh bien, merde. Mes pouvoirs psychiques m'ont fait défaut sur ce coup-là, alors.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X