If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Certificates are not displayed/selectable from certificates stored on smartcard

RESOLVED INVALID

Status

NSS
Libraries
--
major
RESOLVED INVALID
8 years ago
8 years ago

People

(Reporter: Gunnar Haslinger, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla Firefox 3.0.2 and all versions up to 3.0.15, 3.5.5, 3.6beta1

We currently use Firefox 3.0.1 with two types of Smartcards (2 different PKCS11
DLLs).

Firefox 3.0.1 - both PKCS#11 Drivers work correct => Fine, no Problems!

We want to Upgrade to a more recent Version => Problem: PKCS#11 Smartcard Support does not work any more.

Firefox 3.0.15 => Certificate does not show up
Firefox 3.5.3, 3.5.5 => Certificate does not show up
Firefox 3.6 Beta 1 => Certificate does not show up

The Problem in Detail:
Security Devices => Load PKCS#11 Module => works fine. 

Both, our "acpkcs11.dll" which supports "Austria Card - ACOS Cards" and "pkcs201n.dll" which is provided by "Utimaco Safeware AG" load correctly, show up the Cardman, can load the Smartcard ("Log In" with PIN-Check and "Log out", showing the right serial Number of the Card and doing the Pin-Check as expected).

But: The Certificate is not listed in "View Certificates" => "Your
Certificates".

And: The certificate is not usable - when trying to access an HTTPS/SSL Website
which enforces certificate authentication the Error Code
"ssl_error_handshake_failure_alert" shows up after entering the Smartcard-PIN.

With Firefox 3.0.1 everything works fine.

Which Information could we provide to support you solving this Problem?

Reproducible: Always

Steps to Reproduce:
Start Firefox (tested with 3.0.15, 3.5.5 and 3.6beta1)
Problem does NOT exist with 3.0.1 - an other User reported the Problem started with Firefox 3.0.2

Tools -> Ooptions -> View Certificates
the Pin of the Smartcard will be asked => Provide correct PIN

Actual Results:  
Certificate does not show up in "Your Certificates" and therefore cannot be used

Expected Results:  
in Firefox 3.0.1 the Certificate shows up correct and can be used to authenticate against HTTPS/SSL Websites

Could provide you an Logfile captured by following these steps
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html
(Reporter)

Comment 1

8 years ago
Created attachment 411717 [details]
PKCS#11 Logfile made with Firefox 3.5.5

Set Environment as described here:
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html

set NSPR_LOG_MODULES=nss_mod_log:5
set NSPR_LOG_FILE=firefox.log
set NSS_DEBUG_PKCS11_MODULE=Austriacard PKCS#11

*) Start Firefox
*) try to open a HTTPS URL which requires Certificate authentication
*) provide PIN for Smartcard

Error Code: "ssl_error_handshake_failure_alert" shows up after entering the Smartcard-PIN.

comments: Logfile was Censored by substituting some String I don't like to set public by "XXXXXXXX"

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please attach to this bug a copy of each of the X.509 public key certificates 
on your smart card.  A zip file containing those certificates would be good.
(Reporter)

Comment 3

8 years ago
Created attachment 412170 [details]
As requested, the X.509 public key of a sample Smartcard-Certificate

As I don't want this ZIP-File "world readable" by Webcrawlers it is password protected. Password is: "1234"
(Reporter)

Comment 4

8 years ago
Is there anything else I can do? Any Ideas? If this currently is an unsolvable problem I have to tell my boss to switch to an other (working) browser like IE. Is there any commercial support for such Firefox-Problems/Bugs I could contact?

Comment 5

8 years ago
We have the same problem with personal certificates on Lithuanian eID cards - certificates are not displayed in "Your Certificates" tab. Moreover there is another problem with Firefox on Linux:

Selecting Edit-Preferences-Advanced-Encryption -> Pressing button "Security 
Devices". Selecting the device and pressing button "Log in" -> Produces the 
message: "Please authenticate to the token. Authentication method depends on 
the type of your token. Token:           ". There is no input field for PIN 
entry, just the said message. After closing this message Firefox becomes 
unresponsive.

whereas Firefox on Windows:
Selecting Tools-Options-Advanced-Encryption -> Pressing button "Security 
Devices". Selecting the device and pressing button "Log In" -> Prompt for 
PIN appears. Entering PIN ->Log in successful.

Lithuanian eID's use Gemalto pkcs#11 module. Gemalto Classic Client 5.1 for Linux User Guide claims software compliance with Firefox 2.0 and 3.0
Still I can't check if the problem disappears if Firefox 3.0.1 is used (as stated by Mr. Haslinger), as I don't know where to get this particular version (both for Windows and Linux) from.

Comment 6

