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.
May or may not be related to bug #197316
i'm removing the security flag, i don't see any reason to keep this report confidential.
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: carosendahl → bmartin
Version: Trunk → unspecified
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
May well have been a case of identical serial numbers. Will double-check and update.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.