subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Loritsch, Berin" <blorit...@dtri.net>
Subject RE: SSL Error when trying to connect to svn via https
Date Tue, 12 Oct 2010 12:40:48 GMT

> Can you try some tests without svn, for instance set up 
> apache to serve a simple static page protected by client cert 
> authentication, and try to access that with that cert using 
> openssl 0.9.8g vs. 0.9.8k?
> Or try to build an svn client on your new machine with 
> openssl 0.9.8g instead of k?

This one client that is failing, are any of the other clients using the
0.9.8k version of OpenSSL?  I'm just trying to weed out possible rabit
holes.  When I was doing PKI work with the Java libraries I did find
that certain attributes in the client cert would not work with Java, but
would with OpenSSL.  There is a possibility that the same thing is going
on here.  The one thing that really helped me was the ability to get a
log dump of the handshake process.  I'm sure OpenSSL has an equivalent
feature.  Unfortunately I don't know where to look for the problem.  It
does seem odd that a certificate from an older version of OpenSSL would
stop working with a newer version.  That is unless the certificate is
technically invalid and the OpenSSL team fixed that problem.

PKI SSL handshakes are complex beasts.  The client requests a
connection, server responds with its public key and the client/server
negotiate an encryption standard and session key.  After that, the
server requests the client key and verifies it.  If all goes well, they
renegotiate the session key.  That's the abridged version of what goes
on.  The key (pun not intended) to understand what can be going wrong is
knowing who severed the connection and why.  If the client could not
read its own public key certificate or the server did not like the way
the client served it requires two different actions to remedy.  Usually,
if the server is more up to date than the client you do have better luck
than the other way around (this applies to most libraries).


Confidentiality Note: The information contained in this message, and any attachments, may
contain proprietary and/or privileged material. It is intended solely for the person or entity
to which it is addressed. Any review, retransmission, dissemination, or taking of any action
in reliance upon this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and delete the material
from any computer.

Mime
View raw message