Closed Bug 232347 Opened 19 years ago Closed 19 years ago
OCSP Responder Certificates Expiring
User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 Verisign and RSA OCSP Responder certificates delivered with Mozilla expire July and August 2004. These are certificate authority (CA) certificates. While there is no problem yet, the certificates should be updated for the next release of Mozilla (before they expire). Also, for those users who do not immediately update to the next version of Mozilla, information should be provided on how to obtain new certificates to import. The affected certificates are: For Verisign -- Class 1 Public Primary OCSP Responder (expires 3 Aug 04) Serial # 2B:68:D4:A3:46:9E:C5:3B:28:09:AB:38:5D:7F:27:20 Class 2 Public Primary OCSP Responder (expires 31 Jul 04) Serial # 09:46:17:E6:1D:D8:D4:1C:A0:0C:A0:62:E8:79:8A:A7 Class 3 Public Primary OCSP Responder (expires 3 Aug 04) Serial # 2E:96:9E:BF:B6:62:6C:EC:7B:E9:73:CC:E3:6C:C1:84 For RSA -- Secure Server OCSP Responder (expires 3 Aug 04) Serial # 00:FF:45:D5:27:5D:24:FB:B3:C2:39:24:53:57:E1:4F:DE Reproducible: Always Steps to Reproduce: 1. Select Edit > Preferences 2. Select Privacy & Security > Certificates 3. Select the Manage Certificates button 4. Select the Authorities tab 5. Select any of the CA certificates I indicated 6. Select the View button Actual Results: Under Validity, note the Expires On date is in the summer of 2004. Expected Results: Under Validity, the Expires On date should be some later year. First answer the question: Are OCSP certificates still used? All other CA certificates have expiration dates far in the future. If OCSP certificates are no longer used, they should be deleted from the next Mozilla version.
Assignee: security-bugs → kaie
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bmartin
Version: Trunk → 2.4
http://www.verisign.com/support/vendors/ocsp.html for lack of a better url it seems ocsp isn't dead, although it might be the case that our impl won't work...
Nelson, is this not an NSS issue?
John, No, these are intermediate CA certs, not root CA certs. If these intermediate CA certs are in the cert DB, I'm not sure why. It is both necessary and sufficient for NSS to have the ROOT of the chain trusted. The OCSP responder will send out a complete cert chain. When the old intermediate CA certs expire, the server will send out the new ones, and NSS should honor the new ones that it received in the chain over the ones it had before in the cert DB. I believe there is another bug that reports this same thing, that has been closed invalid. This bug should duplicate that one.
Certificates on the Authorities tab of the Certificates Manager window expire in less than six months. Before this bug is closed as a duplicate of some other INVALID bug, the following questions should be addressed: 1. If those certificates indeed belong there, then will it not be a bug for expired certificates to be included with any version of Mozilla released after 3 Aug? And if so, when should that bug be fixed if not before the certificates expire? 2. If those certificates do not belong there, then why is their presence not a bug? 3. And finally, since Mozilla 1.6 is likely to still be in some use after 3 Aug (since we know that many business installations and some home installations will not upgrade immediately when Mozilla 1.7 or even Mozilla 1.8 is released), what mitigation will be appropriate for Mozilla 1.6 (according to whether the certificates belong or not) and how will that be documented?
The presence of these certificates after their expiration dates causes no problem. These certs have no trust flags. They're just extra certs. Users who have cert8.db files that were derived from old cert7.db files made prior to moz 1.3 may also have these certs in their cert7 and cert8.db files. Removing these certs from the built-in list is no more urgent than remvoing them from users' cert8.db files. No mitigation is necessary. Think of them as dead code (after their expiration dates). My *guess* is that AOL/Netscape had a contractual obligation to include these certs in Netscape branded products, and they are left-overs from the era in which AOL/Netscape controlled mozilla's built-in trusted root list (as are all the certs presently in Moz's built-in trust list). Once bug 233453 is resolved and a new public mozilla foundation policy is in place governing which certs belong in the built-in list, then if it is determined that these certs do not belong there, they should be removed. In the meantime, I see no reason to try to urgently remove them prior to their expiration dates. I'd say that they should be removed in the next release thereafter (again, assuming that bug 233453 isn't resolved sooner).
I'm marking this bug invalid. The presence of these certs in the built-in list is causing no failures, and is apparently as was intended at the time they were added. When bug 233453 is resolved, I am sure that ALL the certs in the built-in list will be reviewed for consistency with that new policy. And I expect there will be big changes then. :) Until then, we have no basis upon which to remove these certs, other than if they were causing a problem (e.g. false positive or false negative cert chain validation), which they are not, and will not, even after they expire.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Depends on: 233453
Resolution: --- → INVALID
While my concerns were not addressed in the form I expected, I concur that comment #5, comment #6, and bug #233453 are collectively sufficient to mark this closed.
You need to log in before you can comment on or make changes to this bug.