8 years ago
(In reply to comment #4)
> Is there anything else I can do? Any Ideas? If this currently is an unsolvable
> problem I have to tell my boss to switch to an other (working) browser like IE.
> Is there any commercial support for such Firefox-Problems/Bugs I could contact?

Just some observations: The certificate you attached to the bug uses and MD5 hash. 

Is the root of this certificate in your Authorities store (and any CA certificate chaining to the root)? Is it also on the smart card? If the root is also on the smart card, try to remove it from there (or try to edit the trust bits). Note, that when editing the trust bits of the root which is on the smart card, the change will disappear after renewed login).
The PKCS#11 logfile shows pretty clearly that the PKCS#11 module (library, DLL)
in use reports to Firefox that it does not recognize the standard PKCS#11
certificate attribute types CKA_ISSUER and CKA_SERIAL_NUMBER.  Perhaps its 
conceivable that some older versions NSS used in older versions of Firefox 
failed to check for these errors, but now NSS checks and sees these errors.

So, in effect, the log shows that the PKCS#11 module reports that it has one 
certificate, but when asked for the issuer name and serial numbers for that 
certificate, it answers that it doesn't even know what those things are.  
It doesn't say "they're empty".  It says "what are those?".  
That's a bug in the PKCS#11 module.  Not much Firefox can do about it. 

This doesn't seem to be a Firefox bug as much as a bug with the module.
From Mozilla's perspective, that makes this an invalid Firefox/NSS bug.

Here's the relevant log excerpt.

836[2453900]: C_GetAttributeValue
836[2453900]:   hSession = 0x1
836[2453900]:   hObject = 0x2
836[2453900]:   pTemplate = 0x3b4c830
836[2453900]:   ulCount = 10
836[2453900]:     CKA_CLASS = CKO_CERTIFICATE [4]
836[2453900]:     CKA_TOKEN = CK_TRUE [1]
836[2453900]:     CKA_LABEL = "USWCSP X.509 Certificate" [24]
836[2453900]:     CKA_CERTIFICATE_TYPE = 00000000 [4]
836[2453900]:     CKA_ID = 55544943535002534944 [10]
836[2453900]:     CKA_VALUE = 308204113082037AA00302010202023C62300D06092A8648 [1045]
836[2453900]:     CKA_ISSUER = [0x0] [0]
836[2453900]:     CKA_SERIAL_NUMBER = [0x0] [0]
836[2453900]:     CKA_SUBJECT = E=XXXX@XXXXXXXXXXXXXX,CN=XXXX,OU=XXXXXXXXXXXXXX,O=XXXXXXXXXXXXXX,L=Vienna,ST=Vienna,C=AT [133]
836[2453900]:     CKA_NETSCAPE_EMAIL = [0x0] [0]
836[2453900]:   rv = CKR_ATTRIBUTE_TYPE_INVALID
836[2453900]: C_GetAttributeValue
836[2453900]:   hSession = 0x1
836[2453900]:   hObject = 0x2
836[2453900]:   pTemplate = 0x3b4c878
836[2453900]:   ulCount = 1
836[2453900]:     CKA_ISSUER = [0x0] [0]
836[2453900]:   rv = CKR_ATTRIBUTE_TYPE_INVALID
836[2453900]: C_GetAttributeValue
836[2453900]:   hSession = 0x1
836[2453900]:   hObject = 0x2
836[2453900]:   pTemplate = 0x3b4c878
836[2453900]:   ulCount = 1
836[2453900]:     CKA_ISSUER = [0x0] [0]
836[2453900]:   rv = CKR_ATTRIBUTE_TYPE_INVALID
836[2453900]: C_GetAttributeValue
836[2453900]:   hSession = 0x1
836[2453900]:   hObject = 0x2
836[2453900]:   pTemplate = 0x3b4c884
836[2453900]:   ulCount = 1
836[2453900]:     CKA_SERIAL_NUMBER = [0x0] [0]
836[2453900]:   rv = CKR_ATTRIBUTE_TYPE_INVALID
836[2453900]: C_GetAttributeValue
836[2453900]:   hSession = 0x1
836[2453900]:   hObject = 0x2
836[2453900]:   pTemplate = 0x3b4c884
836[2453900]:   ulCount = 1
836[2453900]:     CKA_SERIAL_NUMBER = [0x0] [0]
836[2453900]:   rv = CKR_ATTRIBUTE_TYPE_INVALID


In comment 5, antanas.zivatkauskas@vrm.lt wrote:
> We have the same problem with personal certificates on Lithuanian eID cards

You have a problem with somewhat similar symptoms.  It may or may not have
the same cause as this bug.  Please file a separate bug and attach the logfile 
obtained with your PKCS#11 module, following the steps in the tech notes article cited in comment 0 above.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
The change that made NSS detect the previously undetected missing PKCS#11 
attributes was a fix for previously reported bug with another PKCS#11 module.
Bug 434099 -  NSS relies on unchecked PKCS#11 object attribute values

This code is now working as intended.
An examination of the cert in the zip file attached above shows that the 
cert in question DOES have both an issuer name and a serial number. 
 Serial Number: 22505 (0x57e9)
 Signature Algorithm: PKCS #1 MD5 With RSA Encryption
 Issuer: "E=xxx@xxxxx.xxxx.at,CN=xxx,OU=XXXXXXX,O=XXXX,L=Vienna,ST=Vienna,C=AT"

So, the fact that the PKCS#11 module does not recognize these attribute types
is purely a failing of the PKCS#11 module, not of the certificate.
You need to log in before you can comment on or make changes to this bug.