Hi Philip,
this solved it!
Using "openssl s_client" as you described it reported:
error setting certificate
140258270184704:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca
md too weak:../ssl/ssl_rsa.c:303:
So we created new certificates with sha256 (default in openssl 1.1)
instead of md5.
This solved the problem.
Maybe a hint in the svn release notes could be useful, since the svn
error messages are not very useful.
Thanks a lot!
And sorry for bothering on the dev list. I should have posted to user.
Also thanks for your other SNI and DEFLATE tips!
Cheers,
Folker
On 2018-07-31 17:04, Philip Martin wrote:
> Folker Schamel <schamel23_at_spinor.com> writes:
>
>> After upgrading, Subversion SSL connections with "SSLVerifyClient
>> require" seem to be broken.
>>
>> Broken: SVN Client 1.9.5, Serf 1.3.9-3, Server "SSLVerifyClient require"
>> Works: SVN Client 1.9.5, Serf 1.3.9-3, Server "SSLVerifyClient off"
>> Works: SVN Client 1.9.5, Serf 1.3.8-1, Server "SSLVerifyClient require"
> I can use client certificates on my Debian machine using 1.3.9-3 with
> "SSLVerifyClient require" so it does work in some configurations.
>
> I think that one of the changes between 1.3.8-1 and 1.3.9-3 on Debian is
> that openssl was upgraded from 1.0 to 1.1. That's a major upgrade and
> some sort of openssl incompatibility may be the problem.
>
> You could use the openssl binary to debug the ssl connection. First you
> need to convert Subversion's client certificate from pkcs12 to pem:
>
> openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem
>
> then you can use:
>
> openssl s_client -connect example.com:443 -servername example.com -cert cert.pem
>
> If you are using ssl-authority-files in .subversion/servers to verify
> the server cert you can get s_client to do the same with the additional
> parameter:
>
> openssl s_client ... -CAfile path/to/authority.pem
>
> The s_client output may indicate what problem is occurring.
>
>> For the broken setup, the client reports:
>> svn: E120171: Error running context: An error occurred during SSL communication
>> And the server Apache log reports:
>> ssl_engine_io.c(1308): (70014)End of file found: [client xxxxx:xxxxx]
>> AH02007: SSL handshake interrupted by system [Hint: Stop button
>> pressed in browser?!]
>>
>> Using the latest TortoiseSVN client reports the same problem,
>> presumably the same cause.
> TortoiseSVN is probably built with openssl 1.1 as well.
>
>> [Tue Jul 31 15:30:43.886183 2018] [ssl:debug] [pid xxxxx:tid xxxxx]
>> ssl_engine_kernel.c(2122): [client xxxxx:xxxxx] AH02044: No matching
>> SSL virtual host for servername xxxxx found (using default/first
>> virtual host)
> That looks like SNI isn't working but I don't know if that is relevant
> for your problem. Some sort of vhost/servername problem in the apache
> config?
>
>> <Location /svn>
>> SetOutputFilter DEFLATE
>> SetInputFilter DEFLATE
>> Header append Vary User-Agent env=!dont-vary
>> </Location>
> DEFLATE combined with mod_dav_svn had problems in the past but I think
> they are all fixed. Note that when mod_dav_svn and Subversion clients
> communicate they do so using compressed deltas, so adding DEFLATE
> doesn't result in very much additional compression. The combination has
> a more significant compression effect if users are using non-Subversion
> tools: web browsers, curl, etc. This is probably not relevant to your
> problem.
>
Received on 2018-07-31 17:42:20 CEST