Certificate from PKCS#12 file with colon in friendlyName not selectable for signing/encryption

RESOLVED FIXED in 3.12

Status

NSS
Libraries
P2
normal
RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: Kai Kramer, Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

(Blocks: 1 bug)

3.12
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040714

If the friendlyName of an imported PKCS#12 file contains a colon (":"), it does
not appear in the select box of the "Select Certificate" dialog and can
therefore not be used for signing mails.


Reproducible: Always
Steps to Reproduce:
1. Import Certificate from a PKCS#12 file. The friendlyName must contain a colon.
2. Go to security settings for your mail account. 
3. Try to select the imported certificate for signing.


Actual Results:  
The previously imported certificate is not in the list of certificates. If there
are no other certificates, an error message occurs "Certificate Manager can't
locate a valid certificate that can be used to digitally sign your messages".
(Reporter)

Comment 1

13 years ago
Created attachment 153313 [details]
Here is a pkcs12 file with friendlyName "test:PN". Password is "test".
(Reporter)

Comment 2

13 years ago
Created attachment 153316 [details]
For comparison: Same certificate but friendlyName is "test" now.
(Reporter)

Updated

13 years ago
Attachment #153313 - Attachment description: Here is a softtoken with friendlyName "test:PN". → Here is a softtoken with friendlyName "test:PN". Password is "test".
(Reporter)

Comment 3

13 years ago
Password for both softtokens is "test".

(Assignee)

Updated

13 years ago
Assignee: sspitzer → wchang0222
Status: UNCONFIRMED → NEW
Component: Security: General → Libraries
Ever confirmed: true
Product: MailNews → NSS
QA Contact: bishakhabanerjee
Version: Trunk → 3.0
(Assignee)

Comment 4

13 years ago
NSS does not permit colon's in friendly names.  This is as designed.
The only "fix" that seems plausible is to change the colon character to
another character while importing. 
(Assignee)

Updated

12 years ago
QA Contact: bishakhabanerjee → jason.m.reid
(Assignee)

Updated

12 years ago
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
(Assignee)

Updated

11 years ago
Attachment #153313 - Attachment description: Here is a softtoken with friendlyName "test:PN". Password is "test". → Here is a pkcs12 file with friendlyName "test:PN". Password is "test".
(Assignee)

Comment 5

11 years ago
Neil, please implement the suggestion in comment 4 in the pkcs12 decoder.
Assignee: nobody → neil.williams
Priority: -- → P2
Target Milestone: --- → 3.11.2
(Assignee)

Comment 6

11 years ago
*** Bug 320934 has been marked as a duplicate of this bug. ***

Comment 7

11 years ago
Retargetting all P2s to 3.11.3 .
Target Milestone: 3.11.2 → 3.11.3

Updated

10 years ago
Target Milestone: 3.11.3 → 3.11.8

Comment 8

