Closed Bug 311863 Opened 19 years ago Closed 8 years ago

certificate chain validation fails whenever a smartcard is present

Categories

(Core :: Security: PSM, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: adriano.santoni, Unassigned)

Details

(Whiteboard: [kerh-noi])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.12) Gecko/20050919 Firefox/1.0.7

Whenever a smartcard is inserted and detected by the browser, certificate chain
construction and/or validation fails on all client and server certificates. At
this point, SSL authentication fails regardless of the position (smartcard,
software) and number of SSL client certificates available. More detailed
explanation below. After extracting the smartcard, certificate chains are
reported back as valid and everything resumes working. This seemingly affects
every version of Firefox, Mozilla and Netscape. I am not sure if it is a PSM or
a NSS problem. At this time, therefore, smartcards are not really supported.
This is a major problem, affecting an important functionality of the browser.

Reproducible: Always

Steps to Reproduce:
1. Setup, or find, a web server with mandatory SSL client authentication.
2. Get an SSL client certificate ("C1") and the corresponding private key from
your preferred CA, as a PKCS#12 file.
3. Ensure the CA is trusted by the web server for SSL client certificates.
4. Also install the CA into the browser as a trusted CA for all purposes.
5. Now import the SSL client certificate and key from the P12 file into the
browser "software token". Remove all other personal certificates, if any.
6. Check that your certificate is validated by the browser and regarded as a SSL
client certificate.
7. Now try accessing the web server; the browser will as you to enter the master
password, then, depending on your settings, the browser may ask you to confirm
using the SSL client certificate.
8. A this point, the SSL client authentication phase will be carried out and you
will be able to access the web server.

9. Now, get a smartcard (of your preferred type) containing a private key and
the corresponding SSL client certificate ("C2") obtained from the same CA above.
Ensure the smartcard and the certificate work well, by other means.
10. Configure the smartcard's PKCS#11 library into the browser.
11. Now insert the smartcard into the reader, then access the certificate
manager from the Options dialog. The browser will ask you to enter the PIN of
the smartcard.
12. From the certificate manager window, you will see that neither the C1 not
the C2 certificates are validated. The certificate manager says "Issuer
Unknown". From now on, until you extract the smartcard, SSL client
authentication will not work, as the browser "sees" no valid certificates available.
13. Until you keep the smartcard inserted, not even the server certificate is
validated, notwithstanding the issuing CA has been imported and trusted.

14. Extract your smartcard and everything come back working.

Actual Results:  
See above.

Expected Results:  
Obviously, the PSM (or NSS?) must not behave that way. The certificates stored
into the software token and which are trusted and valid must not be affected by
smartcard insertion/removal. Certificates stored into a smartcard must be
reported as valid if they are indeed so. SSL server certificate validation must
not be affected by smartcard insertion/removal. Smartcard-based SSL client
authentication must be supported. At this time, it is definitely broken.


While doing the test explained above, the browser frequenly crashes on exit. The
described behaviour does not change if you start the browser from a different
profile, if you delete the certificate database, if you change the browser
version, if you change the underlying Windows version, if you change the
smartcard, if you change the certificate profile, etc. All certificates used in
the test explained above are definitely valid, well-formed, with a standard
profile, and work fine with the Internet Explorer.
can you please specify the specific vendors (and models for hardware) for each
item that you've mentioned here? if you've used multiple vendors or received
multiple models, could you please indicate them here too?
(In reply to comment #1)
> can you please specify the specific vendors (and models for hardware) for each
> item that you've mentioned here? if you've used multiple vendors or received
> multiple models, could you please indicate them here too?

The problem shows up with:
- browsers: Firefox 1.0.5, Firefox 1.0.7, Netscape 7 & 8, Mozilla 1.5, Mozilla
1.3, WamCom;
- web server: Apache v2 with latest mod_ssl, Microsoft IIS, Tomcat v5;
- smartcards: Rainbow iKey3000, Eutron Cryptoidentity, Oberthur cards, Siemens
cards, etc.
- PC platform: WinXP, Win2K

The old Netscape 4.7+ browsers do not have this problem, but I suppose this is
not really a clue.

I am told that people using Aladdin eToken devices do not experience this
problem, so I am not excluding that it also depends on the device (more
precisely: on the PKCS#11 library used to interface the device). 

If that is really the case, then I would conclude that the browser's assumptions
on the behaviour of the PKCS#11 library are not fully obvious for PKCS#11
implementors, as there is a sizeable number of devices with do work fine with
other P11-based applications but not with Mozilla/Firefox.

Is there a PKCS#11 developers' guidelines for Mozilla/Firefox, as it used to
exist in the past for the old Netscape browser?

Whiteboard: [kerh-noi]
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
QA Contact: psm
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
Target Milestone: mozilla1.9alpha1 → ---
At this point, there's not much value in keeping this bug around. If this is still an issue, feel free to re-open (it would be helpful to know which pkcs#11 library you're using if so).
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.