364587 - Firefox/2.0.0.1 breaks smartcard usage.

Status: RESOLVED WORKSFORME

(NSS :: Libraries, defect)

Description

[Bill Ralph]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

After updated to Firefox-2.0.0.1, whenever a smartcard is present in the card reader, any connection to an https site fails with an error code of: 12227 when the site requires a client certificate or 12192 when the site does not. In both cases, the certificates are listed correctly in the Firefox preferences dialog.
Reloading Firefox-2.0 brought it back to operational status.

Reproducible: Always

Steps to Reproduce:
1.Insert a Department of Defense CAC smartcard into the card reader.
2.Connect to an https site.
3.Receive the alert.

Actual Results:  
"Alert: ... Error Code: -12227" 

or

"Alert: ... Error Code: -12192

Expected Results:  
Normal connection to https site and display of web page.

Comment 1

[Kai Engert (:KaiE:)]

You are reporting two issues.

a)
Error 12227 when the site requires a client cert.
This Might be a duplicate of bug 370136, which has a patch.
Bill, do you have at least two certificates with non-repudiation set?

b)
Error 12192 when site does NOT require a client cert.
This is SSL_ERROR_DECRYPT_ERROR_ALERT, "Peer reports failure of signature verification or key exchange."
I don't yet understand this part.

You say this problem is in 2.0.0.1 only, but 2.0.0.0 works fine.
We need to check the changes between the two versions.

Comment 2

[Kai Engert (:KaiE:)]

Bill, regarding regression b)

When you say "error 12192 occurs with a site that does NOT REQUIRE a client cert".
Do you know, does that site optionally use a client cert?

If yes, both issues might be the same bug.

If no, then we'd have to look for other changes that might have introduced that part of the regression. The only other possible change that might have introduced is the upgrade to NSS 3.11.4 that was done for FF 2.0.0.1

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

IMO, the most likely explanation for both of these behavioral changes
(I won't call them regressions) is the recent changes to PSM's code that
selects user certs for SSL client auth.  

Kai, SSL_ERROR_DECRYPT_ERROR_ALERT is an "alert" error.  Like all alert
errors, it reports that the peer has sent us an SSL error alert record.
In all such cases (error alerts received), the user should consult with
the peer (server) to find out why it sent the alert.  

My guess: the server didn't like the cert used for the client authentication.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I wonder if the fix for bug 370136 also fixes this bug.
If so, this should be marked as a duplicate of that bug.

Comment 5

[Momtchil Momtchev]

In order to check it, you could try removing all the certificates except the one on the smartcard. If it works, than this is the same bug as bug 370136. The bug is triggered when you have more than 1 certificates and at least 1 of the certificates has the nonRepudiation bit set. In this case Firefox is going to use the first certificate's private key and it will send the second one - thus the strange errors. Using manual certificate selection should be a workaround too. If it still doesn't work with only 1 certificate loaded in Firefox (or with manual selection), than this is a different issue.

Comment 6

[Bill Ralph]

Here's what I know: The CAC (Common Access Card) contains three certificates. One is intended for identification, one is for email signatures, and one is for email encryption. Both the ID certificate and the email signature certificates have the non-repudiation bit set. The email encryption certificate does not have the non-repudiation bit set.

Regarding the 12192 error, yes, the error occurs at a site which has optional use of a client certificate (the apache server on the same workstation as the firefox client). I don't recall whether it occurs at a site that "SSLVerifiyClient none." I'll test that if you'd like.

Comment 7

[Momtchil Momtchev]

Try the manual certificate selection, it should work if it's the same issue.
IMHO, it's a regression, because the behavior is clearly broken - Firefox would send a certificate and try to authenticate with a key from another certificate.

Comment 8

[Bill Ralph]

I found out that if a site does not have mandatory or optional client certificate requirements, connection occurs properly.

I tried manual certificate selection, and it works. But with some sites like Microsoft Outlook Windows Access, it seems to ask for certificates with every keystroke or mouse click, thus rendering the site virtually unusable.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Bill, You wrote that "Both the ID certificate and the email signature 
certificates have the non-repudiation bit set." 
 
So, then, Is the CAC not conformant to FIPS 201 ("Personal Identity Verification", PIV) ?  

As defined in 

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf
http://www.cio.gov/ficc/documents/CertCRLprofileForCP.pdf ("PROF"),

there are 3 relevant certificate "profiles":
- End Entity Signature   (NR=1, signature only, for email)
- Key Management         (NR=0, key encipherment/agreement, for email)
- PIV Authentication     (NR=0, signature only, for authentication)

FIPS 201 says:

"Certificates containing the public key associated with a PIV authentication 
 private key shall conform to Worksheet 5: End Entity Signature Certificate 
 Profile in [PROF], but shall not assert the nonRepudiation bit in the 
 keyUsage extension,"

The other doc ("PROF") says: 
"The nonRepudiation key usage bit must not be set in either PIV 
 Authentication certificates or Card Authentication certificates."

Comment 10

[Momtchil Momtchev]

OK, This confirms that your problem is the same issue as bug 370136 and this one shall be marked a duplicate. The patch has already been committed, but it won't make it in 2.0.0.2.

Comment 11

[Bill Ralph]

Nelson,

My comments about the non-repudiation bit were based on the information that Firefox told me about the certificates it sees on the CAC. I know nothing about policies and standards to which those certificates are supposed to conform. I just want the browser to work correctly.

Comment 12

[Robert Relyea]

Also CAC is not directly conformant to PIV. PIV changed an number of things that were previously in the CAC card. (In fact PIV and CAC don't even use the same APDUs).

Comment 13

[Momtchil Momtchev]

The fix for bug 370136 has been committed in trunk, can you please test if the nightly builds fix this issue too. I'm almost sure it is the same bug. If the nightly builds work, this bug should be marked a duplicate.

Comment 14

[Bill Ralph]

Fixed by firefox-2.0.0.3.en-US.linux-i686 RC1, as per suggestion of Momtchil Momtchev.