Closed Bug 454406 Opened 16 years ago Closed 16 years ago

SSL handshakes fail after asking PSM to remember user's choice of client auth cert

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
1.9.0 Branch
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1b1

People

(Reporter: erick.fauquette, Assigned: KaiE)

References

Details

(Keywords: regression, verified1.9.0.2, verified1.9.0.4, Whiteboard: [testcase see priv comm 64ff])

Attachments

(5 files)

View of my certificates
3.95 KB, image/gif
Details
Add-ons error message
47.42 KB, image/gif
Details
Back out this patch from bug 431819
16.57 KB, patch
beltzner
: approval1.9.0.2+
Details | Diff | Splinter Review
Thales certificate policy
474.48 KB, application/pdf
Details
Output of certs 141, 142, 143
6.74 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909032504 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909032504 Minefield/3.1b1pre

When using a security device to gain access on web site using certificate the following message is received :
"Secure Connection Failed
An error occurred during a connection to www2.online.thales.
SSL peer does not support certificates of the type it received.
(Error code: ssl_error_unsupported_cert_alert)    
The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
    * Please contact the web site owners to inform them of this problem."
In the same configuration (same equipment, certificate and same URL) but using Firefox 3 (not minefield) all is working fine.

Reproducible: Always

Steps to Reproduce:
1.use security device
2.try to connect to web site which need a certificate
3.enter your access code
Actual Results:  
no connection
error message

Expected Results:  
normal view of the web site  ...;
This sounds like the server is rejecting your certificate format, which may suggest the bug is not in Firefox/Mozilla code at all, but I will move it to the right component, anyhow.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
Perhaps, but why is it working fine with Firefox 3.0 with some alert messages (Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9) Gecko/2008052906) and not with Minefield ?
(In reply to comment #2)
> Perhaps, but why is it working fine with Firefox 3.0 with some alert messages
> (Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9) Gecko/2008052906) and not
> with Minefield ?

Firefox 3.0 has been superseded by 3.0.1, but more important we are about to release 3.0.2 and it has the same version of the crypto library (3.12.1rc2) as Minefield. Since we don't have your security device or web site, would you mind testing with 3.0.2 and see if it has developed the same issue?

You can find the builds we released to the beta channel at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build5/, from your user agent you presumably want ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build5/firefox-3.0.2.fr.win32.installer.exe
I have the same problem using Firefox 3.0.2 

