402584 - Certificates with special characters in the CN

Status: RESOLVED INCOMPLETE

(Core :: Security: PSM, defect)

Description

[Leire Bengoetxea]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: Firefox 2.0.0.4

I'm trying to configure a user certificate, which has special characters like ‘ñ’ in the CN, in firefox 2.0.This certificate is stored in a smart card, and I access to it through a correctly installed PKCS#11 module. The problem is that the certificate is stored in an incorrect store (not like "your certificate") and when I want to use this certificate for authentication or signing purposes, firefox does not allow me to choose it.



Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Daniel Veditz [:dveditz]]

We'll need a lot more information to figure out what's going on here. Is the special character a red herring? (That is, do you have another cert without that character that works? what makes you think that is the problem?).

Do you find the cert stored anywhere? Where? What details does it show? Is it issued by a Certificate Authority trusted by Firefox for the purpose you're trying to use the cert for?

You should probably first seek help in the crypto newsgroup narrowing down the specific problem. news://news.mozilla.org/mozilla.dev.tech.crypto

If you don't have a newsreader that understands news: links (like Mozilla Thunderbird) you can also access the group through Google Groups.

Comment 2

[Leire Bengoetxea]

The user certificate we are using is a certificate issued by IZENPE SA. Firefox is configured to trust this Certification Authority for authentication. When it has been tested with a user certificate without special characters like "ñ", we had no problem to access it through PKCS#11 module and authenticate on it. 

On the other hand, we have no problem with user certificates with special characters such as "ñ" in the subject when they were installed in Firefox through PKCS#12. Firefox stores it in the certificate store called "Your certificates" and when we authenticate on a web it shows us the certificate . The problem arises when we have a certificate with "ñ" in the subject and access to it through PKCS#11 module. In this case, the certificate is stored in the store "Website" and the only data that it shows are the "name of the certificate" and the "purpose". 

Could it have something to do with the way in which the subject of the certificate is encrypted?

Comment 3

[Johnathan Nightingale [:johnath]]

This sounds like a platform-level PSM/NSS issue, not something specific to Firefox.  I'm going to move it over there to get it some additional eyes. 

Comment 4

[Honza Bambas (:mayhemer)]

Leire: could you provide the certificate that causes problems? It is not needed to also provide the private key, but it would be useful. I am trying to simulate your problem using a software token w/o success.

Is the representation of ñ ASCII 241 in Latin-1 page encoding?

Comment 5

[Honza Bambas (:mayhemer)]

Just for info - I am using following openssl commands to create a cert used by the soft token (I have pregenerated key pair in user.key, there is string_mask = utf8only option in openssl.cnf): 

openssl req -key user.key -new -x509 -out user.crt -config openssl.cnf -utf8

When asked for CN I enter Alt-195 Alt-177 (ñ in UTF-8). This produces working cert and when imported to FF3 (current trunk) either FF2 (current branch) using the soft token, it works perfectly. I see ñ in the subject.

The same result for directly entered ñ when using openssl configured just for printable strings.

Comment 6

[Honza Bambas (:mayhemer)]

There is suspicion the problem is the PKCS#11 module. Can you tell us please:
- what is type/vendor of the module and the card you are using?
- how was the certificate and the related priv key transported to the card?

It seems the module is not correctly parsing the certificate subject. Logic that places the certificate to the correct tab in the cert manager depends on presence of the subject/common name. If it is not present in the certificate (because the module is incapable to provide it correctly to Firefox) then the cert is misplaced.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

The fact that the certificate shows up, but not in "your certificates", 
means one thing: NSS/PSM cannot find the private key for the certificate.
This is probably a PKCS#11 module implementation problem, or it could 
be a problem with the software that put the key and certificate onto the
crypto token.  

If I recall correctly, NSS wants the PKCS#11 software objects for the 
certificate and private key to have the same value for the CKA_ID attribute.
If they don't then NSS will not know that the private key corresponds to 
the certificate.  

My guess is that you will find that the two objects have different 
CKA_ID values, and that correcting that in the software that puts the 
objects onto the token will solve the problem.

Comment 8

[Honza Bambas (:mayhemer)]

I would say the reason might be different. The certificate manage code (putting certificates to the right tabs/places) is using following GetCertType function

http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSCertHelper.cpp#2131

here

http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsCertTree.cpp#506

to determine the type of the certificate. This is kind of a heuristic to me. As you can see certificate is considered 'user' only if cert->nickname is present. I suspect that the token implementation is incapable to parse or pass the subject field correctly and therefor the certificate is misplaced. I refer to this because there is a note that there is no problem for certificates w/o any special chars.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

The cert nickname comes from the PKCS#11 CKA_LABEL attribute on the 
certificate object.  The CKA_LABEL must be non-empty.  It is a UTF8 string.  
It is possible that the string on the token is not a valid UTF8 string, but 
rather is in some other character set, such as ISO-8859-soemthing.  That 
would be a problem.  It would probably need to be corrected in the software 
that puts the value into the CKA_LABEL attribute in the token.

Comment 10

[Robert Relyea]

> The CKA_LABEL must be non-empty.

Actually that's not true. The CKA_LABEL could be empty. If it is, there is no nickname for NSS reference (well unless some other cert with the same subject has the a nickname). User certs almost always have some label. (If none are stored in the token, they are sometimes generated from the DN. It might be this code that is messing up (it would be in your token's PKCS #11 module).

> It is a UTF8 string. 

this is true. The character set must be UTF8. Setting some other encoding would result in unfriendly behavior:)

Comment 11

[Kai Engert [:KaiE:]]

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody