On Tue, Jan 28, 2014 at 2:46 PM, Branko Čibej <br...@wandisco.com> wrote: > On 28.01.2014 14:37, Lieven Govaerts wrote: > > On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <br...@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. br...@wandisco.com
