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).




dev-tech-crypto mailing list

Reply via email to