Incorrect caching of certificate data after canceling a cert import operation.

VERIFIED INVALID

Status

Core Graveyard
Security: UI
VERIFIED INVALID
15 years ago
2 years ago

People

(Reporter: Hodor!, Assigned: Stephane Saux)

Tracking

1.0 Branch
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

When importing a certificate to Mozilla via the Preferences:Privacy &
Security:Certificates dialogs, cancelin an import request after examing the
certificate may result in improper caching of the certificate data.

In the testing I've done so far this bug is only evident when trying to import
another certificate with the same common values (i.e. CommonName, Country,
Providence, etc all match).

Given two certificates with the same common properties BUT DIFFERENT
EXPIRATIONS, Mozilla will always see the second certificate import attempt as
equivalent to the first. Yes, this is very confusing to explain, I'm sorry.

Reproducible: Always

Steps to Reproduce:
Ok, go get your favorite bevarage, this is going to take a while...

1. Generate two self-signed certificates with openssl. Give them the same common
values for Country Name, Providence Name, Locality Name, Organization Name,
Organizational Unit, Common Name, Email Address, etc. Generate one certificate
with an expiration time of four years (1460 days) and one with an expiration
time of ten years (3650 days).

(Note: For info on generating certs look at
http://www.post1.com/home/ngps/m2/howto.ca.html)

2. Make note of the MD5 fingerprint of each self-signed certificate. They should
differ noticably.
(Note: openssl x509 -noout -fingerprint -in name-of-certificate-file-goes-here)

3. Launch Mozilla and open up the preferences. Select Privacy and Security, then
select Certificates. Click on the Manage Certificates button

4. Click on the Authorities tab of the Certificate Manager window

5. Click the Import button

6. Select the first of your self-signed certificates (should be a file with a
.pem extension) and click Open

7. In the Downloading Certificate window that appears, click the View button

8. In the Certificate Viewer window, General tab, you should see the info for
the certificate including it's MD5 fingerprint. The fingerprint should match
what you had previously computed. Also make note of the Expires On date.

9. Click the Close button in the Certificate Viewer window.

10. Click the Cancel button in the Downloading Certificate window.

11. Go back to the Certificate Manager window (should still be open and on the
Authorities tab). Click the Import button.

12. Select the SECOND of your self-signed certificate files (they should of
course have different names) and click Open.

13. In the Donwloading Certificate window, click the View button

14. In the Certificate Viewer window, General tab, make note of the Expires On
and MD5 Fingerprint values.



Actual Results:  
When viewing the second self-signed certificate through the importation process,
the fingerprint displayed is wrong. In addition, the expires on date is wrong.
The fingerprint is that of the FIRST certificate that was examined but NOT imported.


Expected Results:  
Should have diplayed the correct certificate data including fingerprint, expirey
dates, etc.


I have not repeated these tests with variations on length of certificate
expiration or importation into other parts of the Certificate Manager.
Theoretically such variations would make no difference as presumably Mozilla
uses exactly the same functions for importing a certificate regardless.

I did confirm that generating a new certificate with ALMOST identical common
values (i.e. just a difference in system name and e-mail address) did NOT
produce this bug. Presumably the issue is trigged only when the certificates are
for the same common name though I haven't verified that either.

Notes:
  o Test system running RedHat 8.0
  o Generated test certificates with "OpenSSL 0.9.6b [engine] 9 Jul 2001" on a
seperate RedHat 8.0 system (PC platform)
  o All certificates were RSA, key length of 1024 bits
  o Did not perform actual import operation to see what Mozilla would do with
second certificate.
  o May or may not have potential for screwing with a users certificates, thus
checked the Security issue box for now.
(Reporter)

Comment 1

15 years ago
May or may not be related to bug #197316

Comment 2

15 years ago
i'm removing the security flag, i don't see any reason to keep this report
confidential.
Assignee: mstoltz → ssaux
Group: security
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: carosendahl → bmartin
Version: Trunk → unspecified

Updated

15 years ago
Version: unspecified → 2.4

Comment 3

15 years ago
You do not mention whether the "serial number" of both certificates is
identical, too.

This is never allowed by the specifications of the certificate standards.
Using a duplicate serial number is STRICTLY forbidden.

The behaviour of Mozilla when doing this is undefined.

I'm marking this as invalid.
Please reopen in case your serial numbers are different.
Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

15 years ago
May well have been a case of identical serial numbers. Will double-check and update.

Comment 5

15 years ago
Verified.
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.