You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2014/01/28 13:53:48 UTC
Bug in ra_serf with client certificates
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:
[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?
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Bug in ra_serf with client certificates
Posted by Branko Čibej <br...@wandisco.com>.
On 28.01.2014 13:53, Branko Čibej 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:
>
> [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?
To follow up, apparently the command-line client never even asks for a
client cert ... even when ~/.subverion/auth is completely removed.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
RE: Bug in ra_serf with client certificates
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: lieven.govaerts@gmail.com [mailto:lieven.govaerts@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 <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.
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
Re: Bug in ra_serf with client certificates
Posted by Lieven Govaerts <lg...@apache.org>.
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. brane@wandisco.com
Re: Bug in ra_serf with client certificates
Posted by Branko Čibej <br...@wandisco.com>.
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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
AW: Bug in ra_serf with client certificates
Posted by Markus Schaber <m....@codesys.com>.
Hi, all,
Von: Thomas Åkesson [mailto:thomas@akesson.cc]
>
> On 28 jan 2014, at 14:37, Lieven Govaerts <lg...@apache.org> wrote:
>
> > On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <br...@wandisco.com> wrote:
> >
> >> [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
>
> Sorry, I am late to this party. Just got confused by this statement that
> command line client does not ask.
>
> svn info https://secure.example.com
> Autentiseringsregion (realm): https://secure.example.com:443 Filnamn för
> klientcertifikat:
>
> This happened to become Swedish but the last line asks for a filename of
> client cert. This was 1.7.7 that I had on an old test machine.
>
> Attempting this on 1.8 gives an SSL error as this thread has already stated.
I remember testing this about one year ago. 1.7 did prompt, but not save the
certificate file (neither path nor content) in the auth store, so it would
prompt again and again on each connection attempt. Thus, setting it in the
configuration was the only sensible way to use client certificates.
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Bug in ra_serf with client certificates
Posted by Thomas Åkesson <th...@akesson.cc>.
On 2014-02-21, at 12:58, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Thomas Åkesson [mailto:thomas@akesson.cc]
>> Sent: vrijdag 21 februari 2014 11:32
>> To: Subversion Development
>> Cc: Branko Čibej; Lieven Govaerts
>> Subject: Re: Bug in ra_serf with client certificates
>>
>>
>> On 28 jan 2014, at 14:37, Lieven Govaerts <lg...@apache.org> wrote:
>>
>>> On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <br...@wandisco.com>
>> wrote:
>>>
>>>> [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
>>
>> Sorry, I am late to this party. Just got confused by this statement that
>> command line client does not ask.
>>
>> svn info https://secure.example.com
>> Autentiseringsregion (realm): https://secure.example.com:443
>> Filnamn för klientcertifikat:
>>
>> This happened to become Swedish but the last line asks for a filename of
>> client cert. This was 1.7.7 that I had on an old test machine.
>>
>> Attempting this on 1.8 gives an SSL error as this thread has already stated.
>
> There was a behavior change in 1.8, where the default was changed to *not ask* until it is enabled in the config.
>
> See http://subversion.apache.org/docs/release-notes/1.8.html#client-cert-prompt-suppression
>
> I think the reasoning was that there are servers that allow a client certificate, but don't require one. In case you would have to use such a server but don't have a certificate you would get the question over and over again.
Ok, that clarifies Lieven's statement. It applies "since 1.8".
I don't care whether the client prompts for filename or not, but I find it important to provide a good error message (preferably with recommended action) and APIs that help Tortoise et al.
Also like, Markus' idea about recording (no-)need for certificate in auth cache.
Cheers,
Thomas Å.
AW: Bug in ra_serf with client certificates
Posted by Markus Schaber <m....@codesys.com>.
Hi,
Von: Bert Huijben [mailto:bert@qqmail.nl]
> From: Thomas Åkesson [mailto:thomas@akesson.cc]
> > >> [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
> >
> > Sorry, I am late to this party. Just got confused by this statement
> > that command line client does not ask.
> >
> > svn info https://secure.example.com
> > Autentiseringsregion (realm): https://secure.example.com:443 Filnamn
> > för klientcertifikat:
> >
> > This happened to become Swedish but the last line asks for a filename
> > of client cert. This was 1.7.7 that I had on an old test machine.
> >
> > Attempting this on 1.8 gives an SSL error as this thread has already stated.
>
> There was a behavior change in 1.8, where the default was changed to *not
> ask* until it is enabled in the config.
>
> See http://subversion.apache.org/docs/release-notes/1.8.html#client-cert-
> prompt-suppression
>
> I think the reasoning was that there are servers that allow a client
> certificate, but don't require one. In case you would have to use such a
> server but don't have a certificate you would get the question over and over
> again.
A better fix for this would be to save in the auth cache that the login without
certificate was successful, so the user won't be asked again until the next
failure.
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: Bug in ra_serf with client certificates
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Thomas Åkesson [mailto:thomas@akesson.cc]
> Sent: vrijdag 21 februari 2014 11:32
> To: Subversion Development
> Cc: Branko Čibej; Lieven Govaerts
> Subject: Re: Bug in ra_serf with client certificates
>
>
> On 28 jan 2014, at 14:37, Lieven Govaerts <lg...@apache.org> wrote:
>
> > On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <br...@wandisco.com>
> wrote:
> >
> >> [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
>
> Sorry, I am late to this party. Just got confused by this statement that
> command line client does not ask.
>
> svn info https://secure.example.com
> Autentiseringsregion (realm): https://secure.example.com:443
> Filnamn för klientcertifikat:
>
> This happened to become Swedish but the last line asks for a filename of
> client cert. This was 1.7.7 that I had on an old test machine.
>
> Attempting this on 1.8 gives an SSL error as this thread has already stated.
There was a behavior change in 1.8, where the default was changed to *not ask* until it is enabled in the config.
See http://subversion.apache.org/docs/release-notes/1.8.html#client-cert-prompt-suppression
I think the reasoning was that there are servers that allow a client certificate, but don't require one. In case you would have to use such a server but don't have a certificate you would get the question over and over again.
Bert
>
>
> Thanks,
> Thomas Å.
Re: Bug in ra_serf with client certificates
Posted by Thomas Åkesson <th...@akesson.cc>.
On 28 jan 2014, at 14:37, Lieven Govaerts <lg...@apache.org> wrote:
> On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej <br...@wandisco.com> wrote:
>
>> [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
Sorry, I am late to this party. Just got confused by this statement that command line client does not ask.
svn info https://secure.example.com
Autentiseringsregion (realm): https://secure.example.com:443
Filnamn för klientcertifikat:
This happened to become Swedish but the last line asks for a filename of client cert. This was 1.7.7 that I had on an old test machine.
Attempting this on 1.8 gives an SSL error as this thread has already stated.
Thanks,
Thomas Å.
Re: Bug in ra_serf with client certificates
Posted by Lieven Govaerts <lg...@apache.org>.
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. brane@wandisco.com