Versions of subversion which are using serf can not deal with certificate authentication

[GoogleCodeExporter]

What steps will reproduce the problem?
1. use "svn co" on debian 8.1   (uses serf 1.8.3 and svn 1.8.10)
2. use "svn co" on opensuse 13.2 (uses serf 1.8.3 and svn 1.8.13) 
3. use "svn co" 0.9.0 and serf 1.3.8
4. use "svn co" 0.9.0 and serf 2.0.0 

What is the expected output? What do you see instead?
For serf 1.8.3 I see:
I expect the checkout of a svn tree. Instead it will give an error:
svn: E120171: Error retrieving REPORT: An error occurred during SSL 
communication
with debug enabled (svn 0.9.0):
subversion/svn/checkout-cmd.c:175,
subversion/libsvn_client/checkout.c:226,
subversion/libsvn_client/checkout.c:193,
subversion/libsvn_client/update.c:668,
subversion/libsvn_client/update.c:508,
subversion/libsvn_wc/adm_crawler.c:859,
subversion/libsvn_ra_serf/update.c:2694,
subversion/libsvn_ra_serf/update.c:2684,
subversion/libsvn_ra_serf/update.c:2616,
subversion/libsvn_ra_serf/util.c:914: (apr_err=120171)
svn: E120171: Error running context: An error occurred during SSL communication

For serf 2.0.0 nothing really works, certificate credentials are not read and 
after some time I get:
subversion/svn/info-cmd.c:981,
subversion/libsvn_client/info.c:390,
subversion/libsvn_client/ra.c:547,
subversion/libsvn_client/ra.c:424,
subversion/libsvn_ra/ra_loader.c:395: (apr_err=SVN_ERR_RA_CANNOT_CREATE_SESSION)
svn: E170013: Unable to connect to a repository at URL 
'https://prace.osd.surfsara.nl/svn/trunk/pracewp6/AAA/LDAP_Check'
subversion/libsvn_ra_serf/serf.c:609,
subversion/libsvn_ra_serf/options.c:517,
subversion/libsvn_ra_serf/util.c:988,
subversion/libsvn_ra_serf/util.c:937,
subversion/libsvn_ra_serf/util.c:914: (apr_err=120108)
svn: E120108: Error running context: The server unexpectedly closed the 
connection.

What version of the product are you using? On what operating system?
See above

Please provide any additional information below.
Older versions of subversion which are using neon instead of serf are working 
correct. 

Original issue reported on code.google.com by srrbv...@gmail.com on 12 Aug 2015 at 1:28

[GoogleCodeExporter]

There is a typo regarding the svn version. release 0.9.0 has to be replaced 
with 1.9.0. 

Original comment by srrbv...@gmail.com on 12 Aug 2015 at 1:45

[GoogleCodeExporter]

Looks like a server-side issue to me.

https://prace.osd.surfsara.nl/asd/  -> SSL okay
https://prace.osd.surfsara.nl/svn/  -> ssl_error_handshake_failure_alert
https://prace.osd.surfsara.nl/trac/ -> ssl_error_handshake_failure_alert

$ wget https://prace.osd.surfsara.nl/
--2015-08-12 16:22:44--  https://prace.osd.surfsara.nl/
Resolving prace.osd.surfsara.nl (prace.osd.surfsara.nl)... 145.100.12.232
Connecting to prace.osd.surfsara.nl 
(prace.osd.surfsara.nl)|145.100.12.232|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://prace.osd.surfsara.nl/trac [following]
--2015-08-12 16:22:44--  https://prace.osd.surfsara.nl/trac
Reusing existing connection to prace.osd.surfsara.nl:443.
HTTP request sent, awaiting response... No data received.
Retrying.

(no data)

Original comment by andreas.stieger@gmx.de on 12 Aug 2015 at 2:23

• Changed state: Invalid

[GoogleCodeExporter]

Your server triggers a renegotiation immediately after the initial handshake, 
to ask the client for a certificate.

OpenSSL has a known bug where renegotiation fails over connections using 
HTTP/1.1 pipelining, the only mode svn+serf supports.

Serf trunk is trying to work around that bug. When it encounters a 
renegotiation request from the server, it resets the connection and disables 
HTTP pipelining for a new connection. Obviously that mechanism fails with your 
server. At least it explains the difference you see between serf 1.3.x and serf 
trunk.

Some debugging is needed to figure out why trunk isn't working.

Original comment by lieven.govaerts@gmail.com on 12 Aug 2015 at 8:09

• Changed state: Accepted

[GoogleCodeExporter]

Could you try your test again with serf trunk@2500 ?

This should fix the workaround we introduced to handle renegotiation correctly.

I've tested by connecting to your server. Serf asks for a client certificate 
and will send the one I provide, but obviously I have no valid certificate for 
your server so the connection breaks off.

Lieven

Original comment by lieven.govaerts@gmail.com on 15 Aug 2015 at 12:26

[GoogleCodeExporter]

Works like a charm! Subversion 1.9.0 with serf 1.3.8 always stopped after the 
checkout of some directories. But with serf 2.0 everything works. I can 
checkout and update the svn repository. Thank you very much. 

Cheers,
Rob

Original comment by srrbv...@gmail.com on 17 Aug 2015 at 6:38

[GoogleCodeExporter]

Thanks for the feedback Rob, good to know that this issue is fixed!
The fix will be included in the 1.4.0 release.

Original comment by lieven.govaerts@gmail.com on 19 Aug 2015 at 6:48

• Changed state: Fixed