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 > [Tue Jan 28 13:32:47 2014] [info] SSL Library Error: 336105671 > error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return > a certificate No CAs known to server for verification? > > > The bug, as I see it, is that in this case, the command-line client doesn't > ask for different credentials. Shouldn't we be transforming (or wrapping) > SERF_ERROR_AUTHN_FAILED to SVN_ERR_RA_NOT_AUTHORIZED? 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 Unless (s)he's using TortoiseSVN which has its own dialog to select certificates from the windows certificate store. Lieven > -- Brane > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. br...@wandisco.com
