On Thu, Jul 25, 2013 at 8:53 PM, Lieven Govaerts <l...@apache.org> wrote: > Hi Bernd, > > On Thu, Jul 25, 2013 at 5:56 PM, Lieven Govaerts <l...@apache.org> wrote: >> Hi, >> >> On Thu, Jul 25, 2013 at 4:25 PM, Bernd May >> <be...@net.t-labs.tu-berlin.de> wrote: >>> Hello, >>> >>> I am experiencing re-negotiation issues namely connection closed when >>> trying to use a subversion client >=1.8 against an svn server running >>> >>> Debian Wheezy >>> apache 2.2.22 >>> libapache 1.8.1 >>> subversion 1.8.1 >>> openssl 1.0.1e >>> >>> with ssl client auth. >>> >>> I have now spent about 4 hours of searching through old ssl client auth >>> errors in the openssl issues, subversion maillinglist and tried the >>> following combinations of client libraries and binaries against the >>> server mentioned above: >>> >>> * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1 >>> * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e >>> >>> Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive >>> the following error on the client side, regardless of the openssl version: >>> >>> svn: E120108: Unable to connect to a repository at URL >>> 'https://example.com/svn/myrepo' >>> svn: E120108: Error running context: The server unexpectedly closed the >>> connection. >>> >>> Disabling the 'SSLVerifyClient Require' directive yields a successful >>> listing of the svn content, so this really appears to be related to >>> client auth. >>> Using an svn client with libneon also yields a successful repository >>> listing so this points quite directly at libserf. > > [..] > >> >> Enabling logging in serf will probably give you more detailed info on >> the failure on the client side. >> Logging can be activated by setting these flags in serf_private.h and >> then rebuilding serf: >> #define SSL_VERBOSE 1 >> #define CONN_VERBOSE 1 >> #define SOCK_VERBOSE 1 >> >> >> If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but >> the info you'll need will be at the end. Alternatively you can upgrade >> to serf 1.3.0 where ssl logging has been cleaned up. You can send the >> log files to the list or to me privately, I'll have a look. > > > the logs you sent (via private mail) did contain all the requested > info, but it's not enough to analyse the root cause. > > However, I can reproduce this by accessing my test repo with svn trunk > and serf trunk over https, with the "SSLVerifyClient Require" line > added to the server config. My server setup does not require client > certificates, so that is not a factor here.
This last sentence doesn't make a lot of sense, it doesn't work because I hadn't configured my client certificate. I still can't get it to work with a valid client certificate matching the server certs, so need to look further. L. > Would you mind summarising this problem in a ticket in the serf issue > tracker at https://code.google.com/p/serf/issues/list ? I'll see what > I can find. > > Lieven > >>> -- >>> Technische Universität Berlin - FGINET >>> >>> Bernd May >>> >>> System Administration >>> Sekr. TEL 16 >>> Ernst-Reuter-Platz 7 >>> 10587 BERLIN >>> GERMANY >>> >>> Mobile: 0160/90257737 >>> E-Mail: be...@inet.tu-berlin.de >>> WWW: inet.tu-berlin.de >>>