> -----Original Message-----
> From: lieven.govaerts_at_gmail.com [mailto:lieven.govaerts_at_gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: dinsdag 28 januari 2014 15:24
> To: Branko Čibej
> Cc: Subversion Development
> Subject: Re: Bug in ra_serf with client certificates
>
> On Tue, Jan 28, 2014 at 2:46 PM, Branko Čibej <brane_at_wandisco.com>
> wrote:
> > On 28.01.2014 14:37, Lieven Govaerts wrote:
> >
> > On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <brane_at_wandisco.com>
> wrote:
> >
> > I just got a private report from a user that has a setup with a private
> > certificate. This user happened to select the wrong certificate for a
> > server, and got the following response:
> >
> > svn: E120171: Unable to connect to a repository at URL
> > 'https://example.com/svn/foobar'
> > svn: E120171: Error running context: An error occurred during SSL
> > communication
> >
> >
> > This the error code E120171 comes from Serf and apparently means
> > SERF_ERROR_AUTHN_FAILED. There's corroboration in the server log:
> >
> > 120171 = SERF_ERROR_SSL_COMM_FAILED
> >
> >
> > Ugh. That's me looking at the wrong part of serf.h. :(
> >
> >
> > The command line client doesn't ask for a client certificate, it
> > should be defined correctly in the servers file using:
> > ssl-client-cert-file
> > ssl-client-cert-password
> >
> >
> > (facepalm)
> >
> >
> > Unless (s)he's using TortoiseSVN which has its own dialog to select
> > certificates from the windows certificate store.
> >
> >
> > It's not TSVN, it's a different client but the result is the same -- it has
> > its own implementation of the authn callback.
> >
> > In other words, is I expect there's no way to get the authn dialog to ask
> > for a different cert, given the error message; thanks, I'll pass this on.
> >
>
> It may be possible to implement this. The callback that OpenSSL calls
> in serf to ask for a client certificate now only calls the application
> once, and then returns that cached result.
>
> If OpenSSL actually calls that callback again after a failed
> validation of a client certificate (to be tested) and we can detect
> that failure, it should be possible to ask the application for a new
> client cert.
If this works it would resolve quite a few problems in the current TortoiseSVN implementation.
We heard multiple problem reports of users that use different certificates for different locations and currently the clients must implement their own support on the openssl layer to get this working.
With a proper Serf callback (through Subversion) we can just implement a proper store (either in Subversion or in the clients that implement this on Windows) as we have access to the uri of the repository. In the OpenSSL layer we don't have access to that.
Bert
Received on 2014-01-28 15:37:51 CET