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
