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 <schame...@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.
