Thanks Bob, You can find the certs at https://powhatan.iiie.disa.mil/pki-pke/interoperability/downloads/unclass-dod_approved_xternal_pkis_v2-4.zip under Treasury_SSP OCIO certs.
The crlutil throws following error: Importing OCIO_CA2.crl into cert8.db crlutil: unable to import CRL: The CRL for the certificate's issuer has an invalid signature. Any suggestions? Thanks S On Thursday, February 28, 2013 1:59:37 PM UTC-5, Robert Relyea wrote: > On 02/27/2013 06:26 AM, marathi...@gmail.com wrote: > > > On Monday, February 25, 2013 1:44:15 PM UTC-5, Robert Relyea wrote: > > >> ----- Original Message ----- > > >> > > >>> Hello, > > >>> I am using NSS 3.12.6. I am trying to add different certs (with > > >>> slightly) different nickname in my db using certutil. However I > > >>> found, that certutil adds them with the same nick name. I have about > > >>> 130 certificates in database and it is happening on at least 5 > > >>> different certificates. What I am doing wrong? > > >> > > >> > > >> Probably nothing. NSS, for better or worse, does not map nicknames to > >> certs, but nicknames to subjects. All certs with the same subject will > >> have the same nickname. If you are using the old database (dbm), that > >> semantic is built into the database format. If you are using sqlite, it > >> maybe be possible to trick NSS into setting a different nickname on the > >> certificate, but even so, NSS will then reference both certs with both > >> nicknames. > > >> > > >> > > >> > > >> The theory was certs with the same nickname mapped to the same > >> personality. NSS would use the cert that was most appropriate for the > >> operation (auth certs for SSL client auth, signing certs for object > >> signing, etc). In practice applications typically 'know' which cert to > >> use, so the semantic can get in the way, but it's already built in:(. > > >> > > >> > > >> > > >> bob > > >> > > >> > > >> > > >> > > >> > > >>> certutil -d<PATH TO DB> -A -i 1-OCIO_0x46EACCEC.cer -n > > >>> '1-OCIO_0x46EACCEC' -t "c,c,c" > > >>> Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": > > >>> -bash-3.2$ certutil -L -d<PATH TO DB> | grep -i OCIO > > >>> 1-OCIO_0x46EACCEC c,c,c > > >>> -bash-3.2$ certutil -d<PATH TO DB> -A -i 1-OCIO_0x4A61D147.cer -n > > >>> '1-OCIO_0x4A61D147' -t "c,c,c" > > >>> Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": > > >>> -bash-3.2$ certutil -L -d<PATH TO DB> | grep -i OCIO > > >>> 1-OCIO_0x46EACCEC c,c,c > > >>> 1-OCIO_0x46EACCEC c,c,c > > >>> -- > > >>> dev-tech-crypto mailing list > > >>> dev-tech-crypto@lists.mozilla.org > > >>> https://lists.mozilla.org/listinfo/dev-tech-crypto > > > Thanks Bob, > > > > > > This makes perfect sense. Unfortunately, we had few intermediate certs > > which have the same subject name, and are lumped into one. We are still > > using the old dbm database. So here are few questions: > > > > > > 1) I know with one nickname for multiple auth certs, we run into crl issues > > (crlutil) > > What kind of issues? CRL's themselves are tied to Subject name of the > > CA. If you have 2 intermediate CA certs with the same subject, they will > > have the same CRL (If the Intermediates have separate keys, then there > > is a key authority identifier that that can be used to distinguish > > between the two. Is this your case. It may be a problem with NSS CRL > > handling rather than a single nickname). If they intermediates of the > > same key, you need to issue a single combined CRL since certs issued by > > one intermediate is indisiguishable from certs issued by the other. > > > > If you are taking about end user certs with the same nickname, this > > doesn't seem to make sense since CRL's work on issuer/SN and the > > individual auth certs may have the same subject, but the will have > > different serial numbers. > > > 2) Will this affect actual authentication or hintlist? > > I'm not sure I understand the question. > > > 3) Is there a easy way to migrate to sqlite (we are using 3.12.6 due to > > FIPS compliance). or is there any end of life cycle planned for dbm? > > That migration should be a problem. Simply refer to your NSS database as > > sql:{path} instead of {path}. For NSS tools, you can do that with the -d > > option (certutil -L -d sql:./mydatabase rather then certutil -L -d > > ./mydatabase). You can upgrade an old DB to sqlite with certutil -K -X > > -d sql:{path to old db}). Unfortunately, that is unlikely to help you > > since NSS at the higher level still enforces the nickname->subject > > mapping (you just wind up with 2 nicknames mapping to the the same subject). > > > > bob > > > > > > Appreciate your help > > > > > > M -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
