Thanks for your reply, Bob!
You said:
When you need fine grain control, the application should use
issuer/serial number to identify the cert (I think all the mozilla
apps have gone to this now)
Well, I agree that it /should/ use the issuer/serial number, which is
supposed to be unique (unlike the nickname). But I don't think that's
the case with the Mozilla apps right now.
I'm using the latest Thunderbird (v38.1) and the certificate selection
box in the "S/MIME" section of the e-mail account configuration dialogue
shows the certificate's nickname /only./
And, even more important, if we look into the "prefs.js" file, where
Thunderbird actually stores which certificate is selected, we see that
it stores /only/ the certificate's nickname!
(It's also the "prefs.js" file that we need to update in order to
configure the user's certificate in an automated way. And currently the
best we can do, AFAIK, is to write the nickname)
Regards,
Daniel
Am 27.07.2015 um 18:07 schrieb Robert Relyea:
On 07/27/2015 12:54 AM, Trick, Daniel wrote:
Thank you a lot for clarification, Kaspar!
So, by design of NSS, all certificates with the same DN will end up
with the same nickname. And the very first certificate with a
specific DN will set the nickname for all other certificates (with
that same DN).
Now, I see that this works as long as we have one certificate for
encryption, one for signing and one for auth. The application (e.g.
Thunderbird) still picks the correct certificate, probably by looking
at the key usage flags, although they all have the same name.
But how am I supposed to deal with the situation that the users gets
a "new" certificate for the same DN? If there are several
certificates for, e.g., encryption, all with the same DN - and thus
also with the same nickname - how do we distinguish?
NSS returns the newest cert valid cert for the given operation.
(I'm asking this, because I also need to be prepared for the case
that user certificates are "refreshed" when they expire - or shortly
before they expire. So, for a limited amount of time, we may need to
keep the "old" /and/ the "new" certificate in the store)
Yes, that's pretty common, including in Thunderbird (where you have a
lot of old encryption certs).
There are not so good, and not uncommon corner cases to watch out for:
If you have 2 certs with the same DN, but different rolls where both
are active at the same time, you can't use nicknames to select the
cert. If you want to delete a cert, you can't use nickname to uniquely
identify the cert you want to delete. When you need fine grain
control, the application should use issuer/serial number to identify
the cert (I think all the mozilla apps have gone to this now).
bob
Regards,
Daniel
Am 26.07.2015 um 08:38 schrieb Kaspar Brand:
On 20.07.2015 14:05, Trick, Daniel wrote:
I'm facing a new problem regarding pk12util from NSS Tools:
When I import the _first_ certificate of a user into the database with
pk12util, then certificate's name in the NSS database will be:
*NSS Certificate DB: <friendly_name_taken_from_p12_file>
*
Okay, but as soon as I import the _second_ certificate (or any
further
certificate), it won't be added to the DB with a distinct name.
Instead,
the entry that was created when importing the _first_ certificate will
appear several times! :-\
[...]
*Is this an intended behaviour of pk12util, and if so, how can I
achieve
the required result? If it's *not* intended and actually a bug,
should I
file a bug report now?*
*
Yes, it is by design. All certificates with the same subject DN are
expected to share a common nickname, otherwise you would end up with a
corrupt DB, see e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=594297.
Kaspar
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
