Warning: This message has had one or more attachments removed Warning: (gorgon10.wittsend.com.p12). Warning: Please read the "WittsEnd-Attachment-Warning.txt" attachment(s) for more information.
Hey hey...
On Sun, 2011-01-30 at 04:12 -0800, Nelson B Bolyard wrote:
> 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.
Attached. Did two runs. Same p12 file. One with a cert8.db and one
with a cert9.db. The other certs in the cert?.db files were imported
with pkcs12util if they had keys or this if I did not have a private
key:
certutil -A -n ${BASENAME} -t u,u,u -i ${CERT} -d ${TARGETDIR}
It was only the gorgon10 cert that I was importing using a .p12 file
just to test the methodology.
> 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.
This got a little strange. Working with my full database of certs, I
was able to reproduced the problems with both. So, it did not fix the
problem. I set up a test setup with just a handful of certs and a
non-production test "private key" (gorgon8) and reran the tests. This
time, the cert8 still failed but the cert9, while it still imported the
cert with the wrong name, seem to delete the errant cert properly. So
that's a bit confusing but I don't believe it's behaving properly
either.
If you want, I can also supply you with the cert?.db files from the full
run.
> 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
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "gorgon10.wittsend.com.p12" is on the list of unacceptable attachments for this site and has been replaced by this warning message. If you wish to receive a copy of the original attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Sun Jan 30 12:18:41 2011 the virus scanner said: MailScanner: Attempt to hide real filename extension (gorgon10.wittsend.com.p12) Note to Help Desk: Look on the WittsEnd () MailScanner in /var/spool/MailScanner/quarantine/20110130 (message p0UHId0R012599). -- Postmaster Thaumaturgy & Speculums Technology www.wittsend.com For all your IT requirements visit: http://www.transtec.co.uk
signature.asc
Description: This is a digitally signed message part
-- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
