View a certificate with non-ascii characters in the subject name. The titlebar of the certificate viewer will incorrectly display the non-ascii characters. An example of a problemenatic cert is http://bugzilla.mozilla.org/attachment.cgi?id=109214&action=view
I could use some help on this bug. For one, the cert viewer titlebar isn't displayed on MacOS and I don't have any other platform I can set up a build environment on. For another thing, this appears to be js/DOM related and I find those exceedingly difficult to debug. In security/manager/pki/resources/content/viewCertDetails.js, the function setWindowName() gets the name from one of two places. I suspect it is getting it from the second-listed place, nsNSSCertificate::GetWindowTitle(char * *aWindowTitle). That routine is returning the string in UTF-8 and setWindowName() then uses it to set the "title" attribute on the window. Why the "title" attribute is being interpreted as ISO-8859-1 and how I can get it to interpret it as UTF-8, I have no idea.
Ok, the problem is that nsIX590Cert.idl defines windowTitle as "string" and xpconnect treats "string" objects as being in ISO-8859-1.
*** Bug 231558 has been marked as a duplicate of this bug. ***
*** Bug 286710 has been marked as a duplicate of this bug. ***
*** Bug 309657 has been marked as a duplicate of this bug. ***
*** Bug 309657 has been marked as a duplicate of this bug. ***
Comment #2 identifies the problem. The best fix for this is to change the idl to make windowTitle a AUTF8String attribute, but nsIX509Cert is frozen. What to do?
OS: Windows XP → All
Hardware: PC → All
Summary: Cert viewer titlebar displaying utf8 as iso-8859-1 → Cert viewer titlebar and hierarchy panel displaying utf8 as iso-8859-1
Simon, see also the blocker bug 235230.
This is the cert from bug 185167, here in a form that should be easily downloaded into the browser for examination.
Well, there's another new (?) bug. That cert cannot be imported at all, not by downloading with the appropriate MIME content type, and not by downloading to a disk file and then locally importing it from that file. Sigh.
(In reply to comment #11) > and not by downloading to a disk file and then locally importing it from > that file. Sigh. Nelson, on what tab (in Cert Manager) did you attempt to load the cert? Try "Web Sites", that should do the trick (the "Other People's" tab makes additional checks, which prevent it from being imported in this case).
Kaspar, those other checks in the browser were added to prevent AUTOMATIC importing of invalid certs into cert DBs. They should not prevent users from knowingly and consciously adding other certs from local files. That they do so is a bug. I added the cert with certutil.
(In reply to comment #13) > They should not prevent users > from knowingly and consciously adding other certs from local files. > That they do so is a bug. It's probably considered a "feature" of Cert Manager that it doesn't allow to import untrusted/expired certificates on the "Other People's" tab - nsNSSCertificateDB::ImportEmailCertificate explicitly calls CERT_VerifyCert before it adds them to the database. In any case, my suggestion in comment 12 was simply meant as a quick way to get the cert into the database... because in the context of this bug, it doesn't matter whether the cert appears under the "Other People's" or the "Web Sites" tab.
This appears to be fixed by the patch I'm about to post for bug 643041. Suggestions for how to test it automatically would be appreciated.
Assignee: jgmyers → zackw
Status: NEW → ASSIGNED
(In reply to comment #16) > This appears to be fixed by the patch I'm about to post for bug 643041. > Suggestions for how to test it automatically would be appreciated. Hmm, try to get the length of those strings with some real UTF-8 data inside them. Here's a word in UTF-8 that you can just paste in your test: آزمایش the length should be 6 if the string is interpreted as UTF-8, and 12 otherwise.
I need a little more help than that. The word has to be packaged in a certificate that can somehow be imported, converted to an nsIX509Cert handle, and then its .windowTitle attribute retrieved. I'm certain all this can be done from a chrome mochitest (possibly with the certificate embedded as a data blob) but I have no idea where to begin.
(In reply to comment #18) > I need a little more help than that. The word has to be packaged in a > certificate that can somehow be imported, converted to an nsIX509Cert handle, > and then its .windowTitle attribute retrieved. I'm certain all this can be > done from a chrome mochitest (possibly with the certificate embedded as a data > blob) but I have no idea where to begin. I don't know how you would wrap this word up in a certificate, but once you get that part working, you can probably open this window from your test <http://mxr.mozilla.org/mozilla-central/source/security/manager/pki/resources/content/viewCertDetails.xul> and just read the title. Take a look at the files inside that directory, that's where the certificate manager UI is implemented.
There is a test certificate attached to this bug.
This test has been manually confirmed to fail when run against current trunk, and to pass when run against current trunk + the patches in bug 643041. If approved, I would land it together with those patches (which have already passed review).
Attachment #521082 - Flags: review?
Attachment #521082 - Flags: review? → review?(ehsan)
It occurred to me as I was going to sleep last night that I could embed the base64-encoded certificate in the test driver and avoid all that mucking about with XMLHttpRequest. Also moved the test to an existing test directory.
Attachment #521194 - Flags: review?(nelson) → review?(kaie)
Comment on attachment 521194 [details] [diff] [review] better automated test r=kaie thanks
Attachment #521194 - Flags: review?(kaie) → review+
FWIW, I also read the test, and it looks great to me.
Duplicate of this bug: 856180
Since others have fixed bug 235230 and bug 643041, I've dusted off the test case that I posted to this bug, three years ago (!), and committed it. Here is the committed version - changes relative to the previous are: remove mention of nsIX509Cert3; chrome.ini instead of Makefile.in; sha256Fingerprint instead of md5Fingerprint; subjectName and issuerName have seen unrelated accuracy improvements; all subtests now expected to pass. For maximum clarity, the *bug* originally reported here was fixed in bug 235230; however, this test case depends on bug 643041 as well. https://hg.mozilla.org/integration/mozilla-inbound/rev/0e8b6862acb2
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Depends on: 1167254
You need to log in before you can comment on or make changes to this bug.