User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126 When you create a X509 certificate with a Teletextstring (not PrintableString) in the CN, and install it in mozilla, Mozilla assigns no name to the certificate / key pair. Selecting the certificate/key pair for use fails and exporting the certificate/key pair fails. And there is no way to set / change the name of the certificate / key pair. Reproducible: Always Steps to Reproduce: 1. go to a certificate authority of you choice (eg. www.trustcenter.de) 2. request a demo certificate, including a special character in the CN (Name) (in my case: Götz Babin-Ebell) 3. the key pair will be generated. 4. you get an email confirming you email address, reply it. 5. after some time you will get an email with an URL where you can install you certificate in you browser, install it. 6. in Edit-> Preferences->Privacy & Security -> Certificates -> Manage Cerifiucates -> Your Certificates -> <Certificate> -> View the Common Name is listed as <Not Part Of Certificate> 7. A backup fails with "unknown reason" in Edit-> Preferences->Privacy & Security -> Certificates -> Manage Cerifiucates -> Your Certificates -> <Certificate> -> Backup 8. If you select the certificate for signing / encrypting in Mail -> Edit -> Mail & Newsgroups Account Settings -> <Account> -> Security sending encrypted / signed emails fails. Actual Results: No Signing / Use of certificate / key pair was possible. Expected Results: Shown some name or let user change the name of the certificate. importing a certificate/key pair with PKCS#12 and a given friendlyname allows usage of the key pair...
Summary: No Friendlyname dor X509 Cert with Teletextstring in CN, can't set FriendlyName → No Friendlyname for X509 Cert with Teletextstring in CN, can't set FriendlyName
Assignee: ben → ssaux
Component: Preferences → Client Library
Product: Browser → PSM
QA Contact: sairuh → junruh
Version: Trunk → unspecified
Confirming. Getting a cert as Götz Babin-Ebell does not show a common name in the cert received. Getting a cert as Security Test does. It must be the umlaut.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Priority: -- → P3
Hardware: PC → All
Version: unspecified → 2.4
Is this a regression?
This may never have been tested. Netscape CMS 6.1 doesn't like umlauts. Using the name Götz Babin-Ebell at https://pki.mcom.com:1025/ca/ I could not even request a cert, until I changed Götz to Gotz. When I went to www.trustcenter.de in Navigator 4.78, this sort of works, except his name in the cert is changed to GÈotz instead of Götz.
The conversion from Götz to GÈotz is a result of the character coding: In the certificate the name is coded as TeletexString (aka T61String) And in T61String the umlaut ö is coded as Èo (don't ask me for details...). A normal CN (without special characters) is coded as PrintableString But since Umlauts are not vaild in PrintableString, T61String is used. Possible, the CN is only accepted if it is coded as PrintableString ? BTW: is there a way to export the key pair with a different program, so I could import the key pair with an acceptable friendly name ? If you really want to hate the different character sets and codings, read Peter Gutmanns guide to X509... ( http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt )
Created attachment 123568 [details] CA cert that demonstrates this problem This attachment will download a new CA cert into your browser that demonstrates the problem
The "General" tab says Common Name <Not Part Of Certificate> The "Details" tab shows the CN in the cert's subject just fine. Does PSM use different NSS calls to obtain the CN on the General tab than it does on the Details tab?
See also bug 53133, which discusses support for T61 (Teletex) in the NSS library. In that bug, I suggested supporting the existing practice of putting Latin-1 character sets in the T61 choice for directory strings, as well as full support for the T61 encoding. This bug suggests supporting the T61 encoding. However, I don't think this is worthwhile. The UTF8 alternative is a much better choice in the long term, and is required by the current IETF RFC by the end of this year.
*** Bug 192727 has been marked as a duplicate of this bug. ***
I did some research on how we display the different tabs: Yes, it appears that we use Components.classes[nsASN1Tree].loadASN1Structure(cert.ASN1Structure) for the general tab, whereas we use the X509Cert stuff for the details tab. Not sure how that differs at the NSS level. I think the data is set in nsNSSASN1Object.cpp. I see the following code: printableItem->SetData((char *)data, len); Then, in GetDisplayValue: aDisplayValue = ToNewUnicode(mDisplayValue); In the DER, is there a way to determine that what will be a string value will be in TeletexString? Anyway, maybe it would be sufficient to use NS_ConvertUTF8toUCS2(mDisplayValue)
Assignee: ssaux → kaie
Terry, if CAs are going to generate certs with T61 encoding, then I think we need to handle them properly, OTOH, I'm not sure this bug is an NSS bug.
> The "General" tab says > Common Name <Not Part Of Certificate> > The "Details" tab shows the CN in the cert's subject just fine. There's a parallel bug somewhere when the certificate has content in unicode (UTF-8/BMPstring) where the "General" tab is correct, and the "Details" tab is wrong. I've found bug 185167 about that, but I remember there's another bug on the issue. Maybe some META bug about encoding issues in certs would be useful. Anyway the problem is *not* that the "General" tab is using the wrong method and "Detail" the right one. In fact, if we considered that the RFC 2459/3280 are deprecating T61String in favor of UTF-8, the method used for the "General" tab is nearer from being correct. In fact, it might perfectly correct, and instead the code from "Detail" wrong by blindly assuming ISO-8859-1 encoding, and the problem here only coming from the missing support for ISO-8859-1 data inside T61strings required in bug 53133.
The details tab assumes UTF8, which it converts to UCS2 for display in the UI.
NSS contains functions that explicitly convert from whatever encoding is used in the cert's DN to UTF8. When PSM is using a value returned by such a function, it is proper to assume that the result if UTF8. But it is also possible to access the raw unconverted values in the NSS memory structures. If PSM is doing that, then it should not assume UTF8. My guess is that one of these path (general or detail) starts with a converted value and the other with the raw value. But that's just a guess.
Nelson. That's exactly my analysis. The code that creates the display in the general basically uses a string obtained from the parsing of the ASN1 in PSM.
*** This bug has been marked as a duplicate of 197009 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.