Hey, I've been massively distracted in other projects so I'm way behind in this issue...
On Sat, 2011-02-12 at 22:33 -0800, Nelson B Bolyard wrote: > On 2011-01-25 13:07 PDT, Michael H. Warfield wrote: > > > [...] Instead of having a cert in the > > database with the name I specified in creating the .p12 file, I ended up > > with a cert in the database with the name of the E-Mail address in the > > cert. Not sure where that problem is (openssl or the pk12util import). > > But, I went to delete that certificate and that's when the fun begun. > > "certutil -D -n postmas...@wittsend.com" ran without error but the cert > > was still there. Run it again and you get this error: > > > > [root@romulus ipsec.d]# certutil -D -n postmas...@wittsend.com -d . > > certutil: could not find certificate named "postmas...@wittsend.com": > > security library: bad database. > > > > That's also when I noticed I was missing at least one other cert. > I was unable to reproduce any of this with the cert DB you sent me. > Before I deleted the cert with that command above, the cert DB was OK, > not corrupted, and after I deleted it, it was also OK. The cert I had > specified, and its nickname record AND its email record were all deleted > from the DB, leaving it in a consistent state. A second delete attempt > produced the same error message you saw, but didn't modify the DB at all. > I tried with both certutil and libs from NSS 3.11.latest and 3.12.latest > and got the same results both ways. > I have these thoughts about the different behaviors that you and I > experienced. > 1) Maybe you had another program that was also holding the DB files open > at the same time you did the certutil -D command. Nope. Absolutely not. This was done in an isolated test directory which nothing else even referenced. > 2) IINM, You had the private key for some certs in your key3.db by virtue > of having used pk12util to import one or more, and I didn't. That might > have made a difference. Ah... Now we may have something here. I'm doing a pure import. Nothing original was created in the NSS database. Everything was imported into it. Take that as a premise. It is fundamental. Start with a database and import everything. Create nothing new within NSS itself. This is, unfortunately, a result of Fedora's decision to convert OpenSwan to use NSS. It's caused a number of people a great deal of grief. People are trying to import existing configurations into NSS and the documentation, quite frankly, doesn't work in many cases. People with established X.509 cert setups that have been working for years don't want to recreate everything from scratch. It's unfortunate that this was poorly planned with no concrete upgrade / transition mechanism in place before doing this and abysmal documentation. > 3) It's possible that the original cert DB you had was in some state of > corruption, and the cert DB you reconstructed for my testing was not > corrupted. No. I took snapshots of the database as I performed those actions. You literally got what I had at each step of the process. Nothing was a reconstruction. I'm a practiced diagnostician and forensic investigator. > Unless and until I can reproduce the behavior you saw, I won't be of much > help in resolving it. Sorry. :-/ Sounds like I need to drop back a couple of steps then and give you the whole process, step by steo, from the very beginning of the creation of the database to the corruption. This I had not done. I'll go back and set those scenarios back up and reproduce them from the "mkdir" forward and provide you with the full import data (including the creation of the pk12 files using openssl). It may take some time. My schedule is full and I tend to get distracted. > -- > /Nelson Bolyard Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=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!
signature.asc
Description: This is a digitally signed message part
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
