No Friendlyname for X509 Cert with Teletextstring in CN, can't set FriendlyName



Core Graveyard
Security: UI
15 years ago
a year ago


(Reporter: goetz, Assigned: kaie)


1.0 Branch

Firefox Tracking Flags

(Not tracked)



(2 attachments)



15 years ago
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.
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> ->
   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...


15 years ago
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
-> PSM
Assignee: ben → ssaux
Component: Preferences → Client Library
Product: Browser → PSM
QA Contact: sairuh → junruh
Version: Trunk → unspecified

Comment 2

15 years ago
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.
Ever confirmed: true
OS: Linux → All
Priority: -- → P3
Hardware: PC → All
Version: unspecified → 2.4

Comment 3

15 years ago
Is this a regression?
Keywords: nsbeta1

Comment 4

15 years ago
This may never have been tested. Netscape CMS 6.1 doesn't like umlauts. Using
the name Götz Babin-Ebell at I could not even
request a cert, until I changed Götz to Gotz.

When I went to in Navigator 4.78, this sort of works, except
his name in the cert is changed to GÈotz instead of Götz.

Comment 5

15 years ago
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...
( )
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
Created attachment 123569 [details]
Same demo ca cert, in base 64 encoded ASCII (plain text)
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?

Comment 9

15 years ago
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.

Comment 10

15 years ago
*** Bug 192727 has been marked as a duplicate of this bug. ***

Comment 11

15 years ago
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.

Comment 13

15 years ago
> 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

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.

Comment 14

15 years ago
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.

Comment 16

15 years ago
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.

Comment 17

14 years ago

*** This bug has been marked as a duplicate of 197009 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


10 years ago
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.