Hi Bernd,
On Thu, Jul 25, 2013 at 5:56 PM, Lieven Govaerts <lgo_at_apache.org> wrote:
> Hi,
>
> On Thu, Jul 25, 2013 at 4:25 PM, Bernd May
> <bernd_at_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.
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: bernd_at_inet.tu-berlin.de
>> WWW: inet.tu-berlin.de
>>
Received on 2013-07-25 20:54:05 CEST