10 years ago
(In reply to comment #4)
> NSS does not permit colon's in friendly names.  This is as designed.
> The only "fix" that seems plausible is to change the colon character to
> another character while importing. 

Nelson, do you have a pointer to comments about this design decision? Some bugs claim that nicknames should be UTF-8, which would include ":".

I have just tried importing attachment 153313 [details] and it imports the cert without complaint.

bash-3.00$ certutil -L -d .
nick                                                         u,u,u
test:PN                                                      u,u,u
Status: NEW → ASSIGNED
(Assignee)

Comment 9

10 years ago
In nicknames, The colon character is a separator.  The general format is:

[<slot-name>:]<cert-friendly-name>  

When we parse a nickname, we look for a colon, and if found, treat the string
before it as a slot name (or token name, or both, I forget).  
You may be able to import it, but I'll bet you cannot list its contents with 
certutil -L -d. -n "test:PN"
(Assignee)

Comment 10

10 years ago
Correction (to comment 9):  It's  [<token-name>:]<cert-friendly-name>

If you find, as I predicted, that the certutil command in comment 9 doesn't
work, then try this alternative:
   certutil -L -d. -n "NSS Certificate DB:test:PN"

That might work.  Let us know.

Comment 11

10 years ago
(In reply to comment #10)
> Correction (to comment 9):  It's  [<token-name>:]<cert-friendly-name>
> 
> If you find, as I predicted, that the certutil command in comment 9 doesn't
> work, then try this alternative:
>    certutil -L -d. -n "NSS Certificate DB:test:PN"
> 
> That might work.  Let us know.
> 

That works. Does that fact make this a non-problem? Perhaps a warning should be issued at import time.

Comment 12

10 years ago
(In reply to comment #10)

Certutil doesn't warn about creating a cert with a colon in the nickname either.

(Assignee)

Comment 13

10 years ago
I'm not sure why this is an NSS bug, since it complains about a UI 
problem in ThunderBird or SeaMonkey.  I think this bug rightly belong
to PSM.  The question is: why doesn't the nickname appear in the list
of selectable nicknames?  

There is also an underlying issue with NSS, which may or may not be
the underlying cause of this bug.  I think we should fix the NSS issue
first.  That may solve the PSM problem too.  If not, then PSM work is 
needed to solve that issue.  

When NSS is asked for the nickname of a cert, NSS generally outputs the 
"simple nickname" if the cert is in the internal DB token, otherwise
it generally shows <token name>:<simple nickname>.  

On input, if the name contains one or more colons, NSS takes everything
up to the first colon as the token name, and everything after the colon
as a simple nickname.  If there is no colon, then the token name is 
implicitly "NSS Certificate DB", the name of the internal DB token.

When a simple nickname of a cert in the internal DB token contains a colon, 
it creates an ambiguity.  Does "test:PN" mean "a cert named PN in the test
token"? or does it mean "a cert named test:PN in the internal DB token?

I think the only solution to this problem will entail fixing a lot of
things in both PSM and NSS.   When NSS outputs a nickname, if it 
contains a colon, and it comes from the internal DB slot, I think NSS must
prepend the slot name explicitly, e.g. "NSS Certificate DB:test:PN".

Maybe, that change alone is sufficient.  Maybe that change alone would
make PSM begin to include the cert nickname in the drop-down list. 

Comment 14

10 years ago
Created attachment 264556 [details] [diff] [review]
add internal token name when nickname contains ':'

Implemented the suggestion in comment 13.
Attachment #264556 - Flags: review?(nelson)
(Assignee)

Comment 15

10 years ago
Neil, please create a new bug against NSS about the issue of displayed 
nicknames needing the token name when they contain a colon.  Then attach 
your patch (above) to that bug, and ask for review there.  I will give it 
r+ there.  

I now believe I erred when I confirmed this bug as an NSS bug.  
It should have been marked as a PSM bug, and probably was (is) invalid.
I will add more comments about that soon.

There are several problems with the cert in the attached P12 files.  

First:  It contains no email addresses at all, so PSM will NEVER find 
        it as being associated with ANY email account.  
Second: It is a (root) CA cert, not an EE cert.
Third:  It does not chain to a trusted CA, and is not explicitly trusted. 
Fourth: It is now expired.  (Although it was within its validity period 
        when the bug was reported.)

As a matter of policy, mozilla email clients require that a cert contain an
email address that matches the email address on the email account.  They 
won't let you use a cert with the wrong email address, or with NO email 
address, on an email account.  This policy has recently been reaffirmed.

So, AFAICT, the reason mozilla doesn't let the user select this cert for use 
with his email account has nothing to do with the presence or absence of a 
colon in the nickname, and has everything to do with the cert not apparently
being an EE email cert for any email address.  By mozilla's definition, 
the attached cert is not valid a email cert, and was not, even when it was 
within its validity period.  Even if that was not being enforced back in the
FF 0.8 days (when this bug was submitted), it is now.

If this claim (that PSM doesn't allow the selection of a cert just because
it has a colon in the nickname) could be demonstrated with a valid email
cert (one that has an email address in it, and that is not a self-signed 
CA cert, but rather is an EE cert), from a trusted issuer of email certs,
then I'd say we should pursue this further. But as a matter of policy,
the NSS team does not fix "bugs" that can only be reproduced with invalid 
certs.  

If the reporter wants to attach valid email certs that demonstrate the 
claimed bug, then perhaps this bug should receive further consideration.  
Otherwise, this bug should be resolved INVALID, IMO.

I am converting this into a PSM bug, since it was a complaint about 
mozilla client cert selection GUI, which is the domain of PSM.  
I recommend that if a valid test case is not produced, then this bug 
should be resolved invalid.
Assignee: neil.williams → kengert
Status: ASSIGNED → NEW
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries → psm
Target Milestone: 3.11.8 → ---
Version: 3.0 → Other Branch
(Reporter)

Comment 16

10 years ago
Created attachment 264663 [details]
Updated test case with friendly name "test:PN", pw "test"

As requested an updated PKCS#12 file with an EE certificate with email address set
Attachment #153313 - Attachment is obsolete: true
(Reporter)

Comment 17

10 years ago
Created attachment 264664 [details]
Same certificate but friendly name is "test" now

Updated PKCS#12 file. Same certificate as in attachment 264663 [details] but when imported from this file it is shown in certificate selection (email address does not seem to matter for selection)
Attachment #153316 - Attachment is obsolete: true
(Reporter)

Comment 18

10 years ago
Created attachment 264667 [details]
CA certificate for certificate from PKCS#12 files

CA certificate for attachments 264663 and 264664. OpenSSL set basic constraint for CA to false, but it can be imported into Mozilla as an authority anyway.
(Assignee)

Comment 19

10 years ago
Thanks very much for the certs.  I was able to reproduce the problem.
It seems that it IS an NSS problem after all.  
It requires a bigger patch than the previous one, but I have a patch now
that seems to fix it.  However, much more testing is required.
Assignee: kengert → nelson
Component: Security: PSM → Libraries
Product: Core → NSS
Target Milestone: --- → 3.12
Version: Other Branch → 3.4
(Assignee)

Comment 20

10 years ago
Created attachment 264712 [details] [diff] [review]
patch v2 - fix another copy of this code

The code that Neil patched appears in two separate functions in pki3hack.c
and both of them need to be patched.  The result of this patch is that the 
nickname in the CERTCertificate contains the token-name prefix, so that all
code that copies it from there will get the correct form of the nickname.
Attachment #264556 - Attachment is obsolete: true
Attachment #264712 - Flags: review?
Attachment #264556 - Flags: review?(nelson)
(Assignee)

Comment 21

10 years ago
Comment on attachment 264712 [details] [diff] [review]
patch v2 - fix another copy of this code

Neil, please review.
Attachment #264712 - Flags: review? → review?(neil.williams)

Updated

10 years ago
Attachment #264712 - Flags: review?(neil.williams) → review+
(Assignee)

Comment 22

10 years ago
Checking in pki3hack.c; new revision: 1.93; previous revision: 1.92
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Blocks: 390184
You need to log in before you can comment on or make changes to this bug.