Closed Bug 305890 Opened 19 years ago Closed 9 years ago

Firefox Certificate Viewer problem with Entrust CA certificates

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
1.7 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: test_korisnik, Unassigned)

References

(
URL
)

Details

(Whiteboard: [kerh-coz][psm-cert-manager])

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 Firefox/Thunderbird Certificate Viewer does not properly display X.509 Entrust CA digital certificates (published in the Microsoft Active Directory). For example: 1. Certificate Viewer, tab General, field Issued By: CN = Configuration 2. Certificate Viewer, tab Details, field Certificate Hierarchy: +---Configuration +---Configuration +---UserName UserSurname or SSL/TLS Server Name CN = Configuration is not CA name. ---------------------------------------------- From the Entrust documentations: The Entrust/Authority configuration utility uses CA name as the relative distinguished name (RDN) value for the CA entry in the Microsoft Active Directory AIA container. CA DN look like: cn=CA name cn=AIA cn=Public Key Service cn=Services cn=Configuration dc=Domain Component x ... dc=Domain Component 2 dc=Domain Component 1 --------------------- Microsoft Active Directory attributes: cn=AIA cn=Public Key Service cn=Services cn=Configuration are not CA name. ---------------------------------------------- I hope, Firefox/Thunderbird will resolve this problem. Reproducible: Always Steps to Reproduce: 1. Go to: https://sertifikati.cepp.co.yu/cda-cgi/clientcgi.exe?action=start 2. Press Examine Certificate... button See form "Certificate Viewer", tabs: a. General, field Issued By: CN = Configuration b. Details, field Certificate Hierarchy Actual Results: Firefox/Thunderbird Certificate Viewer does not properly display X.509 Entrust CA digital certificates (problem CN = Configuration). Expected Results: CN = Posta CA 1, instead of CN = Configuration also: CN = Posta CA Root, instead of CN = Configuration
Assignee: nobody → kaie.bugs
Component: Form Manager → Security: PSM
Product: Firefox → Core
QA Contact: form.manager
Version: unspecified → 1.7 Branch
I see this in firefox 1.0.6, but trunk builds work correctly. In both places I get a warning about an untrusted root CA, which I also get in IE.
Group: security
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Yes, connection from Web client to Web server works correctly. But, problem is displaying CA name of the CA certificate: Error: Issued By: CN = Configuration Properly: Issued By: CN = Posta CA 1 ------------------------------------------------------------- You can download root CA certificate: https://sertifikati.cepp.co.yu/cda-cgi/clientcgi.exe?action=caCert or http://www.cepp.co.yu/ca/identifikacioni_podaci/PostaCARoot.der and import in the Firefox Certificate store. -------------------------------------------------------------
Questions about correctness of certificates are best discussed with nelson@bolyard.com You might want to cc him on this bug if you still think there is a bug in handling your certificate.
(In reply to comment #3) > Questions about correctness of certificates are best discussed with > nelson@bolyard.com > You might want to cc him on this bug if you still think there is a bug in > handling your certificate. Yes, Firefox/Thunderbird Certificate Viewer has bug in handling Entrust (www.entrust.com, authority.support@entrust.com, entrust.support@entrust.com) digital certificates (published in the Microsoft Active Directory). We have 4 CA certificate: 1. CN = Posta CA Root, CN = AIA, CN = Public Key Services, CN = Services, CN = Configuration, DC = ca, DC = cepp, DC = co, DC = yu 2. CN = Posta CA 1, CN = AIA, CN = Public Key Services, CN = Services, CN = Configuration, DC = ca, DC = cepp, DC = co, DC = yu 3. CN = TEST CA ROOT, CN = AIA, CN = Public Key Services, CN = Services, CN = Configuration, DC = catest, DC = ptt, DC = yu 4. CN = TEST CA, CN = AIA, CN = Public Key Services, CN = Services, CN = Configuration, DC = catest, DC = ptt, DC = yu ---------------------------------------------------------------------- Firefox/Thunderbird Certificate Viewer for all 4 CA certificate display: CN = Configuration It is big problem for us.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
After downloading (but not trusting) the root CA cert cited above, and visiting the demo URL cited above with moz 1.8b2 20050521 And looking at the cert details, I see this: Certificate Hierarchy Posta CA Root Posta CA 1 sertifikati.cepp.co.yu Assuming that others can reproduce this with FF, this suggests to me that either a) this is a difference between moz and FF, or b) this is a regression that has arisen in FF in the last 4 months.
Mentioned problem exist in the: 1. Firefox 1.0.1 - 1.0.6 2. Thunderbird 1.0 - 1.0.6 (also, don't support CRL chasing) 3. Netscape 7.2-8.0
This appears to be fixed in Firefox 1.5b1 (I tested on Mac OS X); I can't easily find the checkin that would have fixed it. The fix would need to be found, and migrated to the 1.7 branch.
The difference between the products that display the desired name and those that don't is the presence or absence of the fix for bug 197964. So, I confirm that the particular CN being displayed is not the same in all NSS-based products, but not that it is now wrong or now right. The components of a certificate's subject name are organizezd in a hierarchy, or tree, with the attributes near the top (or root) of the hierarchy being the "most general" or "least specific" attributes, and the attributes farthest away from the root (nearest the leaf) are the "most specific" or "least general" attributes. The attributes are stored in the cert ordered from most general to most specific. The first attribute is most general, the last is most specific. When the name is displayed as a flat linear string of type=value pairs, some products display them from most to least specific left to right, and others display them from least to most specific left to right. There seems to be no standard for the display order. Many people find it natural to display the most specific information first, and the least specific last. When addressing postal envelopes, for example, the recipient's name (most specific) information ususally comes first, and the recipient's country (least specific address information) generally comes last. The Common Name attribute (CN) is commonly used to hold an SSL servers DNS domain name. RFC 2818 that says when there are multiple CN attributes in a name, the MOST SPECIFIC one should be used as the source of the DNS name. For a long time, NSS used the first (most general) CN in the cert for the DNS name, and that was wrong. Bug 197964 reported that NSS was using the wrong CN for SSL server DNS names, and that was fixed in NSS 3.10 by changing NSS's GetCommonName function to return the last (most specific) CN rather than the first (most general) CN. That GetCommonName function is used both for finding the DNS name for SSL servers, and also used to fetch strings used for display purposes. So, fixing the DNS name issue for SSL caused the cert displays to begin to display a different value than before, because the cert displays were displaying only a single CN attribute. Now apparently for cert display purposes, some people would rather see the most general CN, not the most specific CN. (Why the name "configuration" is a "common name" in the certifcate at all is a mystery, but I digress.) Perhaps there is a standard somewhere that suggests that the most general attributes, not the most specific attributes, be displayed. I imagine there are some people who are going to be unhappy displaying only the most general, and another group who will be unhappy displaying only the most specific. So I would like to see someone cite a standard before we conclude that mozilla is doing wrong in this display. Indeed, it would seem best to display ALL the CN attributes when claiming to display the cert's true CN. As a way forward, I think we need two (or more) functions for returning a cert's CN. We need one function to return the most specific value for use in SSL, another to display the least specific value (for some displays) and perhaps a third to return a string bearing ALL thed CN attributes in one order or the other. Once those functions exist, the various places in mozilla/TB/FF (etc) that call CERT_GetCommonName will all have to be re-evaluated to see which of the various versions they should be using.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [kerh-coz]
QA Contact: psm
I've installed Firefox 3.0 Beta 5 and it's good that Common Name (CN) is used instead of Organization (O) when viewing certificates, if O attribute doesn't exist, like suggested in previous post. It would be great if same thing is applied on Manage CRLs form, to display CN of CRL's publisher instead of O.
I've installed latest Firefox 3.5.8 and it's still the same situation with Manage CRLs form, O and OU can be displayed, but not CN, which is problem if CRL has CN, but not O and OU. It can be checked with this CRL: http://sertifikati.ca.posta.rs/crl/PostaCA1.crl
Assignee: kaie → nobody
Whiteboard: [kerh-coz] → [kerh-coz][psm-cert-manager]
CRLs aren't supported in Firefox any more. From comment 11, this otherwise appears to be fixed.
Status: NEW → RESOLVED
Closed: 19 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.