Build 2002121008: When viewing the above certificate upon installation, this field is not visible. In MSIE, it is and I guess it would be useful to get the link to http://www.trustcenter.de/guidelines at this point.
WIth cygwin's "/usr/bin/openssl x509 -in tcclass1-2011.crt -noout -text" the field is visible too!
Viewing this site's cert, there appears to be no common name for the issuer.
John, this is a self-issued CA cert, not an SSL server cert. So it's not expected to have a CN=domain.name in the subject name. It contains a "CA Policy URL" extension, which is a URL. I think the complaint here is that that URL is not appearing in some of mozilla's certificate displays, although it's not clear to me which display(s) the submittor was using.
Created attachment 109378 [details] To clarify where I am missing the field in Mozilla - MS Word file
Comment on attachment 109378 [details] To clarify where I am missing the field in Mozilla - MS Word file This attachment appears to be an image of a Microsoft cert manager window. That window is not mozilla software. The question is: what mozilla window(s) are missing this information.
Somehow the www.trustcenter.de website is not reachable from within the corporate network... When I view the details of the cert, I see Mozilla is displaying two extensions which seem to be unknown to it, possibly one of them is the information we are talking here. The object identifiers are: 2 5 29 19 2 16 840 1 113730 1 8
Nelson, the http://bugzilla.mozilla.org/attachment.cgi?id=109378&action=view attachment has both - first a MS window image to prove that the field exists AND on page 2 (just PGDOWN! ;) ) the illustration that Mozilla misses this. Kai, it would be great if Mozilla worked flawlessly with certificates from trustcenter. They just have been chosen to be the issuer of certificates that will be accepted by SWISS VAT authorities (see http://www.efd.admin.ch/d/dok/medien/medienmitteilungen/2002/12/digitalsigniert.htm) this means for example if a swiss merchant sells some good to someone abroad, a digitally signed receipt will be valid proof leading to VAT exemption. Until now, the merchant had to print a paper receipt and suface-mail it to the buyer - an overhead of Euro 2 or more per transaction! This is one the first examples of digital signatures officially accepted for the broader public I am aware of - maybe you have a list of similar cases somewhere on your website?
You say, it would be nice if certs worked flawlessly. Are they now? I thought the only problem is, one extension is not presented in the way you expect?
Yes, unfortunately there are some problems left: When I send a message to the TC certificate and sign it. On receipt in MS outlook, I do not see the TC certificate, but only the signing certificate. Sure, this may be an outlook error - e.g. assuming that Mozilla by default encrypts to two keys, namely the TC key and the self key, Outlook should show both certificates. But trying to narrow down on this, I no longer sign the same message in Mozilla. All looks fine when sending in this case, but the messages never arrive. What happened? Unfortunately, I haven't found a way to determine what Mozilla really did: - to which keys did it encrypt it? - does it "encrypt to self" even if it is not signed? See http://bugzilla.mozilla.org/show_bug.cgi?id=185779 for one suggestion how to remedy that.
Re comment 6 : 2 5 29 19 is x509basicConstraints. This tells whether the cert is a CA cert or not. 2 16 840 1 113730 1 8 is the Netscape cert policy URL extension. NSS recognizes both of these OIDs, and has strings for each of them. I'd say apparently PSM is not using NSS's facility for recognizing OIDs. I think there's already another PSM bug about PSM not recognizing many cert extension OIDs. Kai, if you can find that one, this bug should probably made a dupe of that one. Re Comment 9: Ralf, the issues reported there are unrelated to this bug. Let's discuss them in the newsgroup, not here.
*** This bug has been marked as a duplicate of 97406 ***