This is a replacement for the internal Netscape bug http://scopus/bugsplat/show_bug.cgi?id=77005 . The gist of the previous report is: Here's the steps to corrupt cert7.db: 1. I fetched the cert for firstname.lastname@example.org from ldap (serial #51) 2. I opened an email signed with a newer cert for lord, serial #04:F7. This step over-writes the cert for email@example.com in cert7.db. 3. I search for firstname.lastname@example.org in ldap again. It says it finds one, then when I view email@example.com, I still see #04:F7...so far so good. 4. I delete firstname.lastname@example.org's cert. It asks if I want to delete #04:F7, I confirm, and it deletes it. 5. email@example.com still shows up in the list, but I can't view, delete, or verify this entry. Database is corrupt. Bummer. -cdn The solution to this bug will come with replacing the existing permanent cert db with a pkcs#11 module; when that is done we should confirm that related data is stored properly and the above sequence of steps doesn't screw up the token.
We should look at this bug in 3.1 or 3.2.
Assignee: lord → relyea
Target Milestone: --- → 3.1
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Bob, Can you confirm this is resolved and close if appropriate ?
QA Contact: bishakhabanerjee → jason.m.reid
This is still a problem today, on WinXP, even though we now have a PKCS#11 module. My test was: - Have an old signed message from Lord with an old (now expired) cert, cert is already in DB (signed message has previously been read). - get new signed message from Lord with new unexpired cert, same email address. - go into cert manager and delete old expired cert. - cert manager shows that it sees new cert, but attempt to send encrypted message says no cert found for his email address. Workaround was to delete all certs for Lord, then visit newest email which then reimported newest cert for Lord.
Priority: P3 → P2
Target Milestone: Future → ---
I can not reproduce this bug. In comment 4 Nelson no longer mentioned a cert db corruption. I believe this problem is fixed. Nelson talked about a different problem, not being able to send encrypted mail, because receipient cert is not found. However, he mentions a workaround is possible. I believe, the cause for "not found" is bug 335021. I tried to reproduce Nelson's description in comment 4. I prepared a cert database, by setting my computer's clock to a date in the past, so reading an old signed message from lord imports the cert (as we usually don't import expired certs). With this prepared cert db as a starting point, I can reproduce the following steps: - start - open cert manager - I have one cert (only) from lord, expired - close cert manager - I open a recent signed message from lord - I go to cert manager - now I see two certs from lord - I delete the old cert - I see one cert from lord - close cert manager - compose a message to lord - hit security button - security info tells me, valid cert for lord is available In addition I tried - I go to cert manager - I delete the new cert - close cert manager - open cert manager - lord's cert is still gone - compose encrypted message to lord - not possible, cert not found I conclude, cert DB corruption is not reproducible, original bug WORKSFORME. I can't reproduce Nelson's problem in comment 4, WORKSFORME. If Nelson is still able to reproduce the "not found", I hope, you will no longer be able to reproduce, once we use the hotfix from bug 335021.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.