Michael, Can you make available to me the cert8.db file and the "nokey" p12 files exactly as they were before you did the fateful certutil -D step? If so, I'm interested in trying to track this down.
I have a test for you to try that *MAY* (or may not) prove to be a solution for you. I believe you're using cert8.db and key3.db files. Let me suggest that you start over with cert9 and key4.db files, which are sqlite3 NSS DB files. It's easy to do with NSS 3.12.x. You can simply set the environment variable NSS_DEFAULT_DB_TYPE to "sql" (without the quotes), or you can prefix "sql:" to the DB directory name argument (usually -d) EVERYWHERE it is found, in every program that uses the DB. I think you may find that the problems you had just go away when using cert9.db files ... or maybe not. You're absolutely right that the "bad database" errors don't necessarily, or even usually mean database is corrupt. They usually mean that a read or delete attempt failed because the record was not found, or that a write attempt failed because a matching record WAS found and doing the write would have created a duplicate. Most of the time, it just means "record not found". But databases have been known to become corrupt and when they do, those "not found" errors happen a LOT, which is how they came to be (mis)identified as "bad database" errors. In your case, I think you did achieve database corruption. When you get to the state were certutil -L shows a cert with a nickname (say "server") but certutil -L -n server says "not found: bad database", that really is a bad database. I think the pk12util step to import the "nokeys" p12 file may have caused that corruption, and if so, then I'm very interested in fixing it. > Just wanted to raise an issue on this list before opening a bugzilla > ticket on it but I seem to have run into a circumstance under which > deleting a certificate from the NSS database ends up doing the wrong > thing with some real confusion resulting that looks like a corrupted or > bad database (but seems to be just a poor error message). If you file the bug now, the most accurate thing you can really say is "cert8 DB seems corrupt after pk12util import of p12 file with no keys". NSS requires every cert in the DB to have a nickname or email address that it can list out in certutil -L. For cert8 DB, these are actually stored in separate DB tables. Every cert's subject name should appear in exactly one table, nickname or email-address. The command certutil -A adds a record to the nickname table. Certutil -E adds a record to the email address table. Looks like you got a cert whose subject name appears in both tables. Bad news. When it was deleted, one of those two table entries (the nickname) was deleted with it, and the other (email) became an orphan. pk12util has code that will create a nickname to complete a cert import. It will do this if either (a) a cert in a p12 file has no nickname, or (b) the cert being imported has a "name collision" with a cert already in the DB. I can't be certain which of those applies to you without seeing the files. Another question is: where did the email table entry come from? As I recall, pk12util resolves the above issues by creating a nickname, not by creating an email record, but something created an email record. In any case, cert9 may just clear this all up, so give it a try. > Sequence of things I did and the results are below my signature block > with a few comments in square brackets... I figure this one is heading > for bugzilla one way or the other but wanted to hear others thoughts on > it first. > > Oh... This is on Fedora 13 with nss-util 3.12.8 as well as Fedora 14 > with nss-util 3.12.9. Thanks for all the great details. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
