CAPolicyURL field suppressed in above certificate

RESOLVED DUPLICATE of bug 97406

Status

Core Graveyard
Security: UI
P3
major
RESOLVED DUPLICATE of bug 97406
15 years ago
a year ago

People

(Reporter: Ralf Hauser, Assigned: Stephane Saux)

Tracking

1.0 Branch
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

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

Comment 1

15 years ago
WIth cygwin's "/usr/bin/openssl x509 -in tcclass1-2011.crt -noout -text" the
field is visible too!

Comment 2

15 years ago
Viewing this site's cert, there appears to be no common name for the issuer.
Priority: -- → P3
Version: 2.1 → 2.4
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.
(Reporter)

Comment 4

15 years ago
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.
Attachment #109378 - Attachment is obsolete: true

Comment 6

15 years ago
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
(Reporter)

Comment 7

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

Comment 8

15 years ago
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?
(Reporter)

Comment 9

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

Comment 11

14 years ago

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

Updated

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

Updated

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.