256992 - Entries in X.509 certificates are not displayed correctly

Status: RESOLVED INVALID

(Core Graveyard :: Security: UI, defect)

Description

[Olaf Gellert]

User-Agent:       Mozilla/5.0 (ogPS) Gecko/20100101
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

When importing and displaying X.509 certificates, Mozilla does not display the
contents correctly if they are no-ASCII characters. For example if the type of
the string is UTF8String or BMPString, special characters like äöüß are
displayed as some strange graphical symbols. According to RFC3280 UTF8String is
the only encoding conforming to the standard after 2003-12-31, so this should
work...

Reproducible: Always
Steps to Reproduce:
1. create an according certificate with special characters in the Subject name
   using OpenSSL
2. import certificate and key (using PKCS12 file)
3. see display of certificate contents

Actual Results:  
Characters were not displayed correctly, other graphical symbols were shown.
Besides this the certificates seem to work. 

Expected Results:  
Display the UTF-8 characters correctly.

Test the given certificate (see URL above). The OpenSSL output for the name is:

Subject:
  countryName               = PRINTABLESTRING:DE
  organizationName          = UTF8STRING:PRE-CERT
  commonName                = UTF8STRING:Till D\C3\B6rges
  emailAddress              = IA5STRING:[e-mail]

Comment 1

[Olaf Gellert]

*** Bug 256991 has been marked as a duplicate of this bug. ***

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Why is this bug filed against NSS?  Looks like a PSM bug to me.
Is there any evidence that this is an NSS bug and not a PSM bug?

Comment 3

[Olaf Gellert]

(In reply to comment #2)
> Why is this bug filed against NSS?  Looks like a PSM bug to me.
> Is there any evidence that this is an NSS bug and not a PSM bug?

Could well be, I am not a Mozilla Developer. After having a look
in the list of Mozilla Components I guess you are right...

Olaf

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Olaf Gellert]

This bug still remains, Mozilla still does not display UTF8 characters in X.509
certificates correctly. It's been more than a year since the bug was submitted,
would be nice if someone would take care of it (though I guess that supporting
UTF8 completely is not easy to implement).

Comment 6

[Wan-Teh Chang]

Nelson, Olaf, do you think bug 309657 is a duplicate
of this bug?

Comment 7

[Olaf Gellert]

Bug 309657 is at least closely related. I was amazed that obviously mozilla is
able to display chinese characters though in my case it even fails to display
ISO-Latin-1 characters. See the image I will attach below (the name of the guy
should be "Till Dörges")...

Comment 8

[Olaf Gellert]

Attachment: Attachment related to previous comment.

Attachment related to previous comment.

Comment 9

[Wan-Teh Chang]

Olaf, could you attach another screen shot in
which you select the "Subject" in the "Certificate Fields"
pane in the middle?

In the screen shot of the Taiwanese government CA cert,
Firefox displays garbage characters in the top
"Certificate Hierarchy" pane but displays the Chinese
characters correctly in the bottom "Field Value" pane
when the "Subject" is selected in the "Certificate Fields"
pane in the middle.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Yes, I think bug 309657 is a duplicate of this bug, and I will mark it as such.

What is not yet determined is whether that cert is properly constructed.
One could imagine, for example, that the cert has ISO-Latin1 characters in
a string encoded as a UTF8 string in the cert, or some other invalid 
combination of character set and encoding.  

Once it has been determined that the cert is properly encoded, then it
would be appropriate to confirm this bug.  And if the cert is not properly
encoded, this bug could be marked invalid or changed to suggest that mozilla
should more forcefully indicate such errors to the user in this display.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 309657 has been marked as a duplicate of this bug. ***

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

This problem has been seen on Windows, Linux and Solaris. 
See Bug 309657 for more info, a screen shot and a cert that demonstrates it.

Comment 13

[Simon Montagu :smontagu]

I spent some time debugging bug 309657 earlier this week. At
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/pki/resources/content/viewCertDetails.js&rev=1.25&mark=64-68#53
we have 

    if (currCert.commonName) {
      displayVal = currCert.commonName;
    } else {
      displayVal = currCert.windowTitle;

windowTitle is defined as string in nsIX509Cert.idl, so it needs conversion from
UTF-8 to UTF-16. (commonName is AString)

Comment 14

[Olaf Gellert]

(In reply to comment #9)
> Olaf, could you attach another screen shot in
> which you select the "Subject" in the "Certificate Fields"
> pane in the middle?

See next attachment.

Olaf

Comment 15

[Olaf Gellert]

Attachment: cert pane with subject selected.

cert pane with subject selected.

Comment 16

[Olaf Gellert]

(In reply to comment #10)

> What is not yet determined is whether that cert is properly constructed.
> One could imagine, for example, that the cert has ISO-Latin1 characters in
> a string encoded as a UTF8 string in the cert, or some other invalid 
> combination of character set and encoding.  

Maybe this helps. It is part of the output of

openssl asn1parse -inform DER -dump -in testcert.utf8-utf8string.der

  199:d=3  hl=2 l=  23 cons: SET               
  201:d=4  hl=2 l=  21 cons: SEQUENCE          
  203:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  208:d=5  hl=2 l=  14 prim: UTF8STRING        
      0000 - 54 69 6c 6c 20 44 c3 83-c2 b6 72 67 65 73         Till D....rges

So it is definitely an UTF8-String, right now I cannot verify that
"c3 83-c2 b6 72" is the UTF8-encoding of the letter "ö"...

Cheers, Olaf

Comment 17

[Simon Montagu :smontagu]

(In reply to comment #16)
>       0000 - 54 69 6c 6c 20 44 c3 83-c2 b6 72 67 65 73         Till D....rges
> 
> So it is definitely an UTF8-String, right now I cannot verify that
> "c3 83-c2 b6 72" is the UTF8-encoding of the letter "ö"...

It's not. The UTF8-encoding of the letter "ö" is "c3 b6".
"c3 83 c2 b6" is the UTF-8 encoding of "ö", which is "c3 b6" in Latin-1.
In other words there has been a double conversion to UTF-8 somewhere.

Comment 18

[Olaf Gellert]

(In reply to comment #17)
> It's not. The UTF8-encoding of the letter "ö" is "c3 b6".
> "c3 83 c2 b6" is the UTF-8 encoding of "ö", which is "c3 b6" in Latin-1.
> In other words there has been a double conversion to UTF-8 somewhere.

Ok, thanks. This resolves the "error" of my test-certificate,
but probably not the problem wit the Taiwanese certificate,
I guess. I'll create a new certificate with correct encoding
and see what happens.

Cheers, Olaf

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Simon, thanks for that analysis!  
I think you have shown that the DER cert is improper.
Notice also from the attached screen shot that the name appears improperly 
in the Title Bar, aand in the Hierarchy and Field Value panes.  
So, I think this bug is invalid.  The problem is not that mozilla is 
improperly displaying valid input, but rather that The input data is not 
valid.  Agreed?

I believe that means that Bug 309657 is NOT strictly a duplicate of this.
That cert's name appears properly in the Field Value pane, suggesting 
it is properly encoded in the cert, but displayed improperly in the 
hierarchy and title bar.  

Comment 20

[Kai Engert (:KaiE:)]

Changing to invalid as suggested by Nelson.
Please reopen if you disagree.