On 07/10/2009 13:24, Eddy Nigg wrote:
On 10/07/2009 07:25 AM, Kyle Hamilton:
Your comments suggest to me that NSS (and Firefox) *should not* be
enforcing any checks on the certificates, other than noting that
they're expired or revoked to the user in the certificate selection
dialog. If it has o
On 10/07/2009 01:24 PM, Eddy Nigg:
Most funny is, when you don't want to chose any of the certificates
for authentication and you hit "Cancel" Firefox nevertheless decides
to sent a "Go new cert" message. But it's so brain-dead today, when
you want to try it again and you had by mistake the d
On 10/07/2009 07:25 AM, Kyle Hamilton:
Your comments suggest to me that NSS (and Firefox) *should not* be
enforcing any checks on the certificates, other than noting that
they're expired or revoked to the user in the certificate selection
dialog. If it has only one certificate that matches the i
My apologies, I thought we were discussing the alert protocol in
general, as relates to TLS and how to tell the client what's going on,
not specifically Firefox's/NSS's behavior. It's important to get an
understanding of what's going on before trying to decide whether any
change is necessary. I'm
On 10/07/2009 02:04 AM, Kyle Hamilton:
There is absolutely *NO*
requirement that the client send a currently-valid certificate, and
it's up to the server to detect that.
E, btw, that's not entirely correct because the client does perform
many checks. Obviously SHOULD the client send so
Kyle, what you apparently don't seem to get here is, that users of
Firefox (but also other browsers) experience the most difficulties
BEFORE the browser even tries to send anything. The browser doesn't say
"Hey listen buddy, this server wants that you authenticate with a
client certificat
If there's no client certificate, either "access_denied",
"bad_certificate", or "certificate_unknown". (I'd suggest the first,
since without a certificate you won't grant access.)
Your TLS implementation *can* check the status of the certificate
before it's even ever passed to the application lay
On 10/06/2009 08:44 PM, Kyle Hamilton:
On Mon, Oct 5, 2009 at 11:38 AM, Eddy Nigg wrote:
I don't think anyone is doubting that both FF and IE have some problems
with the way they handle client auth. Most of these problems can be
worked around on the server (use request, not require, throug
On Mon, Oct 5, 2009 at 11:38 AM, Eddy Nigg wrote:
>> I don't think anyone is doubting that both FF and IE have some problems
>> with the way they handle client auth. Most of these problems can be
>> worked around on the server (use request, not require, through an error
>> page if the cert you wa
On 10/06/2009 12:48 AM, Robert Relyea:
This is the default settings.
Hasn't been for over a year now...
https://bugzilla.mozilla.org/show_bug.cgi?id=295922
Oh, sorry, that's my mistake, I meant the remember flag.
It's not an unreasonable work around, and probably your best choice i
On 10/05/2009 11:38 AM, Eddy Nigg wrote:
> Thanks Bob,
>
> On 10/05/2009 07:39 PM, Robert Relyea:
>> FF does not just resend the same certificate unless you have 'Select
>> Automatically' turned on.
>>
>
> This is the default settings.
Hasn't been for over a year now...
https://bugzilla.mozill
Thanks Bob,
On 10/05/2009 07:39 PM, Robert Relyea:
FF does not just resend the same certificate unless you have 'Select
Automatically' turned on.
This is the default settings.
I don't think anyone is doubting that both FF and IE have some problems
with the way they handle client auth. Mo
On 10/04/2009 08:57 PM, Eddy Nigg wrote:
> On 10/05/2009 05:49 AM, Eddy Nigg:
>>
>> So the server sent a nice error page as you say, most browsers
>> including Firefox and Explorer will have to be completly restarted in
>> order to authenticate again. Or the servers session is set to a very
>> shor
On 05/10/2009 01:24, Peter Djalaliev wrote:
It is our standard security nightmare. Side A thinks it is Side B's
problem. Side B thinks it is Side A's problem. In the meantime the
user doesn't use the tech because it doesn't work, and the sides are too
busy arguing to solve the problem. So z
On 10/05/2009 05:49 AM, Eddy Nigg:
So the server sent a nice error page as you say, most browsers
including Firefox and Explorer will have to be completly restarted in
order to authenticate again. Or the servers session is set to a very
short time like 10 seconds, which has other drawback's p
On 10/05/2009 05:40 AM, Eddy Nigg:
If the browser has no cert to send,
it sends a "I have no cert" message.
And what exactly do you expect the server should return in that case?
Probably that you can't authenticate without a certificate...it's
about as lame
It's entirely up to the
On 10/05/2009 05:13 AM, Nelson B Bolyard:
Eddy,
We're talking about the status of the client cert, not the server cert.
Yes, exactly!
The client doesn't do a validity check on its own cert before using it.
Really? Do me a favor and perform a few tests against the StartSSL
authentic
On 2009-10-04 19:55 PDT, Eddy Nigg wrote:
> On 10/05/2009 03:41 AM, Nelson B Bolyard:
>> That's not true. It's likely true for some servers, but not for SWS.
>>
>> And, in any case, the case where the browser has no cert to send is not
>> one of the cases described by the original poster.
>
> Wel
On 10/05/2009 03:41 AM, Nelson B Bolyard:
That's not true. It's likely true for some servers, but not for SWS.
And, in any case, the case where the browser has no cert to send is not
one of the cases described by the original poster.
Well, there is no difference in the reporting by Firefo
On 2009-10-04 13:37 PDT, Eddy Nigg wrote:
> On 10/04/2009 09:23 PM, Nelson B Bolyard:
>> On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
>>
>>> I've enabled client authentication in Sun One Web Server 6.1 and it does
>>> work fine when the client certificate is valid.
>>> I would like to present t
On Sun, Oct 4, 2009 at 2:30 PM, Ian G wrote:
> On 04/10/2009 22:37, Eddy Nigg wrote:
>>
>> On 10/04/2009 09:23 PM, Nelson B Bolyard:
>>>
>>> On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
>>>
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the clien
> It is our standard security nightmare. Side A thinks it is Side B's
> problem. Side B thinks it is Side A's problem. In the meantime the
> user doesn't use the tech because it doesn't work, and the sides are too
> busy arguing to solve the problem. So zero security is delivered.
>
> In this
> So this could be re-written: Is there something we can do for browsers
> to show something more enlightening than
> "ssl_error_handshake_failure_alert" when seeing this common error?
>
Yes. The bad news is that the "something we can do" is very browser
specific.
In the case of Mozilla Firefo
On 04/10/2009 22:37, Eddy Nigg wrote:
On 10/04/2009 09:23 PM, Nelson B Bolyard:
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the client certificate is valid.
I would like to present the user with a good er
On 10/04/2009 09:23 PM, Nelson B Bolyard:
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the client certificate is valid.
I would like to present the user with a good error message instead of the
generic o
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
> I've enabled client authentication in Sun One Web Server 6.1 and it does
> work fine when the client certificate is valid.
> I would like to present the user with a good error message instead of the
> generic one when his certificate is not valid.
> I
On 10/04/2009 07:45 AM, Meena Vyas:
Please ask Sun Web Server related questions in forum
http://forums.sun.com/forum.jspa?forumID=759
This is a Firefox issue, not a server-side problem. Here is a tracking
bug with many different bugs regarding client authentication:
https://bugzilla.mozill
Please ask Sun Web Server related questions in forum
http://forums.sun.com/forum.jspa?forumID=759
Subject:
How to display the cause of an SSL client authentication failure
From:
"Jereme Bulzor"
Date:
Sun, 4 Oct 2009 00:
28 matches
Mail list logo