withe the folling error message (it's seems to be the same but in french):
Échec de la connexion sécurisée
    
Une erreur est survenue pendant une connexion à www2.online.thales.
Le pair SSL ne gère pas le type des certificats qu'il a reçus.

(Code d'erreur : ssl_error_unsupported_cert_alert)
   
La page que vous essayez de consulter ne peut pas être affichée car l'authenticité des données reçues ne peut être vérifiée.
    * Veuillez contacter les propriétaires du site Web pour les en informer.
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.2?
this works for me with 3.0.2 Builds on Mac and Windows. I get the SSL Error Site, but i'm able to add a exception for this and so to access the site. Tested with https://www1.online.thalesgroup.com

Erick, can you provide a testurl where we an reproduce this problem?
As Johnathan noted in comment 1, this error comes from your server.
The server is saying that it rejects the certificate from the client.
The client is merely reporting to the user that the server has rejected
the client's certificate.  The next diagnostic step is to examine the 
server logs for information regarding what it didn't like about the 
client's certificate.
One possibility is that the latest version of the client is sending a 
different certificate to the server than it sent before.  If the client
has multiple certificates from the same issuer, it is possible that the
client is now choosing a different certificate from among those available
to it than it chose in previous versions.  The selection of the certificate
to be sent to the server is made by PSM, not NSS.  

I am not aware of any recent chances in PSM's client cert selection code,
but I don't monitor all the PSM changes.  This area of client cert 
selection has received numerous requests for changes in recent months,
including (IIRC) a change to the default from choosing automatically, to 
asking the user to manually choose.  Could it be that the user is choosing
the wrong cert?
(In reply to comment #5)
> Erick, can you provide a testurl where we an reproduce this problem?

The error is in logging in with a user certificate, you'd need a certificate used/issued by their system in order to test it.

Can we test _other_ systems that use certificate auth? Are they all broken or is it limited to just thales or just particular user certs?
No, it's not broken, can't confirm this bug and it works at startssl.com. As Nelson hinted in comment 6, most likely the server rejects the certificate sent by the client.
eddy, it isn't clear by your comment.  Are you saying that Firefox has a bug, or that the reporter of the bug has some specific problem with his setup.

Are you able to client authenticated using a hardware token using Firefox 3.0.x?
(In reply to comment #10)
> eddy, it isn't clear by your comment.

Sorry....lets clarify...

>  Are you saying that Firefox has a bug,

No

> or that the reporter of the bug has some specific problem with his setup.

Yes. Or better, perhaps the server he tries to access has a problem or the reporter doesn't have the required certificate.

> Are you able to client authenticated using a hardware token using Firefox
> 3.0.x?

Yes absolutely!
cool.  thanks eddy.
On comment 8 :
https://www1.online.thalesgroup.com doesn't use hardware certificate, only software . You get connection with a login/password.

The certificate is provide by Thales and so is specific to Thales certification authority. So this autthority is not recognised by the browser.

I will try to delete all my certificate to avoid possible conflict.

the URL is https://www2.online.thalesgroup.com/
I apologize for being late to this bug, I've been travelling over the weekend.

Yes, there has been a change to the client auth code at the PSM level, see bug 431819. We had received confirmation about the correctness on this change on the Mozilla 1.8 branch for Firefox and Thunderbird 2.0.0.x

I'm looking into this issue now and run tests.
After Firefox 3.0.1 we've made 2 changes that may affect this bug:

- updated NSS from 3.12.0 to 3.12.1 (2008-08-18 and 2008-09-05)
- added the fix for bug 431819 to PSM (2008-07-08)

We should find out whether it's the NSS or the PSM change.

I recommend to run two more tests.


Erick, you said:
- Firefox 3.0 works
- Firefox 3.0.2 does not work

Can you please test Firefox 3.0.1? Does it work or not?


Erick, in addition, can you please test this nightly build from 2008-08-08?

Windows here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-08-08-05-mozilla1.9.0
Mac and Linux here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-08-08-04-mozilla1.9.0

Does this build from 2008-08-08 work or not?
Erick, what is your setting for "client authentication" (preferences / advanced / encryption / when a server requests my personal certificate...)

Is it:
- Select one automatically
or is it:
- Ask me every time?


And here is some more information for you:

We have added a new feature, that will first appear in Firefox 3.0.2
The feature is already contained in the build from 2008-08-08.

This feature only affects you when you are using the "Select every time" option.
The dialog that prompts you to select a certificate will contain a new checkbox, which says "remember" (shown in the bottom area of the dialog).

If you have this checkbox checked, your selection will be remembered until the end of your Firefox session.


I think Firefox 3.0 and Firefox 3.0.1 do not show this checkbox.
But 2008-08-08 and Firefox 3.0.2 do show this checkbox.
I try to erase all certificates using certificate manager and I erase my smart card ....

I ask IT security to verify this, if this is confirmed there is a big problem...

So they create me a new certificate and I wille try with the latest release of Minefield what happens in a clean state (no certificate conflict)

With "NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080915032512 Minefield/3.1b1pre" is still non working ...
Attached image View of my certificates — 
I install Gran Paradiso 3.0.2pre
And I get the following message :

Secure Connection Failed
An error occurred during a connection to www2.online.thales.
SSL peer does not support certificates of the type it received.
(Error code: ssl_error_unsupported_cert_alert)
The page you are trying to view can not be shown because the authenticity of the received data could not be verified.

    * Please contact the web site owners to inform them of this problem.
I don't use client authentication often, and the setup is tricky.

But I have setup https://kuix.de:9443/misc/bug454406/index.php

Currently it is set to "client auth optional".
I have connected using my own test cert, and the page tells me, it works. I can provide a screenshot...

I also tested the same with "client auth required". Then I get a failure without cert, and success when using the cert.

I never got ssl_error_unsupported_cert_alert

I think SSL client auth still works with FF 3.0.2 in general.

If it's broken, then either Nelson's theory is right (now a different cert gets chosen), or something has changed at the NSS level.

We'll need more data to investigate.
It works with :
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
erik, can some other Thales employees test this issue and tell us if if works for them or not?
> I install Gran Paradiso 3.0.2pre

Erick, in comment 18 you said, version 3.0.2pre fails.

Please note that many different nightly test snapshots use this same version number.

When you said "3.0.2pre fails", I hope you were explicitly referring to the version from 2008-08-08 that I gave you in comment 15
Erick, can you please answer my question from comment 16?
The answer is very important for me.
Thanks.
Comment #16 : I try both, with box checked (default) and box unchecked withe the same result.

Comment #21: no because of IT security ...
I ask them to verify that deleting information in Certificate Manager does or doesn't erase the smart card. 
Comment #22: I follow the link you give me ...


I seems that if I try to access some intranet web site using my certificate there is no problem. 
In previous release of Firefox I have to agree a lot of exceptions to grant access to site with problem (extranet).
This site is accessed through  a proxy using automatic configuration url (.pac file)
Attached image Add-ons error message — 
with Firefox 3.0.2 I get an error message during during verification of updates for extensions.
Comment #16 : If I am very careful to uncheck box It works with Firefox 3.0.2 and MineField
Erick, thanks a lot for your tests and answers.

You said:

(In reply to comment #24)
> Comment #16 : I try both, with box checked (default) and box unchecked withe
> the same result.

This means, you are using the setting "ask every time" with the versions that have the checkbox (starting 3.0.2pre on 2008-07-08)

More questions (sorry):


From attachment 338845 [details] I learn that you have 3 different certs with the same expiration date. I guess your environment uses triple-key-certs, i.e. separate certs/keys for signing/encryption/non-repudiation.


Question 1:
When Firefox 3.0.2pre prompts you to select a certificate (in the dialog that has the checkbox), how many certs does it offer to you in the dropdown box?

If it offers you more than one cert, which one do you use (you should see a difference in the "Purposes" string in the select-cert dialog.

What is the "purposes" value shown for the cert you select?


Question 2:
When you use Firefox 3.0.1 or Firefox 3.0,
do you get the dialog that asks you to select a certificate manually?

If yes, how many certs does it offer in the dropdown box?
(In reply to comment #25)
> Created an attachment (id=338866) [details]
> Add-ons error message
> 
> with Firefox 3.0.2 I get an error message during during verification of updates
> for extensions.

This seems very strange.
It suggests that something might be broken to your certificate database and its trust settings.

I guess you have NOT explicitly deleted trust for the root CA that issued the addons.mozilla.org site cert.
Comment #27 : question 1 only one certificate is proposed.
Due to how the web site has been developped I have to validate 25 times the same certificate to gain access for the first connection ...

The second time, IT is possible to leave the box checked, if I do this in the same session ( not closing Firefox)
Comment #27 : question 2 with Firefox 3.0.1 I get the dialog to select a certificat manually (only 10 times !!!) with only one choice
(In reply to comment #29)
> Comment #27 : question 1 only one certificate is proposed.
> Due to how the web site has been developped I have to validate 25 times the
> same certificate to gain access for the first connection ...

This is interesting.
You get the same prompt 25 times?
That sounds like a badly configured server.
It probably means the session cache is disabled on the server side.
I Think I have got It :
If I use "select one automatically" it works with Firefox 3.0.2 and Minefield,
If I use "ask each time" and I leave the default checked box there is an error,
If I use "ask each time" and I uncheck the box each time it works.

I expect this can help .
Erick, I would like to ask you for one more test.

Please use the Firefox that fails for you, for example the latest 3.0.2pre version.

When you connect, please clear the checkbox every time.
You said, you are prompted 25 times.
Please uncheck the checkbox every times.

Does that allow you to connect?
Erick's comment 32 already answers my questions from comment 33, thanks.
I believe I understand the failure. Writing another comment now.
Comment #33 : with Gran Paradiso 3.0.2pre 
If I use "select one automatically" it works,
If I use "ask each time" and I leave the default checked box there is an error,
If I use "ask each time" and I uncheck the box each time it works.
According to the screenshot, Erick is using a dual-key or even a triple-key cert, where he owns multiple certs with the same nickname, but each cert is only usable for a single usage (I suppose, one for signing, non-repudiation or encryption).

The patch from bug 431819 introduced logic to remember the user's decision, even after one has been prompted (at least once) to select a cert manually.

Because Erick's server is configured not to reuse an authenticated session (not even for seconds), as soon as the new checkbox remains checked (the default), the next authentication will run through the new code, which looks up the certificate based on the previous user selection.

I realize this lookup is based on the nickname, only. It does not attempt to find a certificate with the correct usage.

Because of this, the automatic lookup might (randomly) pick one of the 3 certs having identical nicknames. We might end up using the encryption cert, which is not appropriate for authentication.

This matches Nelson's suspicion from earlier in this bug, that we are sending the wrong cert.


If Erick's server were configured to have a greater SSL session timeout, then the initial connection attempt would work.

But even then he would eventually fail, after the SSL session expires.


I suspect this bug affects all users of SSL client auth in dual-key or triple-key setups, which might be common for high-security deployments.

I propose to work on a patch that backs out bug 431819 (allowing us to implement a smarter patch for a future cycle), but keep the patch from bug 426555.
Ok, I propose to backout attachment 328557 [details] [diff] [review] from bug 431819.
Status: UNCONFIRMED → NEW
Ever confirmed: true

        Attachment #338883 -
        Flags: approval1.9.0.2?

    
    

    
  
I think we may be seeing multiple separate problems here.  

I have another hypothesis about what's difference between 3.0.1 and 3.0.2pre.
It is possible that 301 was sending the client cert with its full chain,
and 302 is sending an incomplete cert chain for the client cert.  

I suspect that the server is sending back the wrong TLS alert code. 
I suspect that it fails to validate the cert, for some reason (as yet unknown)
such as having undesired key usages or having an incomplete cert chain, and
it is sending back an alert code that signifies the use of a cert with the
wrong type of public key in it.  If this suspicion is correct, then the 
problem is not necessarily that there is anything wrong with the cert itself,
but perhaps with the cert chain.

    
    

    
  
So is this the right patch? Does it require review?

    
    

    
  
(In reply to comment #40)
> So is this the right patch?

It seems very likely, based on the test results, that unchecking the checkbox helps (meaning the new logic from the patch never gets run).

Nelson's comment means, there might be another change between the NSS releases that might have touched this area of functionality, but we agree the patch I'd propose to backout seems more likely.


> Does it require review?

Do backouts require review? It is equivalent to the original patch, I just copied it in here for reference. The patch applies cleanly. From my point of view I think an approval-to-backout is sufficient.

    
    

    
  
Comment on attachment 338883 [details] [diff] [review]
Back out this patch from bug 431819

a=beltzner to land on cvs trunk and GECKO190_20080827_RELBRANCH

        Attachment #338883 -
        Flags: approval1.9.0.2? → approval1.9.0.2+
Blocks: 431819
Severity: normal → blocker
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 1.9.0 Branch

    
    

    
  
(can we get a better title for this bug, too?)

    
    

    
  
Changed the bug summary
Summary: Secure Connection Failed → SSL handshakes fail after asking PSM to remember user's choice of client auth cert

    
    

    
  
Erick, for your education, could you please describe in more detail what certificates you are using?

I assume you have extended the "dual key certificate" principle and use a "triple key certificate", is that right?

I assume your certificates differ only by serial number and key usage, and I suspect you are using key usages of signing, non-repudiation, encryption. Is that all right? If not, I'd be very interested to hear about your details. This would allow us to reproduce your environment for testing.

And BTW thanks a lot for your bug report, having answered our many questions and the tests you have performed.

    
    

    
  
Sorry if this seems pedantic, but since there is no such thing as a 
"dual key certificate", let's find a more accurate term to describe such 
certs in bugs.  I've been calling them "limited usage" or "single usage" 
certificates.  Such certs may come in pairs or triplets.

    
    

    
  


  

    
    

    
  
Comment # 46 : as far as I know, we effectively use 3 certificates, following are the key usage of each. I expect this will help.I attach a document describing Thales security services "Safe Sign" what we use internally with some enhancement.

Certificate key usage 
Critical
Key Encipherment
Data Encipherment

Certificate key usage 
Critical
Signing
Non-repudiation

extended key usage
Not Critical
TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
1.3.6.1.5.5.7.3.5
1.3.6.1.5.5.7.3.6
1.3.6.1.5.5.7.3.7
Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1)
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.3+
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.2+

    
    

    
  
(In reply to comment #47)
> Sorry if this seems pedantic, but since there is no such thing as a 
> "dual key certificate", let's find a more accurate term to describe such 
> certs in bugs.  I've been calling them "limited usage" or "single usage" 
> certificates.  Such certs may come in pairs or triplets.

Search results from a major search engine:

"single usage certificates"
none

"limited usage certificates"
3

"dual key certificates"
221, including:
- http://www.mozilla.org/projects/security/pki/psm/smime_guide.html
- http://www.redhat.com/f/pdf/rhas/DirSecProductSheetCertificateSystem.pdf
- http://docs.sun.com/source/816-5543-10/agtintro.htm
- http://www.verisign.com.au/gatekeeper/faqs/general.shtml#05

This is the term we've been using in the past.

Your term "single usage certificate" describes an individual physical cert".
I think the term "dual key certificate(s)" describes that you're getting a group of physical certificates, each having its own key, which form one logical certificate.

    
    

    
  
Erick, thanks a lot for your description in comment 49.

Earlier in this bug you said, when you are prompted to select a cert, the dropdown box only contains a single cert.

I tried to produce such a group of certificates (as in comment 49) locally using the NSS command line tools. After I import them to Firefox and attempt to connect to my test site, Firefox offers me to select out of 2 certs, the "TLS web auth" and the "signing, non-repudiation" cert.

I conclude that I don't understand your setup well enough, or that I failed to reproduce it correctly.

    
    

    
  
I am now able to reproduce the failure with the patch applied and my own set of 3 test certificates.

It was necessary to play with the order of the (nonworking for auth) encryption cert, within the set of 3 certs, as expected.

    
    

    
  
In reply to comment 52,
Kai, out of curiosity, how did you "play with the order of the [certs]" ?
This could be useful to know for future testing purposes.

In reply to comment 50, what search engine did you use?  
I only found 24 with google, and most of them were from mozilla.  
I found 14 with google groups, again mostly from mozilla, or people 
discussing mozilla.

    
    

    
  
> In reply to comment 50, what search engine did you use?  
> I only found 24 with google, and most of them were from mozilla.  
> I found 14 with google groups, again mostly from mozilla, or people 
> discussing mozilla.

I used Google, too, and got 242 results:
http://www.google.com/search?hl=en&q=%22dual+key+certificates%22&btnG=Google+Search&aq=f&oq=

    
    

    
  
> In reply to comment 52,
> Kai, out of curiosity, how did you "play with the order of the [certs]" ?
> This could be useful to know for future testing purposes.

In my first attempt I used the following order of commands:

certutil -d . -S -n SomeoneTriple -s "CN=Someone Triple, O=Test Org, L=Test Loc, ST=Test State, c=DE" -c kai-test-ca -t p,p,p -m 131 -v 60 -1
                2 - Key encipherment
                3 - Data encipherment

certutil -d . -S -n SomeoneTriple -s "CN=Someone Triple, O=Test Org, L=Test Loc, ST=Test State, c=DE" -c kai-test-ca -t p,p,p -m 132 -v 60 -1
                0 - Digital Signature
                1 - Non-repudiation

certutil -d . -S -n SomeoneTriple -s "CN=Someone Triple, O=Test Org, L=Test Loc, ST=Test State, c=DE" -c kai-test-ca -t p,p,p -m 133 -v 60 -6
                1 - Client Auth

Next I exported to .p12 file using pk12util, -n SomeoneTriple, and imported into Firefox. Connected to my server. I changed the server config to have a tls-session-timeout of 1 second. Selected a signing cert with "remember". Connection ok. Tried to reload, worked again.

In this order of certs, when PSM used the Find-By-Nickname function, it apparently worked.


Then I repeated the above steps in reverse order, at the same time changing the serial numbers:

certutil -d . -S -n SomeoneTripleRev -s "CN=Someone Triple Reversed, O=Test Org, L=Test Loc, ST=Test State, c=DE" -c kai-test-ca -t p,p,p -m 141 -v 60 -6
                1 - Client Auth

certutil -d . -S -n SomeoneTripleRev -s "CN=Someone Triple Reversed, O=Test Org, L=Test Loc, ST=Test State, c=DE" -c kai-test-ca -t p,p,p -m 142 -v 60 -1
                0 - Digital Signature
                1 - Non-repudiation

certutil -d . -S -n SomeoneTripleRev -s "CN=Someone Triple Reversed, O=Test Org, L=Test Loc, ST=Test State, c=DE" -c kai-test-ca -t p,p,p -m 143 -v 60 -1
                2 - Key encipherment
                3 - Data encipherment

When I repeat the above test with this new SomeoneTripleRev cert, when doing the reload step, the connection fails with the same error message as given in comment 0. Apparently, the ordering of cert creation (or the ordering based on serial numbers) has an effect on Find-By-Nickname. I think this is to expect. The function probably stops searching on whatever happens to be the first match.

    
    

    
  
In reply to comment 54, when I click the link in that comment, I get a page
of results that says: 
       Results 1 - 24 of 24 for "dual key certificates". (0.22 seconds)
I wonder why the results are so different!

    
    

    
  
Kai, thanks for the great explanation in comment 55.  
Please look at the "notBefore" dates on the 3 certs (SN 141-143) and see 
if they differ, even by as little as one second each.  NSS commonly sorts
certs with the same subject name by the ordered pair {notBefore, noAfter} 
in descending order, IIRC.

    
    

    
  
Erick or Nelson or Kaie, can you please verify the bug is fixed now?   Build 6 has been pushed to the ftp server now with the fix.   I'd do it myself but i don't have the environment setup.

Download at: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build6/

    
    

    
  
Would bug this have caused a nightly of THunderbird to stop accepting my host's IMAPS server self-signed cert? I'm getting the sec_error_untrusted_issuer error, but only in the past few days, and the self-signed cert on my host's box seems to have been generated beginning of June (don't know when it was actually installed).

    
    

    
  
If I use "select one automatically" it works,
If I use "ask each time" it works.

As you suppress the check box IT works in both cases in my configuration.

    
    

    
  
Still not working with Minefield ;
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080918073230 Minefield/3.1b1pre

If I use "select one automatically" it works,
If I use "ask each time" and I leave the default checked box there is an error,
If I use "ask each time" and I uncheck the box each time it works

    
    

    
  
(In reply to comment #60)
> If I use "select one automatically" it works,
> If I use "ask each time" it works.
> 
> As you suppress the check box IT works in both cases in my configuration.


Eric, I assume you have seen/confirmed this success with the most recent Firefox 3.0.2pre ?

(The fact you don't get a checkbox means, Erick was using a version without the patch, i.e. a successful backout)

    
    

    
  
(In reply to comment #61)
> Still not working with Minefield ;
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080918073230 Minefield/3.1b1pre
> 
> If I use "select one automatically" it works,
> If I use "ask each time" and I leave the default checked box there is an error,
> If I use "ask each time" and I uncheck the box each time it works

Yes, this is expected, on the latest development nightlies, I have not yet backed the patch out.

    
    

    
  
(In reply to comment #59)
> Would bug this have caused a nightly of THunderbird to stop accepting my host's
> IMAPS server self-signed cert? I'm getting the sec_error_untrusted_issuer
> error, but only in the past few days, and the self-signed cert on my host's box
> seems to have been generated beginning of June (don't know when it was actually
> installed).

Chris, that seems unrelated. We have not changed the logic that decides whether a server is trusted or not.

It seems more likely that this is caused by a change in your profile's trust settings, or by a configuration change on your server.

But if you'd like to test whether it's related, you could compare the behavior of nightly 3.0.2pre builds from 2008-09-15 and 2008-09-18.
If you get the same behavior for both, your issue is separate.

Unless you have evidence your issue is related to this bug and still think Firefox is behaving incorrectly, please file a separate bug. Thanks!

    
    

    
  


  
(In reply to comment #57)
> Please look at the "notBefore" dates on the 3 certs (SN 141-143) and see 
> if they differ, even by as little as one second each.  NSS commonly sorts
> certs with the same subject name by the ordered pair {notBefore, noAfter} 
> in descending order, IIRC.

Nelson, I'm attaching a text dump of those certs.

    
    

    
  
Comment #62 
Kaie, I Install this release :
firefox-3.0.2.fr.win32.installer.exe	17-Sep-2008 12:24 	7.2M

from :
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build6/

I didn't found  a firefox-3.0.2pre in this directory ...

    
    

    
  
(In reply to comment #58)
> Erick or Nelson or Kaie, can you please verify the bug is fixed now?

Tony: By comment 71 and comment 60 Erick has verified that ff302 build6 works for him


> I'd do it myself but i
> don't have the environment setup.

If you still want to try yourself, comment 64 ff. might allow you to.
(hidden comments, as my test case involves certificates including private keys from my test CA)


Adding keyword checking-needed, because this must get backed out on hg, which is currently closed.
Keywords: checkin-needed
Whiteboard: [testcase see priv comm 64ff]

    
    

    
  
(In reply to comment #72)
> (In reply to comment #58)
> > Erick or Nelson or Kaie, can you please verify the bug is fixed now?
> 
> Tony: By comment 71 and comment 60 Erick has verified that ff302 build6 works
> for him
> 
> 
> > I'd do it myself but i
> > don't have the environment setup.
> 
> If you still want to try yourself, comment 64 ff. might allow you to.
> (hidden comments, as my test case involves certificates including private keys
> from my test CA)
> 
> 
> Adding keyword checking-needed, because this must get backed out on hg, which
> is currently closed.

Thanks Erick for verifying. And thanks Kaie for the test certs you added.  Do we have permission to save them to our test server?  We've been talking about setting up more cert tests here at Mozilla, and this could be a place to start.

I'll mark the bug verified for 3.0.2
Keywords: fixed1.9.0.2 → verified1.9.0.2

    
    

    
  
(In reply to comment #73)
> And thanks Kaie for the test certs you added.  Do
> we have permission to save them to our test server?  We've been talking about
> setting up more cert tests here at Mozilla, and this could be a place to start.


The certs I have added are not sufficient for a different server, they rely on the server infrastructure at https://kuix.de:9444

What is your test server? The mochitest build time test automation? Or a different I'm not yet aware of? In any case, I propose we start a separate bug for getting SSL client auth tested automatically in some way. I've filed bug 456001. Tony, maybe you could add the answers over there? Thanks!

    
    

    
  
I've now downloaded build 6, too, and I concur with "verified".

    
    

    
  
In reply to comment 70, the 3 certs shown in attachment 339408 [details] are 
ordered in descending order by notBefore date, newest first, as expected.  

I conclude that the method used for find a client cert "automatically"
uses a different NSS search function, or different additional cert 
selection code, than the code that found a cert based on nickname.  
I'd like to see which NSS functions are being used in both cases.  

Kai, Can you provide MXR URLs for the PSM code in each case?

    
    

    
  
Can you add a whiteboard note on what/where you want checkin ?
I would prefer to be sure.

    
    

    
  
(In reply to comment #77)
> Can you add a whiteboard note on what/where you want checkin ?
> I would prefer to be sure.

There is only one patch attached to this bug, attachment 338333 [details].
It needs to be backed out from mozilla-central.

use patch -R

    
    

    
  
(In reply to comment #78)
> There is only one patch attached to this bug, attachment 338333 [details].
> It needs to be backed out from mozilla-central.

Posting a patch and asking to "revert" it is unusual to me.

> use patch -R

Does this (patch) differ from
http://hg.mozilla.org/mozilla-central/rev/6615b044bcd8
(It seems not to remove the 2 added files, at least...)

or can I use that as the source of "backout" ?
(though I would "disconnect" it, not to have a 3 month line on the Hg graph.)

    
    

    
  
I ended up just backing out changeset 6615b044bcd8.

http://hg.mozilla.org/mozilla-central/rev/b8baa5937128
http://hg.mozilla.org/mozilla-central/rev/9f8ea2a5f290
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1

    
    

    
  
Verified for 1.9.0.4 with  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4pre) Gecko/2008102706 GranParadiso/3.0.4pre.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.4 → verified1.9.0.4

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: