On 10/18/2016 11:16 AM, Rob Crittenden wrote:
It looks like when multiple NSS databases are initialized using
NSS_InitContext() the nicknames can take multiple forms depending on
order of initialization. Using the multinit program and three NSS
certificate databases with identical nicknames I saw the following
names associated:
(first initialized) Server-Cert
(second initialized) NSS Certificate DB:Server-Cert
(third initialized) NSS Application Token 00000005:Server-Cert
Is this expected/dependable behavior?
Short answer: yes.
So the first and second are identical (assuming your built in database
is named 'NSS Certificate DB'). The name would be different yet in FIPS
mode, and different if NSS is initialized by the application with it's
own database name.
What is happening is the actual token name is different. When NSS is
first initialized, it initialized with it's default token, which doesn't
need a separate 'token' identifier. If you call InitContext() again with
the same database, it will 'point' to the already opened database. If
you point to a different database, you will get a new token with it's
own name.
It sorta looks like with that third initialization it also has each of
the previous two nicknames as well.
If you are using the same cert in all three cases (and the token is
still open), All three nicknames will point to the same cert. It looks
like one cert that lives in 3 different tokens. (There's a call that
will give you all the tokens the cert lives in).
It seems like rule of thumb is that using multiple databases with the
same nicknames is a terrible idea and unpredictable, just looking for
confirmation.
So because of historical issues, nicknames will often give you
unpredictable results. I usually recommend other ways to finding your
cert (like recording the issuer/SN to use).
bob
thanks
rob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
