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.
L.
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane_at_wandisco.com
Received on 2014-01-28 15:25:17 